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

[Kim Liu <[e-mail]>]

Jonathan Rosenberg wrote:
[deleted]
> 
> 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.

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

_______________________________________________
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