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

[Henning Schulzrinne <[e-mail]>]

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

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

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

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.

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

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. 


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

Agreed.

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

_______________________________________________
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