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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 23 Aug 2001 09:55:20 -0400

In the interests of moving things along, the chairs will call
consensus on these issues explicitly.  If you object, PLEASE
speak up, so that we can try to see if/when objectors are
satisfied.  

Jonathan, poke us if we don't call consensus when you think
we have it, but let us make the call.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 5:32 PM
> To: [email-masked]'
> Subject: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> 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
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Aug 2001 03:20:07 -0400

> From: Shail Bhatnagar [mailto:[email-masked]]
> Sent: Thursday, August 23, 2001 3:28 PM
> To: Kim Liu
> Cc: Jonathan Rosenberg; [email-masked]'
> Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> 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.

This argument would be true if the cost of the CANCEL for non-INVITE was
otherwise nil. But, thats not true. What happens if the CANCEL actually
beats the server to sending the final response? Now, you have to actually
cancel it. How does one CANCEL a SUBSCRIBE? A NOTIFY? An OPTIONS? Each
method would need special code. 

Furthermore, since its usage is always a race condition, an entity that
sends CANCEL would always need to handle the case where the cancel works and
doesn't work. Thus, its extra work to do this.

Note that I have stipulted that for backwards compatibility, if you get a
CANCEL for non-INVITE, you still respond to it, but otherwise do nothing. In
that sense, its "allowed", but we explicitly define it as a no-op.

-Jonathan R.
---