Nataraju,
 
You are right. I wasn't clear as I wanted.
 
The dialog is finished (I mean media), but the transaction doesn't. The 
transaction enters in COMPLETED state after receiving a BYE request. While in 
COMPLETED state, answers for a retransmit BYE is the same answered as before, 
in that case, a retransmit 200 OK.
 
Despite the answers were right, someone could understand that, after first BYE, 
UAS must terminates the transaction. I just mencioned that because the question 
and the answers wasn't clear about it. 
 
:)
Leonardo
 
PS: from RFC
 
 
 

________________________________
De: Nataraju A.B <[email protected]>
Para: Leo Leo <[email protected]> 
Cc: "[email protected]" 
<[email protected]> 
Enviadas: Quarta-feira, 4 de Abril de 2012 10:32
Assunto: Re: [Sip-implementors] BYE retransmissions


Comments inline...


On Wed, Apr 4, 2012 at 4:57 PM, Leo Leo <[email protected]> wrote:

Just remmembering, the dialog shall end after timeout expires (64*T1), not just 
after receiving the first BYE. Before it, if BYE arrives, a 200 OK shall be 
sent.
>

[ABN] Soon after sending 200-BYE, the server transaction moves to COMPLETED 
state. Then wait for Timer_J(64*T1) duration. Server transaction terminates 
after TJ expires --> TERMINATED state.

When server transaction is in COMPLETED state, same old response would be sent 
back and request will not be passed upto the UAS layer.

Retransmitted BYE requests could be handled by the server transaction itself 
(by Timer_J = 64*T1).  
No need to defer deletion of dialog  for the duration of 64*T1(TJ)

 
>:)
>
>Leonardo
>
>
>________________________________
>De: Nataraju A.B <[email protected]>
>Para: M. Ranganathan <[email protected]>
>Cc: sip-implementors <[email protected]>
>Enviadas: Terça-feira, 3 de Abril de 2012 22:26
>Assunto: Re: [Sip-implementors] BYE retransmissions
>
>
>comments inline...
>
>On Wed, Apr 4, 2012 at 12:55 AM, M. Ranganathan <[email protected]> wrote:
>
>> Consider the following scenario:
>>
>> UA sends peer UA BYE
>> Recipient of BYE sends OK and tears down the dialog.
>> OK gets lost so sender of UA re-sends BYE.
>> Now there's a dialog in Terminated State but no server transaction (it
>> has already been removed).
>>
>> What is the most appropriate way for the receiver of the retransmitted
>> BYE to respond?
>>
>> Should it respond with OK, CALL_OR_DIALOG_NOT_FOUND or SERVER_FAILURE
>> ( due to the fact that the in-dialog BYE has been sent with a
>> previously seen cseq number) ?
>>
>
>    [ABN] UA receiving BYE must reply with 481 (Transaction does not exist),
>    Hence no issue for UAC / UAS. UAS already terminated, UAC terminates
>the dialog after 481.
>    Both are happy in the end...
>
>
>>
>>
>> --
>> M. Ranganathan
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
>
>
>--
>Thanks,
>Nataraju A.B.
>_______________________________________________
>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
>


-- 
Thanks, 
Nataraju A.B.



When the server transaction enters the "Completed" state, it MUST set
Timer J to fire in 64*T1 seconds for unreliable transports, and zero
seconds for reliable transports. While in the "Completed" state, the
server transaction MUST pass the final response to the transport
layer for retransmission whenever a retransmission of the request is
received. Any other final responses passed by the TU to the server
transaction MUST be discarded while in the "Completed" state. The
server transaction remains in this state until Timer J fires, at
which point it MUST transition to the "Terminated" state.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to