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

2010/5/2 Paul Kyzivat <[email protected]>:
> 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.

Hi Paul, I do know that the UAC shouldn't send the CANCEL, but it
could occur (race conditions, 200 reply lost in the network...). So
the proxy must know how to behave when a CANCEL arrives for an INVITE
transaction in "Accepted" state, something that doesn't make sense in
the original 3261 specification as the proxy terminates the INVITE
transaction when the 200 arrives (immediately).

I think innfix draft should clarify it: what should do a proxy when a
CANCEL arrives and matches an INVITE transaction in "Accepted" state?


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