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

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@lucent.com]

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

James

> Keith
>
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com
>
> > ----------
> > From: 	Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com]
> > Sent: 	25 September 2001 7:06
> > To: 	'Henning G. Schulzrinne'; James Undery
> > Cc: 	sip@ietf.org
> > Subject: 	RE: [Sip] Open Issue #7: CANCEL for non-INVITE
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > Sent: Monday, September 24, 2001 12:45 PM
> > > To: James Undery
> > > Cc: sip@ietf.org
> > > 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
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > 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 sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip