30 Apr
2010
30 Apr
'10
2:25 p.m.
2010/4/30 Jiri Kuthan <jiri(a)iptel.org>rg>:
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*.
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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. 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.