Subject: RE: [SIP] CANCEL/200 OK/BYE

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2000 00:06:21 -0400

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Saturday, October 14, 2000 1:28 PM
> To: [email-masked]; [email-masked]
> Cc: Vijay Gurbani
> Subject: [SIP] CANCEL/200 OK/BYE
> 
> 
> All:
> 
> The bis RFC says that when an INVITE is to be terminated 
> (either by the
> UAC timing out after sending 7 requests out or by the caller 
> associated 
> with the UAC hanging up) a BYE or CANCEL request may be sent; it 
> recommends sending both.
> 
> I know the reason BYE is preferred is if CANCEL and 200 OK "cross each
> other on the wire".  But what if they don't?  Why send the 
> BYE if after
> sending a CANCEL, the UAC gets a 487 Request Terminated (which it will
> have to ACK, of course).  There are two cases (let's assume a lossless
> network with in-order delivery of packets):
> 
> Case 1: CANCEL and 200 OK DO NOT "cross each other on the wire":
> 
>   UAC
>     INVITE------->
>     <----------- 100 Trying
>     <----------- 180 Ringing
>     CANCEL ------>
>     <----------- 487 Request Terminated
>     ACK---------->
>     <------------ 200 OK (CSeq: xxx CANCEL)
> 
>   As far as I can see, no need to send BYE here.  (Last 4 
> exchanges are 
>   as per the behavior of a UAS when it gets a CANCEL and has 
> NOT send a 
>   final response -- Section 4.2.5 "CANCEL")
> 
> Case 2: CANCEL and 200 OK DO "cross each other on the wire":
> 
>    UAC
>      INVITE------->
>      <----------- 100 Trying
>      <----------- 180 Ringing
>      CANCEL-----> <------ 200 OK (CSeq: xxx INVITE)
>      ACK --------->
>      BYE --------->
>      <------------- 200 OK (CSeq: xxx BYE)
> 
>    Clearly, here, the CANCEL has no effect on the state machine of the
>    UAS since it has already sent out the final response.  The UAC, on
>    receiving the 200 OK notes that this is OK'ing an INVITE, thus the
>    CANCEL it send out has no meaning.  It ACKs the 200 OK and 
> THEN sends
>    a BYE.
> 
> So, it looks to me as if a CANCEL results in a 487 Request Terminated,
> a BYE may not be sent.  Is that accurate?  Comments?
> 
> What are other implementors implementing?

I think the most correct behavior is to send a CANCEL. If you get a final
response to the INVITE that is 200 class, then send BYE.

Where in the spec does it say to send both?

-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.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 16 Oct 2000 09:18:35 -0500

Jonathan Rosenberg wrote:
> > I know the reason BYE is preferred is if CANCEL and 200 OK "cross 
> > each other on the wire".  But what if they don't?  Why send the
> > BYE if after sending a CANCEL, the UAC gets a 487 Request Terminated 
> > (which it will have to ACK, of course).  There are two cases (let's 
> > assume a lossless network with in-order delivery of packets):
> >
> > exchanges are as per the behavior of a UAS when it gets a CANCEL and 
> > has NOT send a final response -- Section 4.2.5 "CANCEL")
> >
> >    Clearly, here, the CANCEL has no effect on the state machine of 
> >    the UAS since it has already sent out the final response.  The 
> >    UAC, on receiving the 200 OK notes that this is OK'ing an INVITE, 
> >    thus the CANCEL it send out has no meaning.  It ACKs the 200 OK 
> >    and THEN sends a BYE.
> >
> > So, it looks to me as if a CANCEL results in a 487 Request 
> > Terminated, a BYE may not be sent.  Is that accurate?  Comments?
> >
> I think the most correct behavior is to send a CANCEL. If you get a 
> final response to the INVITE that is 200 class, then send BYE.

Right.  That is my understanding (and implementation, as well).  But,
to me, the spec is expansive enough that there may be problems with
interoperability.
 
> Where in the spec does it say to send both?

Section 10.5.1 "Unreliable Transport Protocols", first paragraph, 
last sentence.

I think the spec should state that a UAC MUST send a  BYE iff after 
having sent a CANCEL (for an in-progress INVITE), it got a 200 class 
response to the INVITE (which means that the 200 OK and CANCEL "crossed 
each other on the wire").

Thanks,

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
Internet Software Group/Intelligent Network and Messaging Systems
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184