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@kamailio_IP>;tag=512af75a.
 
SIP/2.0 200 canceling. ...
To: <sip:SIP_CalledPartyNumber@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@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.