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

[Henning Schulzrinne <[e-mail]>]

Part of the problem with this discussion is that we seem to be coming
from two, I believe, valid but different conclusions:

- CANCEL for non-INVITE is not generally useful
- We don't know whether there will be methods or cases where it might
help

My argument is that we don't know what things we need in the future.
Unlike other features, CANCEL is a "socially responsible" extension,
i.e., it does not in any way inconvenience those that have no use for
it. UACs that don't need it can ignore its existence; UASs and proxies
just have to respond like to any other unknown method.

Christer Holmberg wrote:
> 
> 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
> 

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

I see no complexity advantage in that. It would only be sent in
scenarios where it makes sense to the participants, as an optimization.

> >
> > Right. It wasn't the proposal to respond with a 405. Just a 200 OK, in fact.

Responding to a method you don't understand or didn't act on with a 200
seems odd.

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

Again, this is purely consensual. SIP is a tool kit. I like to keep a
few odd tools around, particularly if they don't clutter the basement.
In general, if you don't like or need CANCEL, don't implement it.

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

Again, in almost all circumstances, this is correct. However, this is a
mechanism that may, in terms of messaging complexity, beat alternatives,
such as splitting the transaction into multiple ones. Also, I expect
that this will be the exception for a particular method. In other words,
a very high fraction of requests will complete immediately, but because
of some special circumstance (slow server, special processing, failover,
what have you), an occasional transaction takes longer.

One analogy is ^C in Unix: almost all commands terminate almost
immediately and ^C is not helpful. However, on occasion, a command does
something unexpected and takes much longer (often, because of some
temporary failure such as an NFS volume that disappeared) and it is very
useful to be able to get rid of it. General timeout doesn't help, since
in other cases you want the request to keep trying.

_______________________________________________
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