Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
ref_manual:timers [2009/05/05 21:26] andrei more details |
ref_manual:timers [2013/01/27 15:12] (current) oej old revision restored |
||
|---|---|---|---|
| Line 44: | Line 44: | ||
| corresponding timer won't be changed (e.g '' | corresponding timer won't be changed (e.g '' | ||
| '' | '' | ||
| - | If it was changes | + | If it was changed |
| using t_reset_fr(). | using t_reset_fr(). | ||
| Line 93: | Line 93: | ||
| - '' | - '' | ||
| - | For more information see the documentation of tm module. | + | For more information see the documentation of tm module |
| ===== wt_timer ===== | ===== wt_timer ===== | ||
| Line 135: | Line 135: | ||
| * **Default value**: 4000 ms | * **Default value**: 4000 ms | ||
| * **Example**: | * **Example**: | ||
| + | |||
| + | ===== 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. | ||
| + | 180, 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, | ||
| + | max_inv_lifetime on a per transaction basis), t_reset_max_lifetime | ||
| + | fr_timer, wt_timer, restart_fr_on_each_reply. | ||
| + | |||
| + | Example: | ||
| + | < | ||
| + | modparam(" | ||
| + | </ | ||
| + | |||
| + | ===== 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, | ||
| + | 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, | ||
| + | max_noninv_lifetime on a per transaction basis), t_reset_max_lifetime | ||
| + | fr_timer, wt_timer. | ||
| ===== delete_timer ===== | ===== delete_timer ===== | ||
