Daniel Corbe wrote: > 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?
At this point, No. Those timers would have been killed after sending and receiving the provisional response regardless of the value of T1. > 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? Under ideal circumstances, you are not suppose to get a retransmission of the request. That is the exact purpose of the 100 Trying. It should stop the UAC from retransmitting. Just in case you get a retranmission of the INVITE, all you need to do is to resend the last provisional response. I don't know what you refer to the "timeout out" above. Upon sending of ANY provisional response, there should be no active timer in the UAS. It is now up to the application to decide how much it is willing to wait for a final response before giving up. Timers would only start again after a final error response is sent. This is to assure that the response gets retransmitted until an ACK is received. > > > -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 >>> >>> >> > > > > > --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
