Hello, Thank you for the clarification.
Just a few questions: 1. What is the Timer1 used for? 2. Since timerb is for all responses, final and provisional, the comment in sip.conf perhaps should point that out instead of implying only for provisional responses: "If a provisional response is not received in this amount of time, the call will autocongest" Thanks, Elliot On Thu, Jul 5, 2012 at 12:31 PM, Olle E. Johansson <o...@edvina.net> wrote: > > 4 jul 2012 kl. 13:32 skrev Elliot Murdock: > >> Hello, >> >> I am trying to get clarity with the sip.conf timer configuration. The >> current configuration states: >> >> ;--------------------------- SIP timers >> ---------------------------------------------------- >> ; These timers are used primarily in INVITE transactions. >> ; The default for Timer T1 is 500 ms or the measured run-trip time between >> ; Asterisk and the device if you have qualify=yes for the device. >> ; >> ;t1min=100 ; Minimum roundtrip time for messages >> to monitored hosts >> ; Defaults to 100 ms >> ;timert1=500 ; Default T1 timer >> ; Defaults to 500 ms or the measured >> round-trip >> ; time to a peer (qualify=yes). >> ;timerb=32000 ; Call setup timer. If a provisional >> response is not received >> ; in this amount of time, the call >> will autocongest >> ; Defaults to 64*timert1 >> >> However, according to RFC 3261: >> >> (EXCERPT 17.1.1.1) >> T1 is an estimate of the round-trip time (RTT), and >> it defaults to 500 ms. Nearly all of the transaction timers >> described here scale with T1, and changing T1 adjusts their values. >> The request is not retransmitted over reliable transports. After >> receiving a 1xx response, any retransmissions cease altogether, and >> the client waits for further responses. The server transaction can >> send additional 1xx responses, which are not transmitted reliably by >> the server transaction. Eventually, the server transaction decides >> to send a final response. >> >> (EXCERPT 13.2.2.4 2xx Responses) >> The UAC core considers the INVITE transaction completed 64*T1 seconds >> after the reception of the first 2xx response. >> >> According to the RFC, the 64*t1 timeout is not for provisional >> responses, but for final responses. This seems to be in contradiction >> to what is stated in the sip.conf file. > > Unless you have PRACK support, which Asterisk not yet has, there's > no timeout in the SIP protocol for provisional responses more than > the need to update your provisional response at least every minute > not to hit a 3 minute timeout in the SIP transaction state in a proxy. > > Now, the timerb is used to get ANY response from a server out there, > including provisional responses. If we don't get ANY response within > TIMERB, the SIP transaction dies and in a UA with a transaction > layer we generate a local 408 timeout. In Asterisk, we congest the call. > > So the 64*T1 is for any response, including final response. It's there > to decide whether or not you have intelligent SIP life forms handling > your SIP request in the network universe. > > I hope this clears up your confusion. > > Regards, > /Olle > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
