Hi Iñaki, >>After the 200 (BYE) should the UAS send a final response (i.e. 487) >>for terminating the INVITE transaction (in the same way a CANCEL >>triggers a 487 for the INVITE from the UAS and the corresponding ACK >>from the UAC)? I'm not sure about it.
The probability of this happen is very low, I think. In this forking case, the BYE is only sent when any other host have alread sent the 200 OK. Usually, the BYE arrives into the UAC after sending at least one provisional response. Anyway, the RFC says that a receiving BYE must to finish all transactions of the associated dialog. The unique transaction which remains is the BYE transaction for sending another 200 OK for some retransmission. Although, the UAC may send some final response (i.e. 487) before sending the 200 OK for the BYE. In matter fact, there is some homologating procedures which requires this behaviour. Leonardo ________________________________ De: Iñaki Baz Castillo <[email protected]> Para: Leo Leo <[email protected]> Cc: "[email protected]" <[email protected]> Enviadas: Terça-feira, 26 de Julho de 2011 10:03 Assunto: Re: [Sip-implementors] BYE before call answer 2011/7/26 Leo Leo <[email protected]>: > But, as you assure correctly, the BYE may be used in this case, as writen in > RFC, section 15: > > "The BYE request is used to terminate a specific session or attempted > session. In this case, the specific session is the one with the peer UA on > the other side of the dialog. (...). The caller’s UA MAY send a BYE for > either confirmed or early dialogs, and the callee’s UA MAY send a BYE on > confirmed dialogs, but MUST NOT send a BYE on early dialogs." > > > Thanks for the answer! Hi Leo, right, I missed to point such exact section of the section 15 (I didn't find it, sorry). Anyhow, all this topic is a bit contradictory since a dialog (which means answered-dialog or early-dialog) requires all the stuff for constructing a dialog, which is: a) A remote target (which is the Contact of the other participant). b) A route-set (if present) which is constructed by mirroring Record-Route headers inserted by proxies. Both a) and b) are just required by RFC 3261 for ***reliable*** responses. In RFC 3261 the only reliable response is a 2XX. So we could state that RFC 3263 (PRACK) is required so 180/183 can also become reliable responses (so they MUST satisfy points a) and b) above, so PRACK and BYE can be sent to the specific destination). BTW I've never seen a BYE for terminating an early-dialog :) In fact, I don't know how the flow should be, this is: alice bob INVITE ----------> <---------------- 180 (INVITE) PRACK ---------> <----------------- 200 (PRACK) BYE -------------> <----------------- 200 (BYE) After the 200 (BYE) should the UAS send a final response (i.e. 487) for terminating the INVITE transaction (in the same way a CANCEL triggers a 487 for the INVITE from the UAS and the corresponding ACK from the UAC)? I'm not sure about it. Regards. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
