Subject: RE: [SIP] Further editorial nit in the bis draft

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Apr 2001 14:04:29 -0400

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2001 5:38 AM
> To: Drage, Keith (Keith); 'Henning G. Schulzrinne'
> Cc: [email-masked]'
> Subject: RE: [SIP] Further editorial nit in the bis draft
> 
> 
> I agree there are indications in the current bis draft that 
> suggest a BYE
> also terminates pending transactions. Assuming that people 
> agree that this
> is correct behaviour, the the following considerations apply.

I don't know that I'd phrase it as "BYE terminates pending transactions".
The main issue is that if you send a BYE before INVITE completes, you must
complete the INVITE transaction (this is because of the golden rule in sip,
that all transactions complete independently). So, what response code?
Really, it matters not one drop. But, the suggestion was made to use 487.
Thats just as fine as anything else, and probably the most appropriate. But,
it is not the same as saying BYE terminates pending transactions, just like
CANCEL. 

> 
> I do note that if this is required behaviour, then there 
> should be more text
> in section 4.2.4 (BYE) that specifies this behaviour.
> 
> Section 4.2.5 (CANCEL) specifies the following for the 487 activity:
> 
>    The behavior of the user agent or redirect server on receiving a
>    CANCEL request depends on whether the server has already 
> sent a final
>    response for the original request. If it has, the CANCEL 
> request has
>    no effect on the original request, any call state and on the
>    responses generated for the original request. If the server has not
>    issued a final response for the original request, it immediately
>    sends a 487 (Request Terminated) for the original request. 
> For INVITE
>    requests, the UAC as usual sends an ACK request to confirm 
> receipt of
>    any final response. The CANCEL request itself is answered 
> with a 200
>    (OK) response in either case.
> 
>    A proxy client or UAC cannot rely on receiving a 487 (Request
>    Terminated) response, as a RFC 2543-compliant UAS will not generate
>    such a response. If there has been no final response after 32
>    seconds, the client MAY consider the original transaction to have
>    been cancelled.

This text above is fine. Its talking about CANCEL, not BYE.

> 
> The only text in 4.2.4 that looks like this talks only about 
> terminating
> INVITE requests, and does not mention the status-code to be used. 
> 
>    A BYE request from either called or calling party terminates any
>    pending INVITE at a UA, but the INVITE request transaction MUST be
>    completed with a final response and ACK.

I would add text here that says, "It is RECOMMENDED that a 487 code be used
in the final response to INVITE"

> 
> Presumably BYE can also terminate other requests within the session
> (OPTIONS, PRACK, COMET) and this status-code should also be 
> used for them.

This is unlikely to be an issue, since these should be responded to
immediately anyway. But, it is worth noting that any outstanding
transactions for a call that is BYEd MUST be responded to.

> 
> I would suggest that the implied behaviour for BYE requires 
> some text in
> 4.2.4 based on that currently in 4.2.5 for CANCEL.
> 
> Back to the subject of the associated text string value, I note the
> following text in 6.21 would imply that "cancelled" and 
> "cancellation" can
> be done by BYE, so we may want to change the words there as well.
> 
>         Strictly speaking, CSeq header fields are needed for any
>         SIP request that can be cancelled by a BYE or CANCEL
>         request or where a client can issue several requests for
>         the same Call-ID in close succession. Without a sequence
>         number, the response to an INVITE could be mistaken for the
>         response to the cancellation (BYE or CANCEL). 

Actually, I would rather remove the reference to cancelling a request with
BYE. Thats legacy from the old days when, in fact, sending a BYE meant you
didn't need to respond to the original INVITE.

-Jonathan R.

---
Jonathan D. Rosenberg                       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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 26 Apr 2001 09:01:57 -0500

Jonathan Rosenberg wrote:
[...]
> didn't need to respond to the original INVITE.

Please do.  This is a perennial source of confusion at the bakeoffs.  I have
observed implementations cancelling a request with BYE and while it is
clear that they should be using CANCEL instead, one cannot authoritatively
cite a section in the RFC for this behavior.  

As far as I can see, the only reason to send BYE in relation to a CANCEL is 
if the CANCEL from the UAC and a 200 OK (INVITE) from the UAS crossed each 
other on the wire. 

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184