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
