It may just be part of your implementation, but Transactions are independent of dialogs. There is nothing in RFC 3261 that associates transactions and dialogs together in a way that the state of the dialog would affect the state of a pending transaction.
The main point is that the reception of a BYE does not mean that the UA that received the BYE can simply ignore any pending transaction that may be related to that dialog. That UA must still send a final response to requests that it has received. In the case of receiving a BYE, the recommendation in 3261 is to send a 487 response to each of those pending transactions. The same applies to the UA sending the BYE in that it must still be ready to receive responses on outstanding transactions (i.e. the transaction state machines must continue to run until a final response is received of it times out). cheers, (-:bob -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Leo Leo Sent: Wednesday, August 03, 2011 2:57 PM To: [email protected] Subject: Re: [Sip-implementors] BYE before call answer 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
