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

Iñaki,

I don't understand what the point is of sending, or forwarding, this 
CANCEL. There is nothing left to cancel. The only possibility would be 
if the INVITE had been forked somewhere along the path. But if it had, 
the forking proxy would have seen the 200 and sent a CANCEL on its own. 
So there is no reason for the UAC to send a CANCEL in this case.

	Thanks,
	Paul

Iñaki Baz Castillo wrote:
> 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.
> 
> 
_______________________________________________
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.