Iñaki Baz Castillo wrote:
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?
Ok, if you are only concerned with being clear about this, and not that
it is something of general utility. It seems it doesn't really matter
whether the CANCEL is propagated by the proxy or not, since it is
destined to be a no-op. It would be more efficient to block its
propagation, but given the rarity of the situation I don't think it
really matters.
Thanks,
Paul
_______________________________________________
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.
