The last I knew, it was *legal* to send a CANCEL for messages other than
INVITE - however it is *futile* to do so.
So sending a CANCEL with a CSeq that matches some request other than an
INVITE is not an error. It should just return a 200 and then it can then
do nothing else. If you acutally had the means to cancel an incomplete
non-INVITE transaction you could do that too, but you would probably be
the first.
Sending a CANCEL for a prior request that has already completed, and for
which no record remains should return a 481. Any CSeq less that the
current cseq, for which no transaction remains, should probably be
treated that way. It could also mean the request being canceled was
lost, for which 481 is also appropriate. A CANCEL with a CSeq greater
than the current cseq can also mean the request was lost and so a 481 is
appropriate. So here I am agreeing with Iñaki.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> El Tuesday 17 June 2008 13:28:42 Iñaki Baz Castillo escribió:
>> El Tuesday 17 June 2008 13:12:09 Suganya D escribió:
>>> Hi,
>>>
>>> Yes, a CANCEL is valid only for an INVITE method.
>>>
>>> Hence when a CANCEL arrives with a CSeq number that does not match
>>> INVITE can it not be considered that a mis-behaving entity is
>>> attempting to CANCEL a non-INVITE transaction?
>> No UAC will send a CANCEL for a non-INVITE transaction. Of course it could
>> occur, and also a UAC could send a request with method CHICKEN XDDD
>>
>> But if I receive a not-matching CANCEL I will consider that the INVITE
>> associated to that CANCEL hasn't arrived yet. So the reply would be 484.
>
> Sorry, I mean 481.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
