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

["Drage, Keith (Keith)" <[e-mail]>]

No problem with the sentiment in the proposed text.

However, surely the text should also be linked with similar text that talks
about the use of provisional responses, with identical conditions for
support. Something along the lines of:

		Provisional responses are permitted for the INVITE method.
100 provisional responses are permitted for all methods. Provisional
responses (except 100) are not defined for other methods in this
specification. Extensions MAY define other methods for which provisional
responses are useful; those extensions should specify that provisional
responses are allowed and are mandatory if the extension method is
supported.

Keith

Keith Drage
Lucent Technologies
Tel: [phone]
Email: [e-mail]

> ----------
> From: 	Jonathan Rosenberg[SMTP:[e-mail]]
> Sent: 	25 September 2001 7:06
> To: 	'Henning G. Schulzrinne'; James Undery
> Cc: 	[e-mail]
> Subject: 	RE: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Henning G. Schulzrinne [mailto:[e-mail]]
> > Sent: Monday, September 24, 2001 12:45 PM
> > To: James Undery
> > Cc: [e-mail]
> > Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE
> > 
> > 
> > James Undery wrote:
> > > 
> > 
> > > The problem I see here is the difference between complete 
> > immidately,
> > > and the ability to cancel before completion. For example this all
> > > started because of REGISTER, sending 100 then attempting to do the
> > > database magic (possibly over a network) makes sense to restrict
> > > retransmission, yet providing full rollback semantics to allow the
> > > REGISTER to cancel is trickier.
> > 
> > As I have tried to say numerous times before, nobody has to implement
> > CANCEL even under the current state of affairs. 
> 
> That might actually be a bad thing for INVITE. CANCEL is the preferred way
> to hang up a call before a final response since its the only reliable way
> to
> do so. However, if the server doesn't implement it, the call can't be hung
> up. I'd call that an interoperability failure. I think that if a UA
> implements INVITE, it probably needs to implement BYE and CANCEL. 
> 
> 
> If CANCELing 
> > REGISTER is
> > difficult (which seems likely), just don't do it. CANCEL is 
> > advisory, an
> > optimization. Somehow the "doesn't work for all cases" seems to get
> > confused with "it's never useful".
> 
> Indeed, that is the question. If it doesn't always work, is it still
> useful?
> To answer that, you have to think about what it means for cancel to
> "work".
> I can think of several dimensions to this:
> 
> 1. it works because it causes the transaction to complete immediately
> 2. it works because it causes the transaction to generate a 487 response
> 
> Even though CANCEL for INVITE doesn't always "work" for definition (2), it
> always works for definition (1) since it always results in immediate
> completion of the transaction one way or another, so long as the server
> supports CANCEL. Would CANCEL for INVITE be useful if it didn't always
> perform (1)? I'd say no. From a users perspective, it is not acceptable to
> hit "stop" and for nothing to happen.
> 
> 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".
> 
> 
> How is that?
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [e-mail]                     FAX:   [phone]
> http://www.jdrosen.net                      PHONE: [phone]
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip