Summary:	ASTERISK-07877: CANCEL is not forwarded to the outbound call leg
Reporter:	hristo (hristo)	Labels:
Date Opened:	2006-10-05 04:22:57	Date Closed:	2006-12-05 11:37:00.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) invitestate-1.4-cancel-after-183.txt ( 1) invitestate-1.4-cancel-after-trying.txt ( 2) sip-debug-cancel-problem.txt
Description:	In the call flow below the CANCEL message is never forwarded to the second call leg and the called party never stops ringing. For accounting purposes I have all inbound and outbound messages routed via openser in front of the asterisk server (not shown below to keep it simple) so the full setup is carrier1<->openser<->asterisk<->openser<->carrier2 Anyway, the simpler version follows: carrier1, asterisk in the middle, carrier2 carrier1 --INVITE--> asterisk --INVITE--> carrier2 carrier1 <--Trying-- asterisk <--Trying-- carrier2 carrier1 <--183/SDP-- asterisk <--183/SDP-- carrier2 carrier1 --CANCEL--> asterisk --> no message is ever sent to carrier2 carrier1 <--487-- asterisk carrier1 <--200-- asterisk carrier1 --ACK--> asterisk The called party eventually picked up the phone (long after the inbound call leg was cleared) and that's the rason for the 200 OK message that is received back from carrier2 at some point at the end of the debug file (not shown in the call flow above). IPs and domain names in the debug are changed. Notes: 1. With 180 (and no SDP) in place of 183 everything in the above scenario works fine and both call legs are terminated properly. 2. Similar problem is observed (even though there is no CANCEL from caller this time) if timeout is specified with the Dial application. &ASTERISK-1048;nce the timeout is reached and there is no answer the call is destroyed but asterisk never sends CANCEL to the called party and it keeps on ringing. Again this only appears if asterisk receives 183/SDP provisional responce - with 180 (no SDP) everything works fine. ****** ADDITIONAL INFORMATION ****** * Seems to be related to 0008036 - a different problem, but still a lot of CANCEL and 183/SDP involved. * The cancel patch posted in 0007492 doesn't solve this problem.
Comments:	By: hristo (hristo) 2006-10-05 04:30:49 The dedug should be easier to read with the following information 192.168.1.123 - openser 192.168.1.124 - asterisk 192.168.1.110 - x-lite (carrier1) 192.168.1.35 - cisco gateway (carrier2) By: Lennon Lim (lennon) 2006-10-05 06:46:17 the problem occur from chan_sip.c revision 43214, change back to 43212 will solve your problem By: mnordstr (mnordstr) 2006-10-10 10:38:45 I am experiencing the same problem. Asterisk 1.4beta2 and calling via a SIP provider. When hanging up the phone, the cancel is sent to Asterisk but Asterisk doesn't forward it to the SIP provider. By: hristo (hristo) 2006-10-29 13:04:20.000-0600 This problem is also partially affecting the 1.2 branch! I say it's partial, because with 1.2 the problem only appears if the CANCEL is sent right after the TRYING message, but not if it's sent after the 183/SDP message. I took some time to investigate and this "partial" problem is first introduced in 1.2 with r38731. Prior to this revision CANCELs are properly forwarded to the second call leg. By: Serge Vecher (serge-v) 2006-10-30 10:39:52.000-0600 is this reproducible in 1.4 r > 46398? By: Olle Johansson (oej) 2006-10-30 15:52:17.000-0600 Please test with latest 1.4 from subversion. thanks. By: Lennon Lim (lennon) 2006-10-30 20:20:18.000-0600 this problem still occur in last svn, it's on chan_sip.c if (ast->_state == AST_STATE_RING || ast->_state == AST_STATE_RINGING) { the logic only check stat_ring and stat_ringing on hristo's case, the first leg's state is ring and the second is down, so asterisk no send canel to second leg. just my discover, i don't know if it is right. By: Olle Johansson (oej) 2006-11-12 13:57:42.000-0600 Please check branch mentioned in issue ASTERISK-7293. Thanks. I need your help testing this in order to solve these related issues. /Olle By: hristo (hristo) 2006-11-12 16:27:41.000-0600 Branch invitestate solves the problem for 1.2 described in note 53322. Since it was branched from 1.2 I cannot really test the originally reported problem, which is for 1.4. As soon as this is resolved for 1.2 and ported to 1.4 I will let you know if it also solves the problem in 1.4. By: hristo (hristo) 2006-11-28 06:45:02.000-0600 In the meantime if anyone can provide patch (or branch) against 1.4 I will be happy to test it and report back. By: hristo (hristo) 2006-12-02 12:21:57.000-0600 I have tested with SVN-oej-invitestate-1.4-r48132 branch and the problem is still present, however if the CANCEL on the inbound leg is sent just after the TRYING message the outbound call leg will be canceled only after the 183 message is received (I am calling a mobile and it actually takes some time between TRYING and 183) - see attached file invitestate-1.4-cancel-after-trying.txt If call is canceled after 183 message, the outbound call leg never gets canceled and mobile keeps on ringing - see the other attached file invitestate-1.4-cancel-after-183.txt. Also sip show peers outputs: Peer             User/ANR    Call ID      Seq (Tx/Rx)  Form  Hold     Last Message 10.0.0.1         1234        2453f5bf236  00102/00000  unkn  No       Init: INVITE It keeps on ringing until it is rejected by the called person (results in busy message being sent back to asterisk) By: Olle Johansson (oej) 2006-12-02 14:34:27.000-0600 This was related to 183 Session progress. Please test latest version of the branch of your choice - invitestate for 1.2 - invitestate-1.4 for 1.4 - trunk for trunk I believe this is fixed. Your urgent reply is really appreciated, so we can close this issue and merge the branches. Thanks. Many thanks to Leif Madsen (Blitzrage) who gave me access to a test system and for placing many test calls. International bug hunting - I'm in Sweden, Leif's in Canada and the server was located in Florida! By: hristo (hristo) 2006-12-02 17:13:43.000-0600 Tested both invitestate and invitestat-1.4 - CANCEL is now always forwarded to the outbound call leg. Thanks! I have noticed something else though: The first "487 Request Cancelled" reply coming in from the outbound leg is ACKed but any "487 Request Cancelled" retransmits are never ACKed - just take a look at the last 3 messages in "invitestate-1.4-cancel-after-trying.txt" attachment. I'm prety sure the reason for the 487 retransmits is elsewhere (probably configuration error in openser, which sits in-front of asterisk), but shouldn't they at least get ACKed by asterisk? If this is a new issue, I'd rather open it as new so you can close this one? By: Leif Madsen (lmadsen) 2006-12-03 21:23:01.000-0600 Excellent! Hristo thanks for testing. Things are still working good here. By: Serge Vecher (serge-v) 2006-12-04 09:14:53.000-0600 hristo: go ahead and open a new bug report for the 487 problem with a new SIP debug attached. Thanks. By: Leif Madsen (lmadsen) 2006-12-04 11:09:06.000-0600 Can't close this quite yet. Found another CANCEL issue with early media. When coming from another Asterisk box (1.2.12.1), I still get ringing without the CANCEL going to the phone it looks like. Will email oej with a trace as it has some sensitive stuff in the trace. By: Leif Madsen (lmadsen) 2006-12-04 11:58:16.000-0600 Oops. My mistake. I had switched back to the 1.4 branch thinking I had seen oej commit this change there, but it was only in trunk. Switched back to invitestate-1.4 branch and everything is (obviously) good again. No issues here! By: Olle Johansson (oej) 2006-12-05 11:36:59.000-0600 Fixed in Asterisk 1.4, svn rev 48270