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:
This call is successfully placed. After an event is triggered in out system, we send the following to transfer the call:
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 email@example.com:5060 - 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 192.168.10.57:5060;branch=z9hG4bK3a6488dc;rport
From: “MYCALLER” sip:firstname.lastname@example.org;tag=as3f145948
CSeq: 104 UPDATE
User-Agent: Asterisk PBX 220.127.116.11~dfsg-1ubuntu1
Remote-Party-ID: “guardstation1” sip:email@example.com;party=calling;privacy=off;screen=no
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.
INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
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