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 >> >> > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
