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

[Robert Sparks <[e-mail]>]

inline

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[e-mail]]
> Sent: Monday, September 17, 2001 12:44 PM
> To: Drage, Keith (Keith); [e-mail]; 'Robert Sparks'
> Subject: RE: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> 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.

We can do this (but see below)

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

This is done in sip-events

> 
> The original sender of the REFER then relies on receipt of 
> the NOTIFY to
> 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.

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

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


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

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

Done.

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

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.


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

As mentioned before, this is in sip-events.

> 
> Keith
>  
> Keith Drage
> Lucent Technologies
> Tel: [phone]
> Email: [e-mail]
> 
> > ----------
> > From: 	Robert Sparks[SMTP:[e-mail]]
> > Sent: 	17 September 2001 14:21
> > To: 	'Drage, Keith (Keith)'; [e-mail]
> > Subject: 	RE: [Sip] Open Issue #7: CANCEL for non-INVITE
> > 
> > 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