[SR-Users] Cancel issue

[Carl Wagner]

Hi,

I was looking at the 3261 again and have a question.

16.10 CANCEL Processing (Proxy Behavior)
    ...  If a matching response context is found, the element MUST
    immediately return a 200 (OK) response to the CANCEL request.  In
    this case, the element is acting as a user agent server as defined in
    Section 8.2.  ...


So Kamailio is acting as a UAS when it receives a CANCEL
We will assume for now that Asterisk properly constructed the CANCEL.

9.2 Server Behavior  (Canceling a Request)
    ...

    Regardless of the method of the original request, as long as the
    CANCEL matched an existing transaction, the UAS answers the CANCEL
    request itself with a 200 (OK) response.  This response is
    constructed following the procedures described in Section 8.2.6
    noting that*the To tag of the response to the CANCEL and the To tag
    in the response to the original request SHOULD be the same.*   ...


By my reading of 9.2, the portion about the To tag,
(In my case)
   1) The Original request is the INVITE.
   2) Response to the original request is a 180 Ringing
   3) Response to the CANCEL is a 200 OK
Therefore the To tag in the 180 Ringing must match the To tag in the 200 OK?

Is this right?
When 3261 says "the response to the original request"  is that the last 
response?

Relevant portions of the log:
SIP/2.0 180 Ringing. ...
To: <sip:SIP_CalledPartyNumber at kamailio_IP>;tag=512af75a.

SIP/2.0 200 canceling. ...
To: 
<sip:SIP_CalledPartyNumber at kamailio_IP>;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34. 


Not sure how this work with forking.

So to my eyes, this looks like a Kamailio bug?
Please tell me where I went wrong.


FYI in Asterisk it is dependent on the pedanticsipchecking being enabled.
This is set in sip.conf:   pedantic=yes

Thanks,
Carl




On 05/25/2011 01:01 PM, Iñaki Baz Castillo wrote:
> 2011/5/25 Carl Wagner<carl.wagner at verbalworld.com>:
>> I am sorry, you are right.   I was looking at rfc3665 Page 71, F10 and it
>> did not have a To: tag in the 200 OK to the cancel.
>> (I know that rfc3665 is just examples, and when in doubt I should use
>> rfc3261)
>>
>> The last paragraph of rfc3261, section 9.2 says to use section 8.2.6 to
>> construct the 200 (OK).
>>
>>
>> Not sure why Asterisk is not liking the 200 Canceling.
>> Does anyone see anything wrong with the Cancel or the 200 Canceling in the
>> log below?
> Because Asterisk is buggy and expects (wrongly) that the Totag of the
> CANCEL must match the Totag of a previously received 1XX response.
> This is of course a wrong assumption as there could be diferent 1XX
> responses with different Totag (when forking).
>
> I remember that it just occurs if you set Asterisk sip.conf with
> pendantic-mode enabled.
>
> Asterisk is buggy.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110808/fd9ab1b1/attachment-0001.htm>