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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 25 Apr 2001 10:38:19 +0100

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

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.

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

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

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Henning G. Schulzrinne[SMTP:[email-masked]]
> Sent: 	25 April 2001 0:16
> To: 	Drage, Keith (Keith)
> Cc: 	[email-masked]'
> Subject: 	Re: [SIP] Further editorial nit in the bis draft
> 
> "Drage, Keith (Keith)" wrote:
> > 
> > Following on from my previous editorial nit, I notice the naming of
> > status-code 487 is also inconsistent in the bis draft.
> > 
> > In section 4.2.5, 5th and 6th paragraphs, and in section 7.4.24, and in
> > section 15.5, the name is given as
> > 
> >         487 (Request Terminated)
> > 
> > However in figure 6, the syntactic definition we have:
> > 
> >         |   "487"  ;  Request Cancelled
> > 
> > In annex F (which will presumably disappear at IESG last call) we have
> > 
> >         487 (Transaction Terminated)
> > 
> > I believe this is a new status-code to SIP, therefore we are not tied to
> > previous usage in HTTP. I propose that we stick to "Request Terminated"
> and
> > change the two instances that are different from this.
> > 
> 
> There is a side issue that I'd like to confirm before doing the edit:
> The status description mentions that 487 is also sent when a BYE
> terminates a pending request (presumably INVITE). This would indeed
> argue for "Request terminated" rather than "cancelled".
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 

_______________________________________________
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: "Arunachalam Venkatraman" <[email-masked]>
Date: Wed, 25 Apr 2001 07:15:39 -0500

If the INVITE was responded to with 100 Trying (thus disabling
retransmissions) and the BYE with 200 OK (since the INVITE has not
completed), the UAS and the proxies en-route would have cleared the call on
receipt of the 200 OK to the BYE. What is the value of the 487 to INVITE ?
Other than the protocol rule that each transaction completes independently.
Is there going to be any stack that will be upset if the 487 is not sent in
this case?

----- Original Message -----
From: "Drage, Keith (Keith)" <[email-masked]>
To: "Drage, Keith (Keith)" <[email-masked]>; "'Henning G. Schulzrinne'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 25, 2001 4:38 AM
Subject: RE: [SIP] Further editorial nit in the bis draft

---

From: Vijay Gurbani <[email-masked]>
Date: Wed, 25 Apr 2001 09:39:07 -0500

Arunachalam Venkatraman wrote:
> completed), the UAS and the proxies en-route would have cleared the call 
> on receipt of the 200 OK to the BYE. What is the value of the 487 to 
> INVITE ? Other than the protocol rule that each transaction completes 
> independently. Is there going to be any stack that will be upset if the 
> 487 is not sent in this case?

I would be careful about making too many assumptions here.  There maybe
call-stateful proxies that may have allocated some resources on proxying
the INVITE transaction.  These proxies will need a final response (even a 
non-200 one) from the UAS in order to release the resources.  These proxies 
may never see a BYE since they R-R but R-R does not take effect on a non-2xx 
response to the INVITE (except on certain 4xx responses -- namely 401 Un-
authorized and 484 Address Incomplete; 487 is not one of them).

I think you are safe if you stick with the dictum of always allowing each
transaction to complete independently.

- 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