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

[Jonathan Rosenberg <[e-mail]>]

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
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip