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

[Jonathan Rosenberg <[e-mail]>]

 

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[e-mail]]
> Sent: Monday, September 24, 2001 12:45 PM
> To: James Undery
> Cc: [e-mail]
> Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> James Undery wrote:
> > 
> 
> > The problem I see here is the difference between complete 
> immidately,
> > and the ability to cancel before completion. For example this all
> > started because of REGISTER, sending 100 then attempting to do the
> > database magic (possibly over a network) makes sense to restrict
> > retransmission, yet providing full rollback semantics to allow the
> > REGISTER to cancel is trickier.
> 
> As I have tried to say numerous times before, nobody has to implement
> CANCEL even under the current state of affairs. 

That might actually be a bad thing for INVITE. CANCEL is the preferred way
to hang up a call before a final response since its the only reliable way to
do so. However, if the server doesn't implement it, the call can't be hung
up. I'd call that an interoperability failure. I think that if a UA
implements INVITE, it probably needs to implement BYE and CANCEL. 


If CANCELing 
> REGISTER is
> difficult (which seems likely), just don't do it. CANCEL is 
> advisory, an
> optimization. Somehow the "doesn't work for all cases" seems to get
> confused with "it's never useful".

Indeed, that is the question. If it doesn't always work, is it still useful?
To answer that, you have to think about what it means for cancel to "work".
I can think of several dimensions to this:

1. it works because it causes the transaction to complete immediately
2. it works because it causes the transaction to generate a 487 response

Even though CANCEL for INVITE doesn't always "work" for definition (2), it
always works for definition (1) since it always results in immediate
completion of the transaction one way or another, so long as the server
supports CANCEL. Would CANCEL for INVITE be useful if it didn't always
perform (1)? I'd say no. From a users perspective, it is not acceptable to
hit "stop" and for nothing to happen.

So, I would propose to define the CANCEL for a method "works" if it always
(under reasonable network conditions) results in rapid completion of the
transaction, whether it is success (because the 2xx and CANCEL pass on the
wire), or failure (including 487).

If this definition is suitable, then we can draw some conclusions:

1. If a non-INVITE transaction is protracted, CANCEL is only useful if all
servers have to support cancel for that method.

2. If a non-INVITE transaction is not protracted, CANCEL is a no-op since
sending it or not achieves the same result.

So, let me propose the following compromise text based on these conclusions:

"Servers that implement INVITE MUST support CANCEL for INVITE transactions.
CANCEL is not defined for other methods in this specification. Extensions
MAY define other methods for which CANCEL is useful; those extensions should
specify that CANCEL is allowed and is mandatory if the extension method is
supported".


How is that?

-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