[asterisk-bugs] [Asterisk 0013440]: No TO tag after SIP INFO in early dialog
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Sep 9 13:43:05 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13440
======================================================================
Reported By: atca_pres
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 13440
Category: Channels/chan_sip/General
Reproducibility: always
Severity: major
Priority: normal
Status: new
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-09-07 15:29 CDT
Last Modified: 2008-09-09 13:43 CDT
======================================================================
Summary: No TO tag after SIP INFO in early dialog
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.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0013381 Wrong branch on CANCEL after SIP INFO i...
======================================================================
----------------------------------------------------------------------
(0092270) putnopvut (administrator) - 2008-09-09 13:43
http://bugs.digium.com/view.php?id=13440#c92270
----------------------------------------------------------------------
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?
Issue History
Date Modified Username Field Change
======================================================================
2008-09-09 13:43 putnopvut Note Added: 0092270
======================================================================
More information about the asterisk-bugs
mailing list