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

[Rohan Mahy <[e-mail]>]

---- Original message ----
>Date: Mon, 10 Sep 2001 08:17:41 -0400
>From: Henning Schulzrinne <[e-mail]>
>Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE
>To: Christer Holmberg <[e-mail]>
>Cc: Jonathan Rosenberg <[e-mail]>, 
[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

agreed

>- We don't know whether there will be methods or cases
>where it might help

Here I disagree.  CANCEL cancels a transaction in progress. 
Bis and guidelines are very explicit now in stating that new 
methods should not have extended delays before responding.  
We have a general model that shows that CANCELing a 
transaction only makes sense for transactions that do not 
have immediate responses.  Only INVITE is allowed to do 
this, so only INVITE transactions can be CANCELed.

I agree that it may be useful to cancel things other than 
transactions, but those are new methods or mechanisms.  
Specifically, SUBSCRIBE and REFER both have ways to cancel 
subscriptions (unsubscriptions) and triggered INVITEs (REFER 
with method=CANCEL).

If I rewrote INVITE/200/ACK into non-protracted transactions 
(say PROPOSE/200 and ACCEPT/200), I would need a new 
mechanism to cancel proposals.  Maybe I would use a new 
method (UNPROPOSE), or maybe I would just rePROPOSE.

So, I know that we can't and shouldn't use the existing 
CANCEL method for anything other than cancelling INVITE 
transactions, but SIP is extensible enough that we will be 
able cancel other things with new methods or mechanisms.

thanks,
-rohan


>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

_______________________________________________
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