Hi Daniel,

There was a typo error in my comment. 
My comment is 
UAC shall start the timer for this value and sends a CANCEL request it
it receives any final response for the INVITE.[RFC 3261, Sec - 13.2.1,
5th Para]
UAC shall start the timer for this value and sends a CANCEL request it does not 
receives any final response for the INVITE.[RFC 3261, Sec - 13.2.1,
5th Para]

thanks,
Sreenath

----- Original Message ----
From: Sreenath Kulkarni <[EMAIL PROTECTED]>
To: Daniel Corbe <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
Cc: [email protected]
Sent: Monday, 12 March, 2007 12:37:30 PM
Subject: Re: [Sip-implementors] server-side transaction timers

Hi Daniel,

See my comments inline.

/Sreenath

----- Original Message ----
From: Daniel Corbe <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [email protected]
Sent: Sunday, 4 March, 2007 10:30:44 PM
Subject: Re: [Sip-implementors] server-side transaction timers

Let me clarify,

I'm implementing the transaction and the application layer.  How  
would I go about timing out the session on the UAS side?
[Sreenath] The invite request shall contains the expires value which indicates 
the life time of the INVITE request. 
UAC shall start the timer for this value and sends a CANCEL request it it 
receives any final response for the INVITE.[RFC 3261, Sec - 13.2.1, 5th Para]
UAS shall start the timer for the same value and it shall send a 487 response 
if it is unable to send any final response with in the time.[RFC 3261, Sec 
-13.3.1, 1st point]
On Mar 4, 2007, at 1:53 AM, [EMAIL PROTECTED] wrote:

> Daniel Corbe wrote:
>> Hello,
>>
>> RFC3261 defines how transactions should be handled.  It clearly   
>> defines the role of a "client" transaction and a "server"   
>> transaction.  The "client" transaction is required to start  
>> request  timers T1 and T2.  T1 is a retransmission timer and T2 is  
>> a lifetime  timer.  T2 is always 64*T1 (which allows for 7  
>> retransmissions before  the session is to be torn down)
>>
>> My question is as follows:
>>
>> In the server transaction (meaning I'm receiving the request),  
>> should  I start T2?
>
> No.  Since we are under the assumption that the UAS has received  
> the INVITE, it would imply that the UAS has sent a "100 Trying"  
> back to the UAC which would kill the Time A (Retransmission Timer)  
> and Timer B( Timeout Timer).
>
>
>>  I would expect to receive a CANCEL back from the UA  after T2 has  
>> fired.
>
> I think you got confused along the way.  T2 should have been  
> terminated by your initial "100 Trying" response.
>
>
>>   If I haven't received this CANCEL I'm going to  want to tear the  
>> session down so it doesn't waste space in my  transaction pool.
>>
>
> The UAS transaction shouldn't participate in tear down while in the  
> proceeding state.  If an application defined timeout occurs, it is  
> the responsibility of the application layer to feed the transaction  
> unit with a "408 Request Timeout".   The transaction then changes  
> state to "completed state and start Timer G to retransmit the error  
> response until Timer H fires or an ACK is received.  It is only at  
> this point you that you can tear down your transaction.
>
>
>> If this sounds appropriate, what value should I use for T2?  If I  
>> use  the RFC-specified 64*T1 I would expect that there's a  
>> possibility of  the UA's cancel coming in while or after I have  
>> torn the session down.
>>
>> What's a good amount of time to allow the UA to send the CANCEL   
>> before just blindly tearing the session down.
>>
>> -Daniel
>> _______________________________________________
>> 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







        
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors







                
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to