[SR-Users] Wrong handling CANCEL message

[Iñaki Baz Castillo]

2010/4/30 Klaus Darilion <klaus.mailinglists at pernau.at>:
>> I don't agree. As per RFC 3261 when a proxy receives a 200 for an
>> INVITE the transaction is terminated so a CANCEL after the 200 should
>> not match such transaction. Then the proxy should reply 481 to the
>> CANCEL rather than a 200.
>
>
>   If the transaction
>   for the original request still exists, the behavior of the UAS on
>   receiving a CANCEL request depends on whether it has already sent a
>   final response for the original request.
>
> This means that the transaction may still exists although the 200 OK was
> already sent (to absorb retransmissions)

No, in RFC 3261 a INVTE transaction ends after a 200 is received,
there is no state to absorbe retransmissions.
In draft invfix the transaction is not inmediately removed upon
receipt of a 200, instead it gets into a new "Accepted" state which
allows absorbing ***INVITE*** retransmissions.

But anyway, if the INVITE has been replied with a 200 it makes no
sense at all to send a CANCEL so the proxy shouldn't reply 200 to the
CANCEL, but a 481.





>   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.
>
> So 200 OK is fine. If it makes sense is a different point.

Again, RFC 3261 states that the transaction MUST be terminated when
the 200 arrives so the CANCEL after it shouldn't match the
transaction.
In case of draft invfix, IMHO it has a bug in the specification (still
a draft) since it says nothing aobut the CANCEL. It doesn't make sense
that a proxy or UAS replies 200 to a CANCEL if the proxy or UAS
already sent a 200 for the INVITE.


draft invfix: http://tools.ietf.org/html/draft-ietf-sipcore-invfix-01


-- 
Iñaki Baz Castillo
<ibc at aliax.net>