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

[Christer Holmberg <[e-mail]>]

Hi,

I agree on this thread. Also, I don't see the problem with this issue,
EVEN if there would be non-INVITE requests in the future that can be
cancelled. The UAC and UAS should know what can be cancelled, and what
can't be, and if the UAC tries to CANCEL something else the UAS simply
returns 400/405/whatever... We could even add some response code saying
"The request can't be cancelled"...

In fact, I am pretty sure the world would have been a better place
without the CANCEL in the first place... 

NOTE: That was NOT a proposal to remove CANCEL from SIP, just my
personal opinion :)

Regards,

Christer Holmberg
Ericsson Finland



Jonathan Rosenberg wrote:
> 
> This thread has again been sidetracked, and I'd like to bring it back.
> 
> I think there is agreement that if the server can't or won't process a
> CANCEL, it simply sends some response to the CANCEL (it really doesn't
> matter whether its a 405, 400 or 200 OK), and continues processing the
> request as if nothing happened. That is always an option, and even though
> not explicitly stated, has always been possible.
> 
> The main source of contention, I think, is whether we think there might be
> future methods that can make use of a CANCEL for non-invite. I agree here
> with Rohan that since all future methods are non-INVITE, and since
> non-INVITE have to complete immediately, they really can't be useful for
> future requests.
> 
> -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
> 
> 
> > -----Original Message-----
> > From: Rohan Mahy [mailto:[e-mail]]
> > Sent: Monday, September 10, 2001 2:05 PM
> > To: Henning Schulzrinne
> > Cc: Christer Holmberg; Jonathan Rosenberg; [e-mail]
> > Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE
> >
> >
> >
> >
> > ---- Original message ----
> > >Date: Mon, 10 Sep 2001 08:17:41 -0400
> > >From: Henning Schulzrinne <[e-mail]>
> > >Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE
> > >To: Christer Holmberg <[e-mail]>
> > >Cc: Jonathan Rosenberg <[e-mail]>,
> > [e-mail]
> > >
> > >Part of the problem with this discussion is that we seem to
> > >be coming from two, I believe, valid but different
> > >conclusions:
> > >
> > >- CANCEL for non-INVITE is not generally useful
> >
> > agreed
> >
> > >- We don't know whether there will be methods or cases
> > >where it might help
> >
> > Here I disagree.  CANCEL cancels a transaction in progress.
> > Bis and guidelines are very explicit now in stating that new
> > methods should not have extended delays before responding.
> > We have a general model that shows that CANCELing a
> > transaction only makes sense for transactions that do not
> > have immediate responses.  Only INVITE is allowed to do
> > this, so only INVITE transactions can be CANCELed.
> >
> > I agree that it may be useful to cancel things other than
> > transactions, but those are new methods or mechanisms.
> > Specifically, SUBSCRIBE and REFER both have ways to cancel
> > subscriptions (unsubscriptions) and triggered INVITEs (REFER
> > with method=CANCEL).
> >
> > If I rewrote INVITE/200/ACK into non-protracted transactions
> > (say PROPOSE/200 and ACCEPT/200), I would need a new
> > mechanism to cancel proposals.  Maybe I would use a new
> > method (UNPROPOSE), or maybe I would just rePROPOSE.
> >
> > So, I know that we can't and shouldn't use the existing
> > CANCEL method for anything other than cancelling INVITE
> > transactions, but SIP is extensible enough that we will be
> > able cancel other things with new methods or mechanisms.
> >
> > thanks,
> > -rohan
> >
> >
> > >My argument is that we don't know what things we need in
> > the future.
> > >Unlike other features, CANCEL is a "socially responsible"
> > extension,
> > >i.e., it does not in any way inconvenience those that have
> > no use for
> > >it. UACs that don't need it can ignore its existence; UASs
> > and proxies
> > >just have to respond like to any other unknown method.
> > >
> > >Christer Holmberg wrote:
> > >>
> > >> Hi,
> > >>
> > >> My personal opinion is that we, like Henning said, simply
> > should have a
> > >> error code telling "sorry, I can't cancel the specific
> > request". Of
> > >> course we can, if needed, also have different error codes
> > for request
> > >> that can't be cancelled because a final response has been
> > sent, and
> > >> another code for requests that the UAS simply doesn't
> > allow - for any
> > >> reason - the UAC to CANCEL.
> > >>
> > >> For example, even if we most likely always will accept a
> > CANCEL for the
> > >> initial INVITE, there are many cases where we may not
> > accept a CANCEL
> > >> for a re-INVITE.
> > >>
> > >> Eg, if I receive a re-INVITE to change some codecs, I may
> > not accept a
> > >> CANCEL. EVEN if I would be smart enough to remember the
> > previous codecs
> > >> it is not even sure that I have resources to change them
> > back. In that
> > >> case we would need a code saying "well, I did CANCEL your
> > re-INVITE, but
> > >> now I am not able to put the old codecs back, so it would
> > probably be a
> > >> good idea to release the whole call". No, I don't think
> > we want that...
> > >> Another thinkg would be for the UAS to send a BYE, since
> > it can't put
> > >> the codecs back, but I don't think we want that either,
> > so...
> > >>
> > >> Regards,
> > >>
> > >> Christer Holmberg
> > >> Ericsson Finland
> > >>
> > >
> > >> > > - I think the complexity of CANCEL for non-INVITE on
> > the
> > >> > > server side is
> > >> > > essentially zero. If you don't implement it, you can
> > either return 481
> > >> > > (i.e., the request has already been completed) or 405
> > (but see below).
> > >> >
> > >> > Well, the proposal was pretty much that. It does
> > nothing. Just respond to
> > >> > it. The point is that a client MUSTNOT send it anymore
> > (i.e., its deprecated
> > >> > as it doesn't do anything useful).
> > >
> > >I see no complexity advantage in that. It would only be
> > sent in
> > >scenarios where it makes sense to the participants, as an
> > optimization.
> > >
> > >> >
> > >> > Right. It wasn't the proposal to respond with a 405.
> > Just a 200 OK, in fact.
> > >
> > >Responding to a method you don't understand or didn't act
> > on with a 200
> > >seems odd.
> > >
> > >> >
> > >> > > - Does anything else get simpler if we disallow
> > CANCEL for non-INVITE?
> > >> >
> > >> > The thing we want to get rid of is the usage in the
> > client, and the
> > >> > processing that, in theory, would need to happen in the
> > server if this was
> > >> > more than a no-op. For example, cancelling a SUBSCRIBE
> > or something would
> > >> > cause the subscription state to be destroyed, and a 487
> > to the SUBSCRIBE to
> > >> > be sent. With the proposal, the server just 200 OKs the
> > CANCEL, and
> > >> > otherwise ignores it. No deletion of state. No
> > generating of a special
> > >> > response to SUBSCRIBE.
> > >
> > >Again, this is purely consensual. SIP is a tool kit. I like
> > to keep a
> > >few odd tools around, particularly if they don't clutter
> > the basement.
> > >In general, if you don't like or need CANCEL, don't
> > implement it.
> > >
> > >> >
> > >> > >
> > >> > > - Under the current model, non-INVITE transactions
> > can have non-zero
> > >> > > duration, if you return a 1xx response. Thus, it is
> > at least
> > >> > > conceivable
> > >> > > that there are methods where the CANCEL could
> > actually accomplish
> > >> > > something.
> > >> >
> > >> > Well, except that you still need to cotninue
> > retransmitting the request at
> > >> > 5s intervals to trigger a response. This is wasteful,
> > and results in slow
> > >> > transactions. I had thought that we had agreed as a
> > group that non-INVITE
> > >> > requests really needed to be responded to immediately
> > to be effective.
> > >> >
> > >
> > >Again, in almost all circumstances, this is correct.
> > However, this is a
> > >mechanism that may, in terms of messaging complexity, beat
> > alternatives,
> > >such as splitting the transaction into multiple ones. Also,
> > I expect
> > >that this will be the exception for a particular method. In
> > other words,
> > >a very high fraction of requests will complete immediately,
> > but because
> > >of some special circumstance (slow server, special
> > processing, failover,
> > >what have you), an occasional transaction takes longer.
> > >
> > >One analogy is ^C in Unix: almost all commands terminate
> > almost
> > >immediately and ^C is not helpful. However, on occasion, a
> > command does
> > >something unexpected and takes much longer (often, because
> > of some
> > >temporary failure such as an NFS volume that disappeared)
> > and it is very
> > >useful to be able to get rid of it. General timeout doesn't
> > help, since
> > >in other cases you want the request to keep trying.
> > >
> > >_______________________________________________
> > >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
> >