Busy Asterisk systems can be affected by the SIP timers T1 and B timeout values configured. Consideration of their values impacts how quickly a transaction can recover from a lost packet and the amount of memory used. It is in your best interest to make these values as small as possible for your installation.
The T1 timer sets the timeout after which SIP gives up on waiting for a response from the remote party. The general rule is to set this to slightly higher than the round-trip time (RTT) to the furthest remote party. Although the default of 500 ms is safe, this timer controls other timing aspects of the of the SIP stack so reducing it is in your best interest. Unless you have a provider or remote phones with more than a 100 ms RTT, setting this to 100 ms (the minimum) is probably safe. If you have outlier phones such as cell phones with VoIP clients, setting it to 250 ms is probably safe.
The B timer is technically the INVITE transaction timeout but it also controls other aspects of SIP stack timing. It’s default is 32 seconds but its minimum is (64 * T1) which would also be 32 seconds if T1 were left at its default of 500 ms. Unfortunately, this timer has the side effect of controlling how long completed transactions are kept in memory so on a busy PBX, a setting of 32 seconds will probably result in higher than necessary memory utilization. For most installations, 6400 ms is fine.
The PJSIP stack used in Asterisk has the timer_t1 and timer_b configuration options to control the two timers described above in the pjsip.conf configuration file. The older chan_sip channel driver also has equivalent options for these timers but you should be migrating toward the new PJSIP channel driver chan_pjsip.
More performance tuning ideas can be found at https://wiki.asterisk.org/wiki/display/AST/Performance+Tuning
4 Responses
The PJSIP stack used in Asterisk has the timer_t1 and timer_b configuration options to control the two timers described above in the res_pjsip.conf configuration file.
The res_pjsip.conf doe not exist, I guess you meant the pjsip.conf file.
Great article by the way.
Fixed.
Thank you.
One thing I miss in Asterisk SIP timers is something like t1max.
When qualify is being used to measure round trip time to an endpoint,
Asterisk sets T1 to the value measured. It’s fine as long as no OPTIONS packets get lost.
As OPTIONS get retransmitted on constant intervals (1000ms), the RTT often gives false readings. This retransmission schedule also pushes settings qualify to some bigger values, like 5000ms to skip unneccessary marking endpoints as unreachable due to occassional packet loss.
1st OPTIONS packet lost – RTT 1030ms,
two consecutive OPTIONS packets lost – RTT 2030ms (assuming qualify timeout value is long enough),
while the real RTT is 30ms. This causes T1 to be set to 2 or even 5 or more seconds till next qualify, which does not make much sense I guess.
I do not know if OPTIONS retransmission schedule remains the same in Asterisk 13 and PJSIP, so this comment may only be relevant to Asterisk 11 and earlier.
The PJSIP functionality does not use OPTIONS response time to adjust T1 as of this time, so it is not applicable to it.