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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 17:31:50 -0400

Folks,

This is the first of a series of emails I am going to send in an attempt to
resolve the open issues in bis. Time is running short, and we need to
resolve these things in the next few months. So, I would strongly encourage
active participants on the list to give priority to these threads, rather
than the many other interesting, but ultimately unimportant ones. I myself
am guilty of being baited all the time with these things....

I will start with those issues discussed at IETF 51. I will send notes for
the ones we both agreed upon, and those we didn't. The agreed upon ones
serve the important purpose of making sure the list itself concurs, since
IETF policy is that decisions cannot get made at meetings, only on the
lists. I suspect there will be no controversy on these.

So, here is the first. Issue #7: CANCEL for non-INVITE.

Issue description: Currently, bis allows for CANCEL for all methods, not
just INVITE. This made sense way back when, before we recognized that all
non-INVITE methods really need to complete immediately. However, if all
INVITEs are supposed to complete right away (i.e., the server immediately
generates a response, and shouldn't wait for user input), the usage of
CANCEL becomes a race condition. Whether the response is cancelled or not
depends on whether or not the CANCEL beats the server's generation of a
response. The argument has been made, and its a good one, that specifying a
mechanism thats ALWAYS a race condition is futile.

What is the cost? Some have argued that its nothing, since its harder to
special case INVITE. However, I suspect there is a real cost on the server
side. It now must have logic that tells it how to undo anything it might
have done for a particular method before sending the final response. Yuck.

The one point of contention at the meeting was whether CANCEL is useful for
stopping timed-out transactions. That is, I send a SUBSCRIBE, and never get
a response. After 16s (or whatever it is), I send CANCEL to terminate it,
because I never got a response. However, I think that this is not a good
argument. Since the server is supposed to respond immediately anway, sending
CANCEL won't help trigger a response, since there is clearly some big error
thats preventing the response from coming anyway. Others argued that errors
can happen for lots of reasons, so perhaps the CANCEL will help.

My proposal was that we should deprecate CANCEL for non-INVITE. The benefit
is not even quantifiable, at best, and the cost seems high. Of course, for
backwards compatibility, a server should not complain if it gets a CANCEL
for a non-invite, just respond 200 OK (or even 405 is OK) and thats it. It
should have responded to the request anyway. 

There was mild consensus on this, but some key participants disagreed.
Please, speak up and lets resolve this.

-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: Vijay Gurbani <[email-masked]>
Date: Thu, 23 Aug 2001 09:42:32 -0500

Jonathan Rosenberg wrote:
[...[
> So, here is the first. Issue #7: CANCEL for non-INVITE.
[...]
> My proposal was that we should deprecate CANCEL for non-INVITE.

Jonathan:

If we have as a operating assumption (requirement?) that non-INVITE methods
have to be responded to immediately, then deprectaing CANCEL for these
methods is actually preferable.

Even in the SUBSCRIBE case you mentioned in your email, if the UAS fielding
the SUBSCRIBE "knows" that there maybe delay -- caused by ldap lookups,
user authorization, whatever -- in responding with a 200 OK to the 
SUBSCRIBE, it still must send a 202 Accepted final response right away.  So 
I see little utility in attempting to CANCEL a SUBSCRIBE.

As I pointed out at the London IETF, this issue is somewhat related to 
Issue #138 (to fork or not to fork [non-INVITE requests]).  Since the 
consensus on Issue 138 is that it is okay to fork non-INVITEs, -04bis 
should indicate (in Section 17.4, handling of 2xx responses) that a forking 
proxy need not CANCEL non-INVITE branches on getting a 200 OK for a 
non-INVITE request.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: Kim Liu <[email-masked]>
Date: Thu, 23 Aug 2001 13:12:48 -0400

[deleted]
> Please, speak up and lets resolve this.

Limit CANCEL for INVITE only.  Trying to handle CANCELs
for all/arbitrary methods otherwise is going to be prohibitively
complex task -- it will end up as a bunch of special
cases -- i.e. if CANCEL is allowed for all methods,
how do you treat a CANCEL for a CANCEL?  A CANCEL for
a BYE?  A CANCEL for an ACK?  That's ridiculous --
you automatically end up with more special cases for
handling CANCEL to handle CANCELs for methods where
CANCEL makes no sense.

It's a case of confusing an application specific
signal (trying to stop a service/application started
by another method) with a generic procotol level
signal (CANCEL).  Since only INVITE and BYE can
start/change/stop a call, every other method almost
has to be an application or service specific 
invocation, rather than session affecting -- if
this assumption is made, then CANCEL, as a session
level signal, is not apropriate for halting a
service.

Kim

---

From: Shail Bhatnagar <[email-masked]>
Date: Thu, 23 Aug 2001 15:27:55 -0400

Kim Liu wrote:

My take is that although CANCEL for non-INVITE is academic,
it should be allowed. Main reason is to not make special checks
in the state machine about original method and this CANCEL.

---

From: Kim Liu <[email-masked]>
Date: Thu, 23 Aug 2001 15:46:31 -0400

What special check?

if (cancel.method != INVITE) do_error_respose();

You would have to make checks in any case to validate
the CANCEL from an authentication/authorization level,
to see if the method the CANCEL was referring to actually
existed, etc.  There already have to be places in the
message processing where a CANCEL can be rejected due
to various reasons.

Or, inversely, if CANCEL is allowed for non-INVITEs,
then you have to make a special check to see if the
original method was an INVITE, to send back the 487
until receiving an ACK, etc.

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 30 Aug 2001 01:04:16 -0400

> should have responded to the request anyway. 

The proposal sounds good to me.

If the request was not important, just 
quit sending retries for the request and 
mark the delivery status as unknown/who-cares.

If the request was important, the UAC 
would have had to indefinitely continue 
to send the request or an alternative 
query to find out if the CANCEL actually 
worked.  

If the success or cancellation status of 
a request is deemed important enough, 
how about a new DISCARDORNOTIFY method 
to ensure that the request will be 
discarded if received or a notification 
sent if positively acknowledged? :)