Hi, Paul, There is something missing here, please explain it to me.
>They BYE does *not* "terminate all transactions"! >Every transaction must follow its own state machine, independent of any >other transaction. >You MUST attempt to send some final response to any outstanding >transactions even if a BYE transaction has been completed. >The BYE only ends the Invite-dialog-usage. If BYE only ends the dialog, what does the UA must to do with any other transaction within that dialog? As far as I know, the transactions within a dialog ara attached its existence. There is no sense to send or to receive some message from earlier transactions (just like retransmissions) after a BYE request or a BYE response received. Lets say the BYE received has come just after sending the re-INVITE. Following your explanation, the dialog must be finished, but the transaction from re-INVITE doesn't. Then, the re-INVITE will be retransmited and the UA which has sent the BYE will still answer after the dialog had been finished. Anyway, I know the dialog and the transactions will be finished, the question is when. Moreover, in some cases it will flood the network unnecessarily. If I was not so clear, I meant "As the BYE terminates all transactions, " as "As the BYE terminates all transactions of the associated established dialog". Thanks. Leonardo ________________________________ De: Paul Kyzivat <[email protected]> Para: [email protected] Enviadas: Quarta-feira, 3 de Agosto de 2011 14:37 Assunto: Re: [Sip-implementors] BYE before call answer On 7/27/11 8:29 AM, Leo Leo wrote: >>> 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. It doesn't matter if the reinvite is forked. A reinvite doesn't establish an early dialog, because there is already a final dialog. And you may send a BYE within the dialog, regardless of whether there is a reinvite outstanding or not. >>> 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. They BYE does *not* "terminate all transactions"! Every transaction must follow its own state machine, independent of any other transaction. You MUST attempt to send some final response to any outstanding transactions even if a BYE transaction has been completed. The BYE only ends the Invite-dialog-usage. Thanks, Paul > 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. > > > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
