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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Sep 2001 17:01:22 -0400

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, September 02, 2001 5:24 PM
> To: [email-masked]
> Subject: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> (Due to travel, I probably missed some of the discussion, so excuse me
> for re-raising old issues.)
> 
> A few notes:
> 
> - 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).

> 
> - If we don't allow CANCEL for non-INVITE, we have to extend the
> definition of 405 (or define a new status code), since the method *is*
> supported for an INVITE for the same URL. To wit, the current 
> text says:
> 
> "The method specified in the \header{Request-Line} is not allowed for
> the
> address identified by the \header{Request-URI}.  The response {\MUST}
> include an \header{Allow} header field containing a list of valid
> methods for the indicated address."
> 
> Note that this defines the granularity of requests at the URI 
> level, not
> at the method level.
> 

Right. It wasn't the proposal to respond with a 405. Just a 200 OK, in fact.

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

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

-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

_______________________________________________
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: Mon, 10 Sep 2001 09:07:17 +0300

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Sep 2001 08:17:41 -0400

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
- We don't know whether there will be methods or cases where it might
help

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.

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

> > otherwise ignores it. No deletion of state. No generating of a special

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.

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

---

From: Suheel Hussain <[email-masked]>
Date: Mon, 10 Sep 2001 14:52:43 -0400

Christer,
By sending an error code for a CANCEL, does it mean that error-code
should be sent only if I (UA) do not want to process non-INVITE CANCEL?
If yes, then this could lead to backward compatibility problem -- i.e., an
UA running a new version of SIP sending a non-INVITE CANCEL to and
older version UA. For example:

UA new                            UA old
     -------- REFER ----------->
                                       start processing REFER
wait..wait
I want to cancel
REFER
  --------- CANCEL ---------->
                                       sorry I do not know why this cancel
                                       Discard and keep processing REFER
Whew...
I got REFER cancelled -------- REFER processing complete
                                          call transferred

In this case absence of an error-code signifies that CANCEL was
successful; whereas UA-old does not cancels REFER.

How do we handle such conditions?

-- 

Suheel Hussain
[email-masked]
Cisco Work # (919) 392-2312

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 10 Sep 2001 17:00:27 -0400

----- Original Message -----
From: "Suheel Hussain" <[email-masked]>
To: "Christer Holmberg" <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; "'Henning G.
Schulzrinne'" <[email-masked]>; <[email-masked]>
Sent: Monday, September 10, 2001 2:52 PM
Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE

> I got REFER cancelled -------- REFER processing complete
I don't think we would change the requirement to still wait for a final
response to the request. The UA should not think the request is cancelled
unless it gets a 487 final response to the original request. This should not
change even if we allow responses other than 200-OK to a CANCEL. The
response to a CANCEL can tell you the CANCEL was rejected, it cannot tell
you it was successful. Only the 487 can tell you that. If you get a 200-OK,
or some other final response, the CANCEL did not work.

Remember, all transactions complete independently.

> How do we handle such conditions?

We must still get 487 final response to original request to know that the
request has truly been cancelled.