Differences

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

--- ref_manual:timers [2009/05/05 00:54]
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 =====
@@ Line 133: / Line 135: @@
   * **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.

Trace:

Differences

Navigation

Search

Toolbox

QR Code