[asterisk-bugs] [Asterisk 0013381]: Wrong branch on CANCEL after SIP INFO in early dialog

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13381 
====================================================================== 
Reported By:                atca_pres
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13381
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 140115 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-08-27 07:13 CDT
Last Modified:              2008-09-04 10:04 CDT
====================================================================== 
Summary:                    Wrong branch on CANCEL after SIP INFO in early
dialog
Description: 
Scenario :
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 wrong branch

The UA cannot match the INVITE to the CANCEL because the CANCEL does not
have the same branch (via header) that the INVITE had. 
B only ack the CANCEL without sending the required 487 to cancel the
INVITE. B Stays ringing forever. (Granted, answering a 481 to the CANCEL
might be the thing to do, but it's only a SHOULD in the RFC)

Attached is the SIP debug + core and verbose 5 (asterisk -Tvvvvvdddddngc |
tee /tmp/verbosedebug.txt) and an ethereal capture for easier reading.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013198 Asterisk sends a [slightly] different b...
====================================================================== 

---------------------------------------------------------------------- 
 (0092072) atca_pres (reporter) - 2008-09-04 10:04
 http://bugs.digium.com/view.php?id=13381#c92072 
---------------------------------------------------------------------- 
I have found out that the CANCEL also is missing the TO tag in this
scenario.

We can see in the gateway 100 Trying and 180 Ringing a TO tag generated by
the gateway.

The CANCEL should contains the same TO tag that was present in those
answers. The INFO packets contain this TO tag, but for an unknown reason,
the CANCEL doesn't.

Should I open a new issue concerning this second problem with the CANCEL
in this scenario ?

Again from 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)).  [...]

Thank you very much 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-04 10:04 atca_pres      Note Added: 0092072                          
======================================================================