>>Interesting, never thought about it. So, if I send a re-INVITE for >>which I have no final reply yet and then I send a BYE, should the UAS >>reply 200 for the BYE and terminate the remaining re-INVITE >>transasction without sending a final response?
>>Or should the UAS reply a "491 Request Pending" for the BYE? Anyhow >>section 14.2 in RFC 3261 just indicates that 491 is useful when there >>is a pending re-INVITE from A to B and B sends a re-INVITE to A. In >>that case A should reply 491. A re-INVITE must not be forked, as RFC says in section 14. Then, no BYE might come for a re-INVITE. The BYE shall be understood in order to finish the dialog itself. The CANCEL must be used in that case. >> 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. >If the BYE is supposed to "magically" terminate all the pending >transactions within the dialog (without requiring a final response for >them) then I see no reason to send a 487 (maybe it would fail as the >UAC would already terminate the client transaction for the initial >INVITE). As the BYE terminates all transactions, it not really necessarilly. However, it is desired to send the final response in order to avoid retransmissions or unexpectable behavour . I think that's why some homologating procedures requires that. Sending the final response (i.e.487) before 200 OK is reliable. Leonardo ________________________________ De: Iñaki Baz Castillo <[email protected]> Para: Leo Leo <[email protected]> Cc: "[email protected]" <[email protected]> Enviadas: Quarta-feira, 27 de Julho de 2011 9:03 Assunto: Re: [Sip-implementors] BYE before call answer 2011/7/27 Leo Leo <[email protected]>: > Anyway, the RFC says that a receiving BYE must to finish all transactions of > the associated dialog. Interesting, never thought about it. So, if I send a re-INVITE for which I have no final reply yet and then I send a BYE, should the UAS reply 200 for the BYE and terminate the remaining re-INVITE transasction without sending a final response? Or should the UAS reply a "491 Request Pending" for the BYE? Anyhow section 14.2 in RFC 3261 just indicates that 491 is useful when there is a pending re-INVITE from A to B and B sends a re-INVITE to A. In that case A should reply 491. > 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. If the BYE is supposed to "magically" terminate all the pending transactions within the dialog (without requiring a final response for them) then I see no reason to send a 487 (maybe it would fail as the UAC would already terminate the client transaction for the initial INVITE). Interesting topic :) Regards. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
