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

["Bob Penfield" <[e-mail]>]

----- Original Message -----
From: "Suheel Hussain" <[e-mail]>
To: "Christer Holmberg" <[e-mail]>
Cc: "Jonathan Rosenberg" <[e-mail]>; "'Henning G.
Schulzrinne'" <[e-mail]>; <[e-mail]>
Sent: Monday, September 10, 2001 2:52 PM
Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE


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


_______________________________________________
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