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.
