|Summary:||ASTERISK-12649: Wrong branch on CANCEL after SIP INFO in early dialog|
|Date Opened:||2008-08-27 07:13:47||Date Closed:||2009-01-27 08:21:34.000-0600|
|Environment:||Attachments:||( 0) 13381.patch|
( 1) 13381v2.patch
( 2) verbosedebug2.txt
( 3) WrongBranchInCancel.pcap
A Calls Asterisk IVR
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 :
As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels.
(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
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
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.
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
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 :
188.8.131.52 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.
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
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
13381v2.patch uploaded by putnopvut (license 60)
Tested by: atca_pres
(closes issue ASTERISK-12486)
Reported by: rickead2000
Tested by: rickead2000