[asterisk-users] Failed to CANCEL a call in ringing state (SIP) in 1.8.9.2

Kevin P. Fleming kpfleming at digium.com
Tue Feb 14 11:32:24 CST 2012


On 02/14/2012 11:19 AM, Karsten Wemheuer wrote:
> Hi Kevin,
> Am Dienstag, den 14.02.2012, 09:46 -0600 schrieb Kevin P. Fleming:
>> On 02/14/2012 09:30 AM, Karsten Wemheuer wrote:
>>> Hi,
>>>
>>> I got a problem with asterisk 1.8.9.2. The same scenario is working fine
>>> in 1.8.8.2.
>>>
>>> Asterisk calls a SIP phone via a proxy, proxy phone and asterisk are on
>>> the same LAN, no NAT.
>>>
>>> Asterisk sends the INVITE to the proxy, the proxy sends INVITE to the
>>> phone. The phone sends 180 RINGING back to the proxy. The proxy sends
>>> 180 RINGING to asterisk. So far so good. If the calling side decides to
>>> cancel the call, asterisk sends the CANCEL directly to the phone. The
>>> phone doesn't find the call and answers 404. In asterisk 1.8.8.2
>>> asterisk sends the CANCEL to the proxy, which sends the CANCEL to the
>>> phone and all ist fine.
>>>
>>> I think, the new behavior comes from the lines
>>>    		parse_ok_contact(p, req);
>>> 		if (!reinvite) {
>>> 			build_route(p, req, 1);
>>> 		}
>>> which are inserted in the handling of provisional SIP response.
>>>
>>> Am I doing something wrong or is this a bug?
>>
>> It's impossible to answer that question without seeing the SIP
>> signaling. The answer will depend on what the proxy did to insert itself
>> in the path (or not) when it forwarded the 180 RINGING response to Asterisk.
>>
>
> I shorten the trace to (hopefully) the relevant things. Asterisk is on
> 192.168.10.72, port 25060, proxy is opnesips on the same machine with
> port 5060, the phone which is ringing is on 192.168.10.221.
>
> Asterisk =>  Proxy:
> U 192.168.10.72:25060 ->  192.168.10.72:5060
> INVITE sip:arthur at 192.168.10.72 SIP/2.0.
> Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860.
> Max-Forwards: 70.
> From: "Max M..ller"<sip:245 at 192.168.10.72>;tag=as3cafd135.
> To:<sip:arthur at 192.168.10.72>.
> Contact:<sip:245 at 192.168.10.72:25060>.
> Call-ID: 4c640ebd11d192e15bfc6d3a667684ce at 192.168.10.72.
> CSeq: 102 INVITE.
> ... sdp cut of ...
>
> Proxy =>  Asterisk
> U 192.168.10.72:5060 ->  192.168.10.72:25060
> SIP/2.0 100 Giving a try.
> Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860.
> From: "Max M..ller"<sip:245 at 192.168.10.72>;tag=as3cafd135.
> To:<sip:arthur at 192.168.10.72>.
> Call-ID: 4c640ebd11d192e15bfc6d3a667684ce at 192.168.10.72.
> CSeq: 102 INVITE.
>
> Proxy =>  phone
> U 192.168.10.72:5060 ->  192.168.10.221:34381
> INVITE sip:arthur at 192.168.10.221:34381;line=478vzxb3 SIP/2.0.
> Via: SIP/2.0/UDP 192.168.10.72;branch=z9hG4bK24be.5163d992.0.
> Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860.
> Max-Forwards: 69.
> From: "Max M..ller"<sip:245 at 192.168.10.72>;tag=as3cafd135.
> To:<sip:arthur at 192.168.10.72>.
> Contact:<sip:245 at 192.168.10.72:25060>.
> Call-ID: 4c640ebd11d192e15bfc6d3a667684ce at 192.168.10.72.
> CSeq: 102 INVITE.
> ... sdp cut of ...
>
> Phone =>  Proxy
> U 192.168.10.221:34381 ->  192.168.10.72:5060
> SIP/2.0 180 Ringing.
> Via: SIP/2.0/UDP 192.168.10.72;branch=z9hG4bK24be.5163d992.0.
> Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860.
> From: "Max M..ller"<sip:245 at 192.168.10.72>;tag=as3cafd135.
> To:<sip:arthur at 192.168.10.72>;tag=cvovqkf6i5.
> Call-ID: 4c640ebd11d192e15bfc6d3a667684ce at 192.168.10.72.
> CSeq: 102 INVITE.
> Contact:<sip:arthur at 192.168.10.221:34381;line=478vzxb3>;reg-id=1.
>
> Proxy =>  Asterisk
> U 192.168.10.72:5060 ->  192.168.10.72:25060
> SIP/2.0 180 Ringing.
> Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860.
> From: "Max M..ller"<sip:245 at 192.168.10.72>;tag=as3cafd135.
> To:<sip:arthur at 192.168.10.72>;tag=cvovqkf6i5.
> Call-ID: 4c640ebd11d192e15bfc6d3a667684ce at 192.168.10.72.
> CSeq: 102 INVITE.
> Contact:<sip:arthur at 192.168.10.221:34381;line=478vzxb3>;reg-id=1.
>
> When canceling the call, asterisk sends
>
> Asterisk =>  Phone
> U 192.168.10.72:25060 ->  192.168.10.221:34381
> CANCEL sip:arthur at 192.168.10.72 SIP/2.0.
> Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860.
> Max-Forwards: 70.
> From: "Max M..ller"<sip:245 at 192.168.10.72>;tag=as3cafd135.
> To:<sip:arthur at 192.168.10.72>.
> Call-ID: 4c640ebd11d192e15bfc6d3a667684ce at 192.168.10.72.
> CSeq: 102 CANCEL.
>
> The Phone responds:
>
> U 192.168.10.221:34381 ->  192.168.10.72:25060
> SIP/2.0 404 Not found.
> Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860.
> From: "Max M..ller"<sip:245 at 192.168.10.72>;tag=as3cafd135.
> To:<sip:arthur at 192.168.10.72>.
> Call-ID: 4c640ebd11d192e15bfc6d3a667684ce at 192.168.10.72.
> CSeq: 102 CANCEL.
>
> As noted in the earlier mail, this scenario is working in previous
> versions (1,4.x up to asterisk 1.8.8.2).
>
> Do You have any idea where the failure happens? Is it the proxy
> configuration or is it at the asterisk side (maybe config or bug)?

This does appear to be a bug in Asterisk; please open an issue in JIRA, 
and post the issue number here, so we can get someone looking at this 
ASAP. Thanks!

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org



More information about the asterisk-users mailing list