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

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 02 Sep 2001 17:23:45 -0400

(Due to travel, I probably missed some of the discussion, so excuse me
for re-raising old issues.)

A few notes:

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

- If we don't allow CANCEL for non-INVITE, we have to extend the
definition of 405 (or define a new status code), since the method *is*
supported for an INVITE for the same URL. To wit, the current text says:

"The method specified in the \header{Request-Line} is not allowed for
the
address identified by the \header{Request-URI}.  The response {\MUST}
include an \header{Allow} header field containing a list of valid
methods for the indicated address."

Note that this defines the granularity of requests at the URI level, not
at the method level.

- Does anything else get simpler if we disallow CANCEL for non-INVITE?

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

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Mon, 10 Sep 2001 11:04:42 -0700

---- Original message ----
>Date: Mon, 10 Sep 2001 08:17:41 -0400
>From: Henning Schulzrinne <[email-masked]>
>Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE
>To: Christer Holmberg <[email-masked]>
>Cc: Jonathan Rosenberg <[email-masked]>, 
[email-masked]
>
>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
>> > 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.
>> > 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.
>> > > duration, if you return a 1xx response. Thus, it is 
at least
>> > > conceivable
>> > 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.
>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 17 Sep 2001 12:41:19 +0100

This thread is telling me that as well as CANCEL being an open issue for the
bis draft, it is also an open issue for the refer draft.

REFER certainly seems to be defined in an open ended fashion at the moment.

3.6.1 specifies the following:

A UA receiving a well-formed REFER request SHOULD request approval
   from the user to proceed (this request could be interactive or
   through configuration).  Upon receiving approval from the user, the
   UA MUST contact the resource identified by the URL in the Refer-To:
   header.  Note that if the URL is a SIP URL, it could contain header
   fields such as Call-Id that may be used to form the resulting
   request.  If the URL is a SIP URL, the Referred-By header in the
   REFER request should be copied into the request sent to the referred-
   to resource.

If this requires human interaction, then I would expect any duration to
exist from about 5s through to 180s. 

During this time, there seems to be no provision for the sender to be sent
anything (no mention of provisional responses for REFER - do they exist?). 

The current text seems to indicate that CANCEL should be used from the
sending end if an included Expires header is exceeded. 

I could find no text that extends the procedures that extend the Expires
header to methods other than INVITE or REGISTER although the tables in the
refer draft indicate that it is optional for REFER requests.

I could find no text that specifies what either the sender or receiver think
if the Expires header is not included. Do they wait for ever?

I'm sure I have missed some things here in looking for procedures. Would
anybody like to give a summary of how the sender and receiver react to
absence of response for the REFER method. I am convinced that either the bis
draft or the refer draft needs to tell more of the story.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Bob Penfield[SMTP:[email-masked]]
> Sent: 	10 September 2001 22:00
> To: 	Suheel Hussain; Christer Holmberg
> Cc: 	Jonathan Rosenberg; 'Henning G. Schulzrinne'; [email-masked]
> ----- Original Message -----
> From: "Suheel Hussain" <[email-masked]>
> To: "Christer Holmberg" <[email-masked]>
> Cc: "Jonathan Rosenberg" <[email-masked]>; "'Henning G.
> Schulzrinne'" <[email-masked]>; <[email-masked]>
> Sent: Monday, September 10, 2001 2:52 PM
> > Christer,
> > By sending an error code for a CANCEL, does it mean that error-code
> > should be sent only if I (UA) do not want to process non-INVITE CANCEL?
> > If yes, then this could lead to backward compatibility problem -- i.e.,
> an
> > UA running a new version of SIP sending a non-INVITE CANCEL to and
> > older version UA. For example:
> >
> > UA new                            UA old
> >      -------- REFER ----------->
> >                                        start processing REFER
> > wait..wait
> > I want to cancel
> > REFER
> >   --------- CANCEL ---------->
> >                                        sorry I do not know why this
> cancel
> >                                        Discard and keep processing REFER
> > Whew...
> > I got REFER cancelled -------- REFER processing complete
> >                                           call transferred
> >
> I don't think we would change the requirement to still wait for a final
> response to the request. The UA should not think the request is cancelled
> unless it gets a 487 final response to the original request. This should
> not
> change even if we allow responses other than 200-OK to a CANCEL. The
> response to a CANCEL can tell you the CANCEL was rejected, it cannot tell
> you it was successful. Only the 487 can tell you that. If you get a
> 200-OK,
> or some other final response, the CANCEL did not work.
> 
> Remember, all transactions complete independently.
> 
> > In this case absence of an error-code signifies that CANCEL was
> > successful; whereas UA-old does not cancels REFER.
> >
> > How do we handle such conditions?
> 
> We must still get 487 final response to original request to know that the
> request has truly been cancelled.
> 
> >
> > 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
> > >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
> > >
> > >
> > >
> > >
> > >Jonathan Rosenberg wrote:
> > >
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: Henning G. Schulzrinne [mailto:[email-masked]]
> > >>>Sent: Sunday, September 02, 2001 5:24 PM
> > >>>To: [email-masked]
> > >>>Subject: [Sip] Open Issue #7: CANCEL for non-INVITE
> > >>>
> > >>>
> > >>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
> > >>Right. It wasn't the proposal to respond with a 405. Just a 200 OK, in
> fact.
> > >>
> > >>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.
> > >>
> > >>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.
> > >>
> > >>-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
> > >>
> > Suheel Hussain
> > [email-masked]
> > Cisco Work # (919) 392-2312
> >
> >
> >
> 
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 17 Sep 2001 09:21:53 -0400

Keith -

The text below doesn't imply the UA should wait for the
human loop to close before replying to the REFER request.
The REFER transaction itself must complete almost immediately,
hence the change several months ago to the 202 response 
followed by a subsequent notify letting the REFERer know what
the result of the REFERed action (which, if a UA doesn't have
a user's policy coded into it, could be a 603 declined because
the user said no).

Its an understandable misread though - the way you interpreted
it was in fact the original intent _way_ back when before we
spotted that we had to complete the transaction in non-INVITE
time.

I'll see if I can make the text less likely to mislead someone
in the future. On a first pass, changing the first occurance of
"recieving" to "accepting" may be sufficient.

RjS

> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Monday, September 17, 2001 6:41 AM
> To: [email-masked]
> Subject: RE: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> > > >>>(Due to travel, I probably missed some of the 
> discussion, so excuse
> > me
> > > >>>essentially zero. If you don't implement it, you can 
> either return
> > 481
> nothing. Just respond
> (i.e., its
> > > >>>definition of 405 (or define a new status code), since 
> the method
> > *is*
> Just a 200 OK, in
> server if this
> or something
> and results in

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 17 Sep 2001 18:43:51 +0100

So, given this (for the refer draft) - 

A 202 response to REFER says "I know about refer and know how to handle one,
but I do not yet know whether I will issue an INVITE or not." Perhaps we can
get the sense of the above into the first paragraph of section 3.5.
Alternatively, as we do define a new status-code, maybe the refer draft
should contain a section equivalent to 11.2.1 in the bis draft defining this
new status-code, and it could be included there.

The original sender of the REFER then relies on receipt of the NOTIFY to
know if the request has been actioned or not.

Editorial note: I have failed to understand the distinction between the
material in section 3.5 and section 3.6. Section 3.6 is UA procedures, and
3.5 just seems to be more of them.

Further question: Given that responses should be nearly immediate, why do we
need an Expires header in REFER (see section 3.3). (Expires is currently
only defined for INVITE and REGISTER).

Editorial note: Can we have a table number for this table in section 3.3.

Perhaps we also need to say that REFER does not allow provisional responses.

Further question: Does the 202 status-code, although defined in the refer
draft, apply to other methods other than REFER, or in your view does it only
apply to REFER.

Keith
 
Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Robert Sparks[SMTP:[email-masked]]
> Sent: 	17 September 2001 14:21
> To: 	'Drage, Keith (Keith)'; [email-masked]

---

From: Robert Sparks <[email-masked]>
Date: Mon, 17 Sep 2001 14:17:42 -0400

inline

> Sent: Monday, September 17, 2001 12:44 PM
> To: Drage, Keith (Keith); [email-masked]; 'Robert Sparks'

We can do this (but see below)

> new status-code, and it could be included there.

This is done in sip-events

> know if the request has been actioned or not.

_IF_ the UA has enough information to know it won't try the
referred action (for instance, the REFER might be to an rtsp:
URL and the UA doesn't support rtsp:, or it could be to a
SIP INVITE URL which is blacklisted at the phone), it can 
return a non-200 to the REFER request itself.

> 3.5 just seems to be more of them.

Good observation. 3.5 has evolved to be only behavior, so I'll
move it to the first section of 3.6.

> only defined for INVITE and REGISTER).

It's also defined for SUBSCRIBE, but I don't think we want
to inherit that meaning here. I'll edit the 3.3 table accordingly.

> Editorial note: Can we have a table number for this table in 

Done.

> Perhaps we also need to say that REFER does not allow 

The REFER spec doesn't need to say anything about this -
REFER needs to behave like any other non-INVITE transaction
where this is concerned. The normative text will be in the
core specification.

Note that even though non-INVITEs should be completing quickly,
allowing 100 is still important for UDP to quench retransmits
for latent links.

> draft, apply to other methods other than REFER, or in your 

As mentioned before, this is in sip-events.

> > > > > >>>(i.e., the request has already been completed) or 
> 405 (but see
> > > > below).
> > > > > >>>
> > > > > >>>supported for an INVITE for the same URL. To wit, 
> the current
> > > > > >>>text says:
> > > > > >>>
> > > > > >>>Note that this defines the granularity of requests 
> at the URI
> > > > > >>>level, not
> > > > > >>>at the method level.
> > > > > >>>
> > > > > >>>duration, if you return a 1xx response. Thus, it 
> is at least
> > > > > >>>conceivable
> retransmitting the
> group that

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 26 Sep 2001 10:47:54 +0100

See below
Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	James Undery[SMTP:[email-masked]]
> Sent: 	25 September 2001 14:43
> To: 	Drage, Keith (Keith); 'Henning G. Schulzrinne'; 'Jonathan Rosenberg'
> Cc: 	[email-masked]
> > No problem with the sentiment in the proposed text.
> 
> Agreed.
> 
> >
> > However, surely the text should also be linked with similar
> > text that talks
> > about the use of provisional responses, with identical
> > conditions for
> > support. Something along the lines of:
> >
> > 		Provisional responses are permitted for the
> > INVITE method.
> > 100 provisional responses are permitted for all methods. Provisional
> > responses (except 100) are not defined for other methods in this
> > specification. Extensions MAY define other methods for
> > which provisional
> > responses are useful; those extensions should specify that
> > provisional
> > responses are allowed and are mandatory if the extension method is
> > supported.
> 
> Very strongly do not agree. 100s are good for all sorts of
> (authenticated) requests, not just INVITEs.
> 
The text I proposed tries to say that 100s are allowed for all methods, and
1xx (not 100) are only allowed for INVITE or for future methods that
explicitly allow them (the reason for including this text on the CANCEL
thread is that I believe the conditions are one and the same).

I believe we are strongly agreeing.

Have you misread what I wrote, or can it be specified more clearly.

> James
> 
> > Keith
> >
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: [email-masked]
> >
> > > ----------
> > > From: 	Jonathan Rosenberg[SMTP:[email-masked]]
> > > Sent: 	25 September 2001 7:06
> > > To: 	'Henning G. Schulzrinne'; James Undery
> > > Cc: 	[email-masked]
> > > > Sent: Monday, September 24, 2001 12:45 PM
> > > > To: James Undery
> > > > Cc: [email-masked]
> > > > 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.
> > >
> > > ---