30 and 60 seconds don't sound like sane values to me since the UAC isn't required to give up until 64*T1 and the default setting for T1 is 500ms. Every INVITE retransmission is supposed to reset to 2*T1 so that 64*T1 gives you a total of seven retransmissions.
This means I shouldn't expect to see a CANCEL packet coming from the UAC until a minimum of 32 seconds. Over latent connections (such as satellite links) where there can easily be 800ms worth of one-way delay, this timer will increase dramatically as RFC3261 specifies that one can increase this timer. Let's say for instance T1 is set to 2000ms (2 seconds) on the UAC side. That would give us a T2 timer of 128 seconds. See what I'm getting at? What's a sane value to time out the server transaction if we haven't received a request retransmission or a CANCEL back from the UAC? -Daniel On Mar 4, 2007, at 7:36 PM, Joegen E. Baclor wrote: > In My Case, I have configurable timeouts for Alerting and Connect. > I am defaulting to 30 seconds for Alerting and 60 seconds for > Connect. The two timers are started simultaneously upon receipt of > the INVITE. Upon expiration of any of the two timers, I feed the > transaction layer with a 408 error response to the INVITE. > Another check I am doing is to define a new timer to guard against > maximum transaction life span. I am defaulting this to 5 > minutes just in case the application layer totally forgot about the > transaction to avoid transaction leaks. > > Joegen > > Daniel Corbe wrote: >> 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? >> 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 >>>> >>>> >>> >> >> >> >> >> --No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.446 / Virus Database: 268.18.7/710 - Release Date: >> 3/4/2007 1:58 PM >> >> > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
