Re: [Sip] Open Issue #7: CANCEL for non-INVITE

"Jonathan Rosenberg" <jdrosen@dynamicsoft.com> wrote:
>
> So, I would propose to define the CANCEL for a method "works" if it always
> (under reasonable network conditions) results in rapid completion of the
> transaction, whether it is success (because the 2xx and CANCEL pass on the
> wire), or failure (including 487).
>
> If this definition is suitable, then we can draw some conclusions:
>
> 1. If a non-INVITE transaction is protracted, CANCEL is only useful if all
> servers have to support cancel for that method.
>
> 2. If a non-INVITE transaction is not protracted, CANCEL is a no-op since
> sending it or not achieves the same result.
>
> So, let me propose the following compromise text based on these
conclusions:
>
> "Servers that implement INVITE MUST support CANCEL for INVITE
transactions.
> CANCEL is not defined for other methods in this specification. Extensions
> MAY define other methods for which CANCEL is useful; those extensions
should
> specify that CANCEL is allowed and is mandatory if the extension method is
> supported".
>
This is fine with me.

(-:bob


_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip