+1 to what Bob says.
In addition, I suggest you read:
* RFC 5057 Multiple Dialog Usages in the Session Initiation Protocol
* RFC 5407 Example Call Flows of Race Conditions in the
Session Initiation Protocol
Thanks,
Paul
On 8/3/11 3:37 PM, Bob Penfield wrote:
> 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: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Leo Leo
> Sent: Wednesday, August 03, 2011 2:57 PM
> To: sip-implementors@lists.cs.columbia.edu
> 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<pkyzi...@alum.mit.edu>
> Para: sip-implementors@lists.cs.columbia.edu
> 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<i...@aliax.net>
>> Para: Leo Leo<lafa...@yahoo.com.br>
>> Cc:
>> "sip-implementors@lists.cs.columbia.edu"<sip-implementors@lists.cs.columbia.edu>
>> Enviadas: Quarta-feira, 27 de Julho de 2011 9:03
>> Assunto: Re: [Sip-implementors] BYE before call answer
>>
>> 2011/7/27 Leo Leo<lafa...@yahoo.com.br>:
>>> 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
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
