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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Sep 2001 23:39:05 -0400

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
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Monday, September 10, 2001 2:05 PM
> To: Henning Schulzrinne
> Cc: Christer Holmberg; Jonathan Rosenberg; [email-masked]
> Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> 
> 
> ---- Original message ----
> >Date: Mon, 10 Sep 2001 08:17:41 -0400
> >From: Henning Schulzrinne <[email-masked]>
> >Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE
> >To: Christer Holmberg <[email-masked]>
> >Cc: Jonathan Rosenberg <[email-masked]>, 
> [email-masked]
> >
> >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 [email-masked] for questions on 
> current sip
> >Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Sep 2001 11:34:22 +0300

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 21 Sep 2001 21:22:51 -0400

> "The request can't be cancelled"...

I don't understand this paragraph. Unless I'm misunderstanding the whole
discussion, the proposal is that it will be illegal in the future to
send a CANCEL for any non-INVITE request and it will be illegal for any
SIP device to implement CANCEL for non-INVITE. (It's always been legal
for UAS to not implement CANCEL.)

> without the CANCEL in the first place...

Well, nobody has to support it.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 21 Sep 2001 21:17:30 -0400

> non-INVITE have to complete immediately, they really can't be useful for

If that is indeed the choice, then we should remove 1xx responses for
non-INVITE requests. As long as there are 1xx responses, non-INVITE
requests can sometimes not complete immediately.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 24 Sep 2001 19:26:02 +0300

Hello,

> requests can sometimes not complete immediately.

I agree with this. Let's define CANCEL for non-INVITEs as a "do nothing"
on the server side and let's remove 1xx responses for non-INVITEs.

Then, for backwards compatibility, my understanding is that a "200 OK"
for a CANCEL just means "I have received the CANCEL. You can stop
retransmitting it". It does not imply that we are trying to cancel
anything. In fact, if a UAS responds with a 2xx an INVITE request and
later it receives a CANCEL, it still answers the CANCEL with a 200 OK.

Therefore, if an old UAC still sends a CANCEL for a non-INVITE request,
a "200 OK" response for the CANCEL seems appropriate to me.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 24 Sep 2001 12:25:55 -0400

> on the server side and let's remove 1xx responses for non-INVITEs.

We still need at least 100's to stop retransmissions when proxying
non-INVITEs, no?

Anders

---

From: "James Undery" <[email-masked]>
Date: Mon, 24 Sep 2001 17:34:41 +0100

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Gonzalo
> Camarillo
> Hello,
>

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.

> a "200 OK" response for the CANCEL seems appropriate to me.

I'd agree with this just not getting rid of 100s for non-INVITEs

James Undery

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 24 Sep 2001 12:44:47 -0400

James Undery wrote:

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

There are three possible views of the non-INVITE world:

(1)everything must complete immediately (i.e., within 500 ms) -> no
1xx, no CANCEL

(2) most non-INVITE complete immediately almost all the time, but on
occasion they don't
  (2a) but these things are never cancellable (whether with CANCEL or
something else)
  (2b) for some cases, they are cancellable

I've argued for 2b, simply because I can't rule out this case and since
it seems to reflect reality in other spheres of life.

CANCEL makes sense for view 2b, although it has been argued that you
could also devise a new method for methods where 2b holds. (However,
that clearly only works if overlapping transactions are allowed.) That
is an approximation to CANCEL, but not quite functionally equivalent,
due to the different forking proxy behavior.

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 24 Sep 2001 13:21:02 -0400

From: "James Undery" <[email-masked]>
> I'd agree with this just not getting rid of 100s for non-INVITEs
I agree. Let proxies send 100s to non-INVITEs.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Sep 2001 07:50:42 +0300

Hi,

I STILL don't see why this is a big issue at all.

No matter what request the UAC tries to CANCEL, the response to that
request will indicate if the request was canceled or not. 487 (Request
Terminated) means that the request was canceled, another response code
means it wasn't. Like I said before, it is not even sure the UAS will
allow one to CANCEL an INVITE either (especially not a re-INVITE, I
would assume).

However, if we want to allow CANCEL only for INVITEs, that's fine.

Regards,

Christer Holmberg
Ericsson Finland