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
