Is it a SIP protocol bug?


I have a near complete custom AMI interfaced program for controlling and monitoring asterisk connected equipment. It works quite well except for a single scenario, which I believe has revealed a bug in asterisk. I am hoping someone here may be able to confirm this for me, or tell me what I am misunderstanding.

We are using linphone in auto-answer mode on some of our equipment to handle audio, and we have asterisk on a central server to coordinate connections. In one scenario we command asterisk to connect a linphone box to an internal extension which only provides a ringing signal. The system waits here until an event from other equipment is detected. At that point we transfer the linphone channel to a new extension which is a real phone (also set to auto answer).

The AMI commands to do these two functions are here:

Action: Originate
Channel: local/b03c2
Async: 1
Exten: ringing
Variable: __EVENTID=78086501
Callerid: MYCALLER
Priority: 1
Timeout: 600000

This call is successfully placed. After an event is triggered in out system, we send the following to transfer the call:

Action: Redirect
Channel: SIP/b03c2-000000c1
Exten: 231
Context: default
Priority: 1

The problem.

Shortly after the transfer from ‘ringing’ to the real phone (which is successfully completed) Asterisk give this message on the console and terminates the call:

Hanging up call 33a0c45a1874646c0d44ee3054d8d47f@ - no reply to our critical packet

Using tcpdump I was able to determine the “critical packet” (below), which asterisk dutifully resends many times, and linphone apparently ignores.

Via: SIP/2.0/UDP;branch=z9hG4bK3a6488dc;rport
Max-Forwards: 70
From: “MYCALLER” sip:asterisk@;tag=as3f145948
To: sip:b03c2@;tag=1624842300
Contact: sip:asterisk@
Call-ID: 33a0c45a1874646c0d44ee3054d8d47f@
CSeq: 104 UPDATE
User-Agent: Asterisk PBX
Remote-Party-ID: “guardstation1” sip:231@;party=calling;privacy=off;screen=no
X-Asterisk-rpid-update: Yes
Content-Length: 0

This I believes reveals a bug in asterisk because linphone has no support for this packet. Here is the Allow line from its OPTIONS packet.


UPDATE is not listed here (and there is no mention of ‘UPDATE’ in the linphone source) so it is no surprise that linphone is ignoring it. Unfortunately my understanding of SIP is very basic so what I am not completely sure of is if the bug is in asterisk for sending this packet in the first place or if it is in linphone for not sending some kind of NAK as a response.

It is also interesting that the call transfer completes successfully anyway. Presumably as a result of the subsequent INVITE messages which are also sent.

If there is anyone out there that knows more about SIP/asterisk/linphone who might be able to explain this I would very much appreciate a reply.

Thank you very much

It is a bug in linphone. Even if it doesn’t support the method (you missed out the method line!) it should respond that it does not support it.

I forget the option, but you should be able to turn off connected line updating, in Asterisk, for this device.

Wow. Thank you. As I said, I have a poor understanding of SIP protocol itself. I didn’t see a method line in any of the packets I captured.

Apparently it is the "Remote-Party-ID’ message which needs to be suppressed and the SIP option to do so is sendrpid=no.

I lost the better part of a day to this yesterday. Sigh.

Be warned anyone using linphone. Set sendrpid to ‘no’!