2010/4/30 Klaus Darilion klaus.mailinglists@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