[SR-Users] Wrong handling CANCEL message

[Iñaki Baz Castillo]

2010/4/30 Jiri Kuthan <jiri at 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.


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