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
