Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)

Hi, RFC 3261 clearly states that an INVITE transaction is terminated
upon receipt of a 200. So let's imagine a proxy between alice and bob:

- alice sends INVITE to the proxy.
- The proxy relays it to bob.
- bob replies 200.
- The proxy relays the 200 to alice and terminates the INVITE transaction.
- For some reason alice sends now a CANCEL.
- The proxy doesn't match a transaction for this CANCEL so it would
relay it statelessly as section 16.10 states:

   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).


This makes sense because such "response context" doesn't exist after
the 200 was processed by the proxy. However "invfix" draft adds a new
state "Accepted" so when the proxy relays the 200 the transaction
remains in "Accepted" state for a while. What should happen then if
the UAC sends a CANCEL? does the "response context" still exist or
not?

So I suggest that "invfix" draft also changes the section 16.10 of RFC 3261:

   If no transaction in proceeding state is 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).


This is, even if the transaction still exists (under "Accepted" state)
the proxy has nothing to CANCEL so it shouldn't reply 200 to the
CANCEL. Instead it should forward it statelessly. I think this
requires some clarification in the original specification of the RFC
3261.

Best regards.


-- 
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use [email protected] for questions on how to develop a SIP implementation.
Use [email protected] for new developments on the application of sip.
Use [email protected] for issues related to maintenance of the core SIP specifications.