Differences

This shows you the differences between two versions of the page.

--- ref_manual:timers [2009/05/05 00:48]
janakj
+++ ref_manual:timers [2013/01/27 15:12] (current)
oej old revision restored
@@ Line 39: / Line 39: @@
 This timer can also be changed per transaction (INVITE) by calling
-  t_set_fr(timer_fr_inv, timeout_fr);
+  t_set_fr(timeout_fr_inv, timeout_fr);
 in a route section of the configuration file. 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'').
+If it was changed using t_set_fr() for a transaction, it can be reset to the default value
+using t_reset_fr().
 ===== fr_inv_timer =====
@@ Line 91: / Line 93: @@
   - ''t_is_canceled'': true if the current transaction has been canceled
-For more information see the documentation of tm module.
+For more information see the documentation of tm module (especially t_set_fr() and t_reset_fr()).
+===== wt_timer =====
+Time for which a transaction stays in memory to absorb delayed messages after
+it is completed. Also, when this timer hits, retransmissions of local CANCELs
+are stopped.
+  * **Corresponding RFC 3261 timers**: Timer I and Timer K
+  * **Default value**: 5000 ms
+  * **Example**: modparam("tm", "wt_timer", 10000)
+Within this time, retransmissions will be absorbed by the server. After this
+time, the transaction is cleared and late retransmissions not
+recognized. Increase if there is an extreme problem with late retransmissions.
+<note>
+The longer this timer is, the longer the transaction will be kept
+in memory and memory consumtion increases (Try to set it to a lower value if
+you want to minimize memory consumption).
+</note>
+===== retr_timer1 =====
+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 3261: Timer B).
+For non-INVITE transactions, the timer is set to
+MIN(4 * retr_timer1, retr_timer2) until ''fr_timer'' hits (RFC 3261: Timer F).
+  * **Corresponding RFC 3261 timers**: Timer T1, initial value for A, E, and G.
+  * **Default value**: 500 ms
+  * **Example**: modparam("tm", "retr_timer1", 1000)
+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_timer2 =====
+The maximum length between two retransmits (for everything).
+  * **Corresponding RFC 3261 timers**: Timer T2, maximum value for A, E, and G.
+  * **Default value**: 4000 ms
+  * **Example**: modparam("tm", "retr_timer2", 8000)
+===== max_inv_lifetime =====
+Maximum time an INVITE transaction is allowed to be active (in
+milliseconds). After this interval has passed from the transaction
+creation, the transaction will be either moved into the wait state or
+in the final response retransmission state, irrespective of the
+transaction fr_inv_timer and fr_timer values.
+An INVITE transaction will be kept in memory for maximum:
+max_inv_lifetime+fr_timer(from the ack to the final reply
+wait)+wt_timer.
+The main difference between this timer and fr_inv_timer is that the
+fr_inv_timer is per branch, while max_inv_lifetime is per the whole
+transaction. Even on a per branch basis fr_inv_timer could be
+restarted. For example, by default if restart_fr_on_each_reply is not
+cleared, the fr_inv_timer will be restarted for each received
+provisional reply. Even if restart_fr_on_each_reply is not set the
+fr_inv_timer will still be restarted for each increasing reply (e.g.
+, 181, 182, ...). Another example when a transaction can live
+substantially more then its fr_inv_timer and where max_inv_lifetime
+will help is when dns failover is used (each failed dns destination
+can introduce a new branch).
+The default value is 180000 ms (180 seconds - the rfc3261 timer C
+value).
+See also: max_noninv_lifetime, t_set_max_lifetime() (allows changing
+max_inv_lifetime on a per transaction basis), t_reset_max_lifetime
+fr_timer, wt_timer, restart_fr_on_each_reply.
+Example:
+<code>
+modparam("tm", "max_inv_lifetime", 150000)
+</code>
+===== max_noninv_lifetime =====
+Maximum time a non-INVITE transaction is allowed to be active (in
+milliseconds). After this interval has passed from the transaction
+creation, the transaction will be either moved into the wait state or
+in the final response retransmission state, irrespective of the
+transaction fr_timer value. It's the same as max_inv_lifetime, but for
+non-INVITEs.
+A non-INVITE transaction will be kept in memory for maximum:
+max_noninv_lifetime+wt_timer.
+The main difference between this timer and fr_timer is that the
+fr_timer is per branch, while max_noninv_lifetime is per the whole
+transaction. An example when a transaction can live substantially more
+then its fr_timer and where max_noninv_lifetime will help is when dns
+failover is used (each failed dns destination can introduce a new
+branch).
+The default value is 32000 ms (32 seconds - the rfc3261 timer F
+value).
+See also: max_inv_lifetime, t_set_max_lifetime() (allows changing
+max_noninv_lifetime on a per transaction basis), t_reset_max_lifetime
+fr_timer, wt_timer.
+===== delete_timer =====
+<note>
+This timer is obsolete for ser 2.1 and sip-router (in 2.1 the transaction is deleted the moment it's not referenced anymore).
+</note>
+This is the amount of time for which the deletion of a transaction will be
+delayed if the transaction is still use.
+  * **Corresponding RFC 3261 timers**: No corresponding timer, SER specific
+  * **Default value**: 200 ms
+  * **Example**: modparam("tm", "retr_timer1", 1000)
+In general there's no need to change it except for testing ways to minimize
+the memory consumption (setting it to 100ms might help).

Trace:

Differences

Navigation

Search

Toolbox

QR Code