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

[Jonathan Rosenberg <[e-mail]>]

 

> -----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