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

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

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

> ----------
> From: 	James Undery[SMTP:[e-mail]]
> Sent: 	25 September 2001 14:43
> To: 	Drage, Keith (Keith); 'Henning G. Schulzrinne'; 'Jonathan Rosenberg'
> Cc: 	[e-mail]
> Subject: 	RE: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> 
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:[e-mail]]
> 
> > No problem with the sentiment in the proposed text.
> 
> Agreed.
> 
> >
> > 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.
> 
> Very strongly do not agree. 100s are good for all sorts of
> (authenticated) requests, not just INVITEs.
> 
The text I proposed tries to say that 100s are allowed for all methods, and
1xx (not 100) are only allowed for INVITE or for future methods that
explicitly allow them (the reason for including this text on the CANCEL
thread is that I believe the conditions are one and the same).

I believe we are strongly agreeing.

Have you misread what I wrote, or can it be specified more clearly.

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