Summary:	ASTERISK-19937: Still not working - Failed to CANCEL a call in ringing state (SIP) in 1.8.9.2, 1.8.11, 1.8.12.2
Reporter:	Peter Sokolov (peterdoo)	Labels:	regression
Date Opened:	2012-06-01 08:52:15	Date Closed:	2012-07-17 18:13:47
Priority:	Critical	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence	Constant
Related Issues:	is a clone of ASTERISK-19358 Failed to CANCEL a call in ringing state (SIP) in 1.8.9.2
Environment:	Debian, Asterisk 1.8.12.2	Attachments:	( 0) annotated_SIP_debug.txt
Description:	Not sure, this has to do with ASTERISK-19358. The visible problem is the same. That is, phones do not stop ringing after CANCEL. Looking into SIP debug one can see that Asterisk is sending various SIP messages (CANCEL, ACK) to the IPs that are not participating in the call at all. In the below example one can see that for example it says: [Edited- 6/3/12- Rusty Newton - removed debug an attached as annotated_SIP_debug.txt]
Comments:	By: Rusty Newton (rnewton) 2012-06-01 13:59:24.598-0500 Stefan, do you know if this is still re-occurring for anyone else that had the issue before? Can you attach a packet trace with associated sanitized sip.conf and do you have any idea how to reproduce? As I don't think we have seen this internally with those versions. By: Stefan Schmidt (schmidts) 2012-06-02 05:34:03.234-0500 Welcome rusty ;) AFAIK has walter doekes (wdoekes) written a regression test for this. See review r1751 so i though this problem isnt only solved but also checked by a test so it should occour anymore. maybe this test missed a part of the change. best regards stefan By: Peter Sokolov (peterdoo) 2012-06-02 05:55:09.351-0500 To be able to see the problem, it is important that the SIP domain has a SIP proxy on a different IP than A record for the domain. It worked correctly in older 1.8 versions however not in the mentioned ones. In my example sipdomain.com resolves to 78.73.170.26, while SRV record for _sip._udp.sipdomain.com points to sip1.sipdomain.com which itself resolves to 78.73.170.132. The peer is present in sip.conf in the following way: [OutDirect] type=peer fromdomain=sipdomain.com defaultuser=myname secret=mysecret host=sipdomain.com context=from-office canreinvite=yes qualify=no insecure=port,invite promiscredir=no dtmfmode=rfc2833 nat=no disallow=all allow=ulaw callgroup=1 The call is initiated in extensions.conf: [from-office] exten => _00ZXX.,1,NoOp exten => _00ZXX.,2,NoOp exten => _00ZXX.,3,Dial(SIP/000${EXTEN}@OutDirect,60,) exten => _00ZXX.,4,Hangup The INVITE finds the correct IP 78.73.170.132 for the SIP domain sipdomain.com using its SRV records:    -- Executing [0049123456710@from-office:1] NoOp("SIP/phone-5-00000034", "") in new stack    -- Executing [0049123456710@from-office:2] NoOp("SIP/phone-5-00000034", "") in new stack    -- Executing [0049123456710@from-office:3] Dial("SIP/phone-5-00000034", "SIP/0049123456710@OutDirect,60,") in new stack  == Using SIP RTP CoS mark 5 Audio is at 19684 Adding codec 0x4 (ulaw) to SDP Adding codec 0x800 (g726) to SDP Adding codec 0x2 (gsm) to SDP Adding non-codec 0x1 (telephone-event) to SDP Reliably Transmitting (no NAT) to 78.73.170.132:5060: INVITE sip:0049123456710@sipdomain.com SIP/2.0 SIP Proxy replies with 183: <--- SIP read from UDP:78.73.170.132:5060 ---> SIP/2.0 183 Session progress Via: SIP/2.0/UDP 78.38.13.197:5060;branch=z9hG4bK362ae7da From: "123456789" <sip:123456789@sipdomain.com>;tag=as6c689db8 To: <sip:0049123456710@sipdomain.com>;tag=340313ac4f9907ac581a71 Contact: sip:0049123456710@78.73.170.132:5060 Call-ID: 5bbc8501767ee2c8623018af25d19ef3@sipdomain.com CSeq: 102 INVITE Server: Sip Proxy Server Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE Content-Type: application/sdp Content-Length: 200 <-------------> --- (11 headers 9 lines) --- list_route: hop: <sip:0049123456710@78.73.170.132:5060>    -- SIP/OutDirect-00000035 is making progress passing it to SIP/phone-5-00000034 Audio is at 11966 The caller hangs up. Asterisk receives CANCEL and starts to cancel the outgoing leg. Somehow it sends the request to the IP for A Record for sipdomain.com instead to the IP used in INVITE (obtained by DNS SRV lookup). <------------> Scheduling destruction of SIP dialog '5bbc8501767ee2c8623018af25d19ef3@sipdomain.com' in 32000 ms (Method: INVITE) set_destination: Parsing <sip:0049123456710@sipdomain.com> for address/port to send to set_destination: set destination to 78.73.170.26:5060 Reliably Transmitting (no NAT) to 78.73.170.26:5060: CANCEL sip:0049123456710@sipdomain.com SIP/2.0 v: SIP/2.0/UDP 78.38.13.197:5060;branch=z9hG4bK362ae7da Max-Forwards: 70 f: "123456789" <sip:123456789@sipdomain.com>;tag=as6c689db8 t: <sip:0049123456710@sipdomain.com> i: 5bbc8501767ee2c8623018af25d19ef3@sipdomain.com CSeq: 102 CANCEL User-Agent: Sipura/SPA3000-3.1.3(GWa) l: 0 Anyhow besides this problem of using wrong DNS lookup in my opinion any additional DNS lookup before sending non-call-initiating SIP packets (CANCEL, BYE) is a wrong way of doing it. Imagine a provider using many SIP proxies for the same domain, each using different IP. If the IP for CANCEL is obtained using DNS lookup, it might be a different one that the one that was used in INVITE. CANCEL or BYE would go to a different SIP proxy which normally knows nothing about a call. For example proxy. sip. orange. es resolves to many different IPs. Now imagine that between INVITE and CANCEL or between INVITE and BYE that IP expires in DNS cache. The next DNS lookup for CANCEL/BYE would return a different IP (round robin) for the same domain and even though the correct DNS lookup has been used for Request-URI, CANCEL/BYE would not work being sent to a different SIP proxy which knows nothing about a call. In my opinion Asterisk would have to store the IP (v4/v6) to which INVITE is sent and use exactly and only that one without any additional DNS lookup for sending CANCEL and BYE requests for the same call. The Request-URI is anyhow always identical as in INVITE in both CANCEL/BYE, so no reason to do another DNS lookup. Let's continue with the SIP trace. 10 retransmitts to the wrong IP follow. Retransmitting #1 (no NAT) to 78.73.170.26:5060: CANCEL sip:0049123456710@sipdomain.com SIP/2.0 Then the called party rejects the call: <--- SIP read from UDP:78.73.170.132:5060 ---> SIP/2.0 486 Busy here Via: SIP/2.0/UDP 78.38.13.197:5060;branch=z9hG4bK362ae7da From: "123456789" <sip:123456789@sipdomain.com>;tag=as6c689db8 To: <sip:0049123456710@sipdomain.com>;tag=340313ac4f9907ac581a71 Contact: sip:0049123456710@78.73.170.132:5060 Call-ID: 5bbc8501767ee2c8623018af25d19ef3@sipdomain.com CSeq: 102 INVITE Server: Sip Proxy Server Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE Content-Length: 0 Now Asterisk claims, the SIP response has been received from a different IP than the one the request really came from. Cannot imagine any explanation for this one. And then it is trying to do (faulty) DNS lookup probably for the Request-URI? According to RFC ACK should normally be sent to Contact-URI which here is IP address anyhow (Contact: sip:0049123456710@78.73.170.132:5060). <-------------> --- (10 headers 0 lines) ---    -- Got SIP response 486 "Busy here" back from 77.72.169.25:5060 set_destination: Parsing <sip:0000034649140380@voicetrading.com> for address/port to send to set_destination: set destination to 78.73.170.26:5060 Transmitting (no NAT) to 78.73.170.26:5060: ACK sip:0049123456710@78.73.170.132:5060 SIP/2.0 v: SIP/2.0/UDP 77.37.12.196:5060;branch=z9hG4bK362ae7d9 Max-Forwards: 70 f: "123456789" <sip:123456789@sipdomain.com>;tag=as6c689db8 t: <sip:0049123456710@sipdomain.com>;tag=340313ac4f9907ac581a71 m: <sip:0049123456710@78.73.170.132:5060> i: 5bbc8501767ee2c8623018af25d19ef3@sipdomain.com CSeq: 102 ACK User-Agent: Sipura/SPA3000-3.1.3(GWa) l: 0 By: Matt Jordan (mjordan) 2012-06-04 08:24:16.764-0500 Given the complexity of this - and the fact that several tests have still not captured all of the behavioral changes - a pcap of the traffic that demonstrates this problem is going to be essential to fixing this particular vector. If you're having this problem, *please* attach a pcap, as was requested. By: Matt Jordan (mjordan) 2012-06-04 11:37:41.023-0500 Please attach a pcap illustrating the problem, as well as a DEBUG log with 'sip set debug on' unedited By: Peter Sokolov (peterdoo) 2012-06-05 10:04:38.740-0500 Unfortunatelly I have not enough rights to do pcap on the hosted server. However if you configure the following in sip.conf and extensions.conf you should be able to see the mentioned behavior. Just dial the number configured in extensions.conf (99990 in my example) and hang up after it starts ringing. Asterisk will send CANCEL to the IP 216.207.245.33 instead of the one used in INVITE. sip.conf: [STOut] type=peer host=srvtest.fab.si context=from-test canreinvite=yes qualify=no insecure=port,invite promiscredir=no dtmfmode=rfc2833 nat=no disallow=all allow=ulaw callgroup=1 extensions.conf: exten => 99990,1,Dial(SIP/9999@STOut,60,S(5)) exten => 99990,n,Hangup By: Mark Michelson (mmichelson) 2012-07-06 14:08:54.294-0500 I tried the example you gave and unfortunately the destination was unresponsive, so I could not reproduce the problem. As a follow-up, I'd like to point out that I fixed an error with regards to routing CANCELs and ACKs in revision 369066 of the 1.8 branch. If it is possible for you to update to that revision, please test to see if the problem still persists. If you cannot do so, then try using the newly-available 1.8.14.0-rc2, since it has the fix in it. The fix in question was one where we were misrouting CANCEL, ACK, and follow-up INVITEs with authentication details to the wrong address. In that specific issue, the problem was that the requests were supposed to be routed to a configured outboundproxy, however there are other situations in which the same problem could have occurred. It sounds remarkably similar to your issue, and so I suggest testing. By: Peter Sokolov (peterdoo) 2012-07-17 18:12:55.158-0500 I was out for a few days so could not test this before. With the version 1.8.14.1, the problem is solved. CANCEL and ACK are sent to correct IPs. It seems that now directrtpsetup=yes stopped working, which worked fine with 1.8.12.2. All calls are setup with RTP passing via Asterisk first. Before opening another issue, I will double check that all settings are still correct.