Re: [asterisk-users] Timer1 RFC and SIP.CONF
6 jul 2012 kl. 09:29 skrev Elliot Murdock: Hello, Thank you for the clarification. Just a few questions: 1. What is the Timer1 used for? Timer1 is the base for many other SIP timers and it's an estimate of the roundtrip time for a packet between two SIP devices or servers. TimerB is based on T1, like the retransmit timers. 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 Yes, that should propably change. /O 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 --- * Olle E Johansson - o...@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden -- _ -- 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
Re: [asterisk-users] Timer1 RFC and SIP.CONF
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
Re: [asterisk-users] Timer1 RFC and SIP.CONF
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
