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

[Robert Sparks <[e-mail]>]

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

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[e-mail]]
> Sent: Monday, September 17, 2001 6:41 AM
> To: [e-mail]
> Subject: RE: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> 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: [phone]
> Email: [e-mail]
> 
> > ----------
> > From: 	Bob Penfield[SMTP:[e-mail]]
> > Sent: 	10 September 2001 22:00
> > To: 	Suheel Hussain; Christer Holmberg
> > Cc: 	Jonathan Rosenberg; 'Henning G. Schulzrinne'; 
> [e-mail]
> > Subject: 	Re: [Sip] Open Issue #7: CANCEL for non-INVITE
> > 
> > 
> > ----- 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
> > 
> 
> _______________________________________________
> 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