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

[Suheel Hussain <[e-mail]>]

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

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?

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
>
>
>
>
>Jonathan Rosenberg wrote:
>
>>
>>
>>>-----Original Message-----
>>>From: Henning G. Schulzrinne [mailto:[e-mail]]
>>>Sent: Sunday, September 02, 2001 5:24 PM
>>>To: [e-mail]
>>>Subject: [Sip] Open Issue #7: CANCEL for non-INVITE
>>>
>>>
>>>(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).
>>>
>>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).
>>
>>>- 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.
>>>
>>Right. It wasn't the proposal to respond with a 405. Just a 200 OK, in fact.
>>
>>>- 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.
>>
>>>- 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.
>>
>>-Jonathan R.
>>
>>---
>>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>>Chief Scientist                             First Floor
>>dynamicsoft                                 East Hanover, NJ 07936
>>[e-mail]                     FAX:   [phone]
>>http://www.jdrosen.net                      PHONE: [phone]
>>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 [e-mail] for questions on current sip
>>Use [e-mail] for new developments on the application of sip
>>
>>

-- 

Suheel Hussain
[e-mail]
Cisco Work # [phone]