How the new timer framework works

Keywords: 2.0.x | Book | tm

THANKS to Andrei for giving the actual info on the new timer implementation!!

The timers of the tm module can be confusing and normally you don¨t have to (or should) tweak timers except the fr_inv_timer (controlling "how long to ring").  The below table is an overview of the timers that can be changed from seri.cfg, how they correspond to the timer names in RFC3261 and how/why you would want to change it. 

The timers for SERi 0.9.x are documented in the FAQ.

In 0.10.x the timer implementation has been completely rewritten. The timers are now controlled in milliseconds and (not in seconds as in 0.9.x), e.g. modparam("tm", "fr_timer", 30000) => default value of 30s. The timer have a resolution of 1/TIMER_TICKS_HZ. This is default 62.5 ms. Thus, the timer can fire every 62.5 ms.  Note that this also is the error interval (they can fire anywhere in a 62.5 ms interval from their "theoretical" expire point).

These changes give a much higher control over timers. Also, see the new timer module that allows you to execute a route using the new timers.

SER Timer 

RFC Name  Default Description How can it be changed? 
 fr_timer B, F 30,000 ms

Used for all requests. It hits if no reply for an INVITE request or other message has been received (F in milliseconds).  If a provisional reply is received for an INVITE (any 1xx), then the fr_inv_timer will be used instead. And if no replies (at all) for an INVITE are received before fr_timer hits, the transactioni is terminated with a 408 in failure route.

See fr_inv_timer for description of handling of multiple branches and local generation of 408 vs. 408s received from the network etc.

Intention of RFC is having this value equal to the time required to send seven requests.

modparam("tm", "fr_timer", 30000) 

This timer can also be changed per transaction (INVITE) by calling t_set_fr(timer_fr_inv, timeout_fr);
If one of the vaules is 0, the corresponding timer won't be changed (e.g t_set_fr(0, 15000 changes only the fr_timer).

 fr_inv_timer C 120,000 ms

 Timer which hits if no final reply for an INVITE arrives after a provisional message was received (in milliseconds). This means that this timer controls how long time a phone will ring before a 408 timeout is generated in failure_route. Note that it won't always be the 108 reply that will be seen in the failure_route as SER will choose a reply from all the replies received on all the branches and the "winner" will get to the failure route.

In the failure route, the new tm functions t_branchi_timeout(), t_branch_replied(), t_any_timeout(), and t_any_replied() can be used to find out if the failure route is executed as a result of a timeout (even if the selected reply is a 408, it could be something forwarded from downstreami and not a local timeout), and if it is a timeout, to find out which kind (no reply or "ringing").

     if (!t_branch_timeout() && t_check_status("408")) ...  => a 408 received from the network.
     if (t_branch_timeout() && ! t_branch_replied()) ... => a local transaction timed out w/o any reply received.
     if (t_branch_timeout() && t_branch_replied()) ... => a local timeout after some provsional reply.

Even more script functions:
         - t_any_timeout() -- true if any of the transaction branches did timeout
         - t_any_replied() -- true if at least one branch received a reply
                              (when used from an on_reply route it will ignore
                               the "current" reply)
         - t_is_canceled() -- true if the current transaction has been canceled
 For more information see the tm module docs

modparam("tm", "fr_timer", 120000) 

This timer can also be changed per transaction (INVITE) by calling t_set_fr(timer_fr_inv, timeout_fr);
If one of the vaules is 0, the corresponding timer won't be changed (e.g t_set_fr(0, 15000 changes only the fr_timer).

restart_fr_on_each_reply controls whether the fr_inv_timer is restarted every time a provisonal reply is received, default: 1 (yes)

Setting it to 0 is not rfc conformant but is very usefull for dealing with phones that will periodically retransmit the 18x Ringing, which otherwise could make the transaction live forever or mess up your voicemail activation.

 wt_timer I, K 5,000 ms 

Time for which a transaction stays in memory to absorb delayed messages after it completed; also, when this timer hits, retransmissioni of local CANCELs is stopped.


Within this time, retransmissionsi will be absorbed. After this time, the transaction is cleared and late retransmissions not recognized. Increase if there is an extreme problem with late retransmissions.

NOTE that the longer this timer is, the longer the transaction will be kept in memory and memory  consumtion increases ( => if you want to minimize the memory consumption try to lower it).

 retr_timer1T1, initial value for A, E and G500 ms 

Initial retransmission timer (for everything).

On the first retransmit of INVITEs, timer A is set to this value. For each subsequent retransmit, the timer value is doubled until fr_timer hits (RFC: B).

For non-INVITE transactionsi, the timer is set to MIN(4 * retr_timer1, retr_timer2) until fr_timer hits (RFC: F).

If you have a network with very long roundtrip time (above 1 sec), you may increase this value (but change fr_timer as well).
 retr_timer1p1  Deprecated. Replaced by retr_timer1. 
 retr_timer1p2  Deprecated. Replaced by retr_timer1. 
 retr_timer1p3  Deprecated. Replaced by retr_timer1. 
 retr_timer2T2, maximum value for A, E and G 4,000 msThe maximum length between two retransmits (for everything). No need to change. RFC mandated.
 delete_timerSER internal 200 ms  How long the deletion of a transaction will be delayed if the transaction is still in use.

modparam("tm", "delete_timer", 200)

In general there's no need to change it except for testing ways to minimize the memory         consumption (setting it to 100ms might help).

Home |  Recent changes |  Search |  Glossary |  Sitemap |  Login