Jonathan Rosenberg wrote: > > > -----Original Message----- > > From: Vijay K. Gurbani [mailto:[EMAIL PROTECTED]] > > > > 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. 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 PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 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
