Summary:	ASTERISK-12693: No TO tag after SIP INFO in early dialog
Reporter:	atca_pres (atca_pres)	Labels:
Date Opened:	2008-09-07 15:29:10	Date Closed:	2008-09-10 11:10:25
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) verbosedebug2.txt ( 1) WrongBranchInCancel.pcap
Description:	A Calls Asterisk IVR IVR answers A enters B's ext A pushes a DTMF while B is ringing A hangs up in SIP : A INVITES Asterisk Asterisk 200OK (IVR) Asterisk INVITES B B sends 180 Ringing A sends SIP INFO Asterisk sends SIP INFO to B A BYEs Asterisk Asterisk sends CANCEL with no TO Tag The UA cannot match the INVITE to the CANCEL because the CANCEL does not have the TO tag that was in the provisional responses (100 trying and 180 ringing). B only ack the CANCEL without sending the required 487 to cancel the INVITE. B Stays ringing forever. Attached is the SIP debug + core and verbose 5 (asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt) and an ethereal capture for easier reading. ****** ADDITIONAL INFORMATION ****** The RFC is not very clear on the CANCEL issue, but here is what I found in the RFC : 8.2.6.2 Headers and Tags   [...]   If a request contained a To tag in the request, the To header field   in the response MUST equal that of the request. However, if the To   header field in the request did not contain a tag, the URI in the To   header field in the response MUST equal the URI in the To header   field; additionally, the UAS MUST add a tag to the To header field in   the response (with the exception of the 100 (Trying) response, in   which a tag MAY be present). This serves to identify the UAS that is   responding, possibly resulting in a component of a dialog ID. The   same tag MUST be used for all responses to that request, both final   and provisional (again excepting the 100 (Trying)). [...]
Comments:	By: atca_pres (atca_pres) 2008-09-07 15:30:40 Hi, This is somewhat related to the issue 13381. (Wrong branch in the same conditions) Thank you very much By: Mark Michelson (mmichelson) 2008-09-09 13:43:05 Hmm, I found where RFC 3261 is more explicit about this information. Section 9.1: "A CANCEL request SHOULD NOT be sent to cancel a request other than   INVITE.      Since requests other than INVITE are responded to immediately,      sending a CANCEL for a non-INVITE request would always create a      race condition.   The following procedures are used to construct a CANCEL request.  The   Request-URI, Call-ID, *To*, the numeric part of CSeq, and From header   fields in the CANCEL request MUST be identical to those in the   request being cancelled, *including tags*." I've added the emphasis myself. Just to make it clear, a CANCEL has to exactly match the To header of the request it is cancelling, including the tags. Since the INVITE contained no To tag, the CANCEL also must not have a To tag. If your UA or proxy is rejecting the CANCEL because of a missing To tag, then it is violating the RFC. Are you sure this is why the problem is occurring? By: Mark Michelson (mmichelson) 2008-09-09 15:27:18 I have a new hypothesis on what may be causing the problem. I think the problem is that the CANCEL has a lower Cseq number than the preceding INFO request. If I'm correct, then there are several open issues all dealing with a similar problem, the root of which is that Asterisk does not gracefully handle multiple simultaneous transactions in a single dialog. The basic issue is that if two outgoing transactions occur, then Asterisk will ignore the response to the request with the lower Cseq number. To confirm that this is the problem you are experiencing, if you can turn on SIP history, you should see lines that say "Ignoring this retransmit" when this failure occurs. By: atca_pres (atca_pres) 2008-09-09 19:54:12 Hi putnopvut, In fact I did a tcl script and if the cancel has the TO tag (that was in the 180 ringing), the call is cancelled sucessfully. After what you just told me, I'm guessing this is a gateway issue. I will open an incident with them. I will check if I have "Ignoring this retransmit", but I'm pretty sure it's the TO tag. Thank you VERY much for all this. By: Mark Michelson (mmichelson) 2008-09-10 11:10:22 All right. I'll go ahead and close this issue. If it turns out there is a problem with Asterisk in this scenario, please feel free to open a bug about it.