[Home]

Summary:ASTERISK-12649: Wrong branch on CANCEL after SIP INFO in early dialog
Reporter:atca_pres (atca_pres)Labels:
Date Opened:2008-08-27 07:13:47Date Closed:2009-01-27 08:21:34.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 13381.patch
( 1) 13381v2.patch
( 2) verbosedebug2.txt
( 3) WrongBranchInCancel.pcap
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.

****** ADDITIONAL INFORMATION ******

RFC states that :
(8.1.1.7 Via)
As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels.
AND
(9.1 UAC Behavior)
A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled.
Comments:By: atca_pres (atca_pres) 2008-08-27 08:00:06

Can I respecfully ask that the verbosedebug.txt be removed from this issue ?

Please consider only verbosedebug2.txt

Thank you
By: Leif Madsen (lmadsen) 2008-08-27 11:09:27

File removed per reporters request.
By: Mark Michelson (mmichelson) 2008-08-29 14:18:34

Yes, it would appear that the branch is the same as what was in the INFO request that Asterisk sent instead of the INVITE. I haven't looked at the code too closely, but I'm guessing that Asterisk's SIP stack assumes that no requests will be sent to the far end between the INVITE and CANCEL messages and so there's no need to cache the branch from the INVITE. I'll look and see about coming up with a fix for this.
By: Mark Michelson (mmichelson) 2008-08-29 14:48:06

I have uploaded 13381.patch.
With this, we cache the branch calculated on the initial INVITE request that we send. Whenever we send a CANCEL, we use this branch instead of whatever the branch was for the latest transaction.

Please test to see if this corrects the error you were seeing.
By: atca_pres (atca_pres) 2008-08-30 09:57:08

Thank you putnopvut for this quick patch.

I will be testing this patch this week.
By: atca_pres (atca_pres) 2008-09-02 13:51:29

Hi putnopvut,

I tested the attached patch, but the branch in the CANCEL is the same as the branch in the last SIP INFO.

My guess was that this line is executed for SIP INFO as well :
p->invite_branch = p->branch;

So I added a if (req.method == SIP_INVITE) just before it, no success, same behavior.

My other hypothesis is that this modify the branch as well :
if (sipmethod == SIP_CANCEL)
               c = p->initreq.rlPart2; /* Use original URI */

I'm sorry if this isn't clear.

Thank you
By: Mark Michelson (mmichelson) 2008-09-03 16:00:31

Thanks for the suggestions. I'll take a closer look about what could be causing the branch to not be correct.
By: Mark Michelson (mmichelson) 2008-09-03 16:05:34

It appears that I was checking the wrong variable when attempting to find what type of SIP request was being sent in the function reqprep(). After doing some debugging, the code is actually coming to the correct area when a CANCEL is sent. Please test 13381v2.patch to see if this now fixes the problem. Thanks!
By: atca_pres (atca_pres) 2008-09-04 08:55:39

Hi putnopvut,

This last patch keeps the good branch ! However, my gateway still refuses the CANCEL and states it as out-of-dialog.

I will investigate if this is a gateway issue or not.

Thank you very much
By: atca_pres (atca_pres) 2008-09-04 10:04:16

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
By: Leif Madsen (lmadsen) 2008-09-06 13:22:14

atca_pres: yes, please create a new issue if the issue described in this bug has been resolved.

You can link back a relation to this bug if you wish once you've opened it.

Thanks!
By: Mark Michelson (mmichelson) 2008-09-09 14:02:28

Since this patch appears to be in good order and working properly, I'm going to commit it and close this issue. Thanks for testing the patch for me!
By: Digium Subversion (svnbot) 2008-09-09 14:06:08

Repository: asterisk
Revision: 142218

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r142218 | mmichelson | 2008-09-09 14:06:08 -0500 (Tue, 09 Sep 2008) | 14 lines

Make sure that the branch sent in CANCEL requests
matches the branch of the INVITE it is cancelling.

(closes issue ASTERISK-12649)
Reported by: atca_pres
Patches:
     13381v2.patch uploaded by putnopvut (license 60)
Tested by: atca_pres

(closes issue ASTERISK-12486)
Reported by: rickead2000
Tested by: rickead2000


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=142218