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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Sep 2001 02:06:43 -0400

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Monday, September 24, 2001 12:45 PM
> To: James Undery
> Cc: [email-masked]
> 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
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 25 Sep 2001 09:08:00 -0400

> specify that CANCEL is allowed and is mandatory if the extension method is
This is fine with me.

(-:bob

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 25 Sep 2001 15:37:03 +0100

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

Do like it.

 - Jo.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Sep 2001 23:11:35 -0400

> implements INVITE, it probably needs to implement BYE and CANCEL.

I was talking about CANCEL for non-INVITE, since I didn't think CANCEL
for INVITE was up for dismissal.

> hit "stop" and for nothing to happen.

Good. Please stop using Windows immediately (or Linux, for that matter),
as it does not satisfy your requirements. Have you ever tried to
terminate an application with the X in the upper right hand corner and
got no reaction? Seems to happen with some frequency, at least on my W2K
box. Doesn't mean that removing the X would be desirable.

In Netscape, the ESC or Stop button don't always work, for reasons I
don't claim to understand. Should we remove the Stop button?

On Unix systems, all but the kill -9 can be ignored by applications, so
^C doesn't always work. Would you suggest getting rid of ^C?

In a car, brakes don't always work (e.g., on ice). Are you going to
remove them?

I can add lots more silly examples, if you insist :-)

Not having CANCEL means that I have no way to interrupt an
unexpectedly-non-completing transaction, since we unfortunately lack the
equivalent of kill -9 in the Internet, if you discount the various
reboot-this-server protocol extensions added as unintentional features
by certain web server designers.

In general, it is impossible to guarantee that you can stop anything
with any request as you may not be able to get the packet across. I'm
all for explicitness, i.e., an implementation should return 501 or
similar to tell you that it can't do what you asked of it. You're no
worse of than without CANCEL in that case.

> servers have to support cancel for that method.

I disagree. It is useful even if some servers support it, as it gives me
functionality that I wouldn't have otherwise, incomplete as it may be.
Obviously, a specification can mandate CANCEL support for a particular
method, but I don't consider myself clairvoyant enough to know whether
this is appropriate in all circumstances. 

> sending it or not achieves the same result.

Agreed.