2010/4/30 Jiri Kuthan jiri@iptel.org:
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.
That's a bug in the RFC and we shall not better projects RFC bugs in implementations :) A well behaving proxy shall keep the context for some period of time.
Yes, I agree. In fact draft invfix solves it by adding a new state "Accepted" so when a 200 is sent the server transaction remains in memory for a while (to absorbe INVITE retransmissions).
But anyway the transaction is in "Accepted" state, and not in "Proceeding", so a CANCEL should have no effect and the proxy shouldn't reply 200 for the CANCEL as the proxy has canceled *nothing*.
Then the proxy should reply 481 to the CANCEL rather than a 200.
well, once the transaction is gone, forwarding the CANCEL statelessly would seem a legitimiate behaviour, as long as the proxy is in position to produce branch ID consistently with that for INVITE.
Yes, in fact this is the behavior RFC 3261:
16.10 CANCEL Processing [...] If a response context is not found, the element does not have any knowledge of the request to apply the CANCEL to. It MUST statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously).
But again, what does "response context is not found"?:
- In RFC 3261 it means that the transaction server is terminated as per RFC 3261 it is ended when a 200 arrives and is forwarded (immediately).
- But in draft invfix the transaction remains in "Accepted" state upon receipt of a 200 (to absorbe INVITE retransmissions). So the section 16.10 should be rewriten as: "If a response context in state Proceeding is not found, the element does not have any knowledge of the request to apply the CANCEL to."
Regards.