INVITE not forwarded


If have 2 (soft)sipphones registered on an AsteriskNow 2.0 with extension 7001 and 7002.
Each phone running on a different laptop as well as WireShark examining the SIP traffic

Then, 7001 calls 7002.
7002 accepts the call.
Now, when 7002 puts 7001 on hold, (by sending INVITE with in the SDP a=sendonly to the PBX) the SIP message is visible in the ws-trace on the 7002-laptop, but the message is not traceable on the receivers end (7001)
Seems to me Asterisk doesn’t forward that type of SIP messages to the receiver.
INVITEs not being forwarded happen as well during transfers.
No problem with other types of PBX (Innovaphone, HiPath)

How can I have Asterisk forward those messages? (I need it for a SIPPhone I’m developing)
Some (hidden) setting?

kind regards

Asterisk never forwards INVITEs; it regenerates them on (to be) bridged channel. This is because it is a back to back user agent, not a SIP proxy. It does not signal hold upstream at all.

When you get the Re-invite with a media direction of sendonly or an media address of, Asterisk generates an AST_CONTROL_HOLD frame internally. If the bridged channel is also a SIP channel, it starts music on hold, but does not generate a re-invite.

Changing this behaviour involves quite significant re-work of the source code. The handling of media direction attributes was and probably still is flawed.

If you want to follow this up, you should move to the developer mailing list. However, as you indicate that you are using AsteriskNOW, it is unlikely that you will want to go down to that level.


it starts music on hold, but does not generate a re-invite.
If this is only with on hold then OK, The on hold music makes it clear to the receiver that he’s put on hold

But what do you do with transfers?
I’ll explain what the problem is I’m facing…

Extending my scenario a bit… using 3 phones (ext 7001, 7002 and 7003)

7001 calls 7002
7002 accepts the call
7002 puts 7001 on hold and calls 7003
7003 accepts the call.
7002 now Xfers 7001 to 7003 so that the end result is that 7001 and 7003 are now in a conversation,
and that’s what users of my SipPhone see:
7001 sees that his connection changed from 7002 to 7003
7003 sees that his connection changed from 7002 to 7001

In order to that, so far on Innovaphone,HiPath and other, I detected the Xfer by parsing the new INVITEs that were generated and looking for the ‘Remote-Party-ID’ or ‘Referred-By’ SIP-headers.

Now with Asterisk (2.0 and below) no such INVITEs are generated.
Does this mean there’s no way whatsoever to detect Xfers on Asterisk?

kind regards

Current versions have some COLP (Connected Line Presentation) update capabilites, for suitable phones, but they will still terminate the SIP on one side and generate new SIP on the other side; that is of the nature of back to back user agents (B2BUAs).

You will need at least Asterisk version 1.8 (I don’t know which version is packaged with AsteriskNOW 2.0. You will also need COLP capable phones. Not having use it yet, I can’t guarantee that it will work with your phones. I believe the main target was Cisco phones with SIP firmware. It was added because of your transfer scenario.


And how is COLP information communicated from the Asterisk to a phone?
We’re not talking SIP anymore then?


Commonly implemented, draft, SIP extensions.

've been looking for “SIP extension” + COLP in google but don’t find a good link really.
any documentation/link you recommend?
some samples maybe?


To forward, it uses re-INVITE, or UPDATE, with Remote-Party-ID headers.

using my scenario, do you mean that it is 7002 who must re-INVITE, or UPDATE, with Remote-Party-ID headers?
Currently he’s using REFER with Refer-To and Referred-By headers

Using UPDATE with Remote-Party-ID instead of REFER will have Asterisk forward the SIP message?

Asterisk never forwards SIP messages. An incoming REFER should generate a re-invite or update on the outgoing side, although there may be more conditons to fulfill. If you want more details, you will need to refer to the source code or test cases empirically. The transfer may not even involve a SIP channel.