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

[Christer Holmberg <[e-mail]>]

Hi,

My personal opinion is that we, like Henning said, simply should have a
error code telling "sorry, I can't cancel the specific request". Of
course we can, if needed, also have different error codes for request
that can't be cancelled because a final response has been sent, and
another code for requests that the UAS simply doesn't allow - for any
reason - the UAC to CANCEL.

For example, even if we most likely always will accept a CANCEL for the
initial INVITE, there are many cases where we may not accept a CANCEL
for a re-INVITE. 

Eg, if I receive a re-INVITE to change some codecs, I may not accept a
CANCEL. EVEN if I would be smart enough to remember the previous codecs
it is not even sure that I have resources to change them back. In that
case we would need a code saying "well, I did CANCEL your re-INVITE, but
now I am not able to put the old codecs back, so it would probably be a
good idea to release the whole call". No, I don't think we want that...
Another thinkg would be for the UAS to send a BYE, since it can't put
the codecs back, but I don't think we want that either, so...

Regards,

Christer Holmberg
Ericsson Finland




Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Henning G. Schulzrinne [mailto:[e-mail]]
> > Sent: Sunday, September 02, 2001 5:24 PM
> > To: [e-mail]
> > Subject: [Sip] Open Issue #7: CANCEL for non-INVITE
> >
> >
> > (Due to travel, I probably missed some of the discussion, so excuse me
> > for re-raising old issues.)
> >
> > A few notes:
> >
> > - I think the complexity of CANCEL for non-INVITE on the
> > server side is
> > essentially zero. If you don't implement it, you can either return 481
> > (i.e., the request has already been completed) or 405 (but see below).
> 
> Well, the proposal was pretty much that. It does nothing. Just respond to
> it. The point is that a client MUSTNOT send it anymore (i.e., its deprecated
> as it doesn't do anything useful).
> 
> >
> > - If we don't allow CANCEL for non-INVITE, we have to extend the
> > definition of 405 (or define a new status code), since the method *is*
> > supported for an INVITE for the same URL. To wit, the current
> > text says:
> >
> > "The method specified in the \header{Request-Line} is not allowed for
> > the
> > address identified by the \header{Request-URI}.  The response {\MUST}
> > include an \header{Allow} header field containing a list of valid
> > methods for the indicated address."
> >
> > Note that this defines the granularity of requests at the URI
> > level, not
> > at the method level.
> >
> 
> Right. It wasn't the proposal to respond with a 405. Just a 200 OK, in fact.
> 
> > - Does anything else get simpler if we disallow CANCEL for non-INVITE?
> 
> The thing we want to get rid of is the usage in the client, and the
> processing that, in theory, would need to happen in the server if this was
> more than a no-op. For example, cancelling a SUBSCRIBE or something would
> cause the subscription state to be destroyed, and a 487 to the SUBSCRIBE to
> be sent. With the proposal, the server just 200 OKs the CANCEL, and
> otherwise ignores it. No deletion of state. No generating of a special
> response to SUBSCRIBE.
> 
> >
> > - Under the current model, non-INVITE transactions can have non-zero
> > duration, if you return a 1xx response. Thus, it is at least
> > conceivable
> > that there are methods where the CANCEL could actually accomplish
> > something.
> 
> Well, except that you still need to cotninue retransmitting the request at
> 5s intervals to trigger a response. This is wasteful, and results in slow
> transactions. I had thought that we had agreed as a group that non-INVITE
> requests really needed to be responded to immediately to be effective.
> 
> -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