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

["Rosen, Brian" <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, August 22, 2001 5:32 PM
> To: '[e-mail]'
> 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
> [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
> 

_______________________________________________
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