[SR-Users] Does forking impact max_inv_lifetime?
Alex Balashov
abalashov at evaristesys.com
Wed Jan 28 23:40:23 CET 2015
Hi,
To return to this topic, it definitely does not appear that
max_inv_lifetime runs concurrently with the fr_[inv]_timers. The
documentation suggests that max_inv_lifetime is a transaction-level
construct that is logically independent of the fr_ timers on any
particular branch, but that does not appear to be the case.
I tested with a UAS that sends continuous 183 Session Progress ad
infinitum. My TM parameters are:
modparam("tm", "fr_timer", 3000) # 3 seconds
modparam("tm", "fr_inv_timer", 120000) # was: 40000.
modparam("tm", "fr_inv_timer_avp", "$avp(inv_timer)")
modparam("tm", "max_inv_lifetime", 60000)
Now, one critical aspect of this issue is that I initially set
$avp(inv_timer) to 10 sec to deal with PDD. This is reset to the default
120s in an onreply_route using t_reset_fr() once a 18x or 2xx reply is
received:
if(t_check_status("1[1-9][0-9]|200"))
t_reset_fr();
The top of my failure_route looks like this:
failure_route[ROUTE_OUTBOUND_TRY_FAILURE] {
if(t_is_canceled()) {
xlog("L_INFO", "[FR-ROUTE-OUTBOUND-TRY-FAILURE:$ci] -> "
"Transaction cancelled\n");
return;
}
if(t_is_expired()) {
xlog("L_INFO", "[FR-ROUTE-OUTBOUND-TRY-FAILURE:$ci] -> "
"Transaction timed out because max_inv_lifetime has been reached; no
more attempts will be made\n");
t_reply("503", "Service Unavailable");
exit;
}
if(t_branch_timeout()) {
xlog("L_INFO", "[FR-ROUTE-OUTBOUND-TRY-FAILURE:$ci] -> "
"Route attempt timed out\n");
}
...
}
So, my expectation would be that even though the successive 183s cause
the fr_inv_timer to be reset every time and thus never hit, that
max_inv_lifetime would kick in at 60 seconds and thus kill the transaction.
Instead, here's what happens:
[Jan 28 16:24:36] Initial INVITE -->
[Jan 28 16:24:36] <-- 100 Trying
[Jan 28 16:24:38] <-- 183 Session Progress
[Jan 28 16:25:26] <-- 183 Session Progress
[Jan 28 16:26:01] <-- 183 Session Progress
[Jan 28 16:26:03] <-- 183 Session Progress
[Jan 28 16:26:25] <-- 183 Session Progress
[Jan 28 16:26:59] <-- 183 Session Progress
[Jan 28 16:27:31] <-- 183 Session Progress
[Jan 28 16:28:03] <-- 183 Session Progress
[Jan 28 16:28:25] <-- 183 Session Progress
[Jan 28 16:28:59] <-- 183 Session Progress
[Jan 28 16:29:26] <-- 183 Session Progress
[Jan 28 16:29:36] <-- max_inv_lifetime finally hits, and branch is
CANCEL'd by Kamailio, i.e.
Jan 28 16:29:36 sip /usr/local/sbin/kamailio[5816]: INFO: <script>:
[FR-ROUTE-OUTBOUND-TRY-FAILURE:4551-5851-9ab6 at x.x.x.x] -> Transaction
timed out because max_inv_lifetime has been reached; no more attempts
will be made
That's a full 5 minutes later!
Furthermore, if I remove the t_reset_fr() call in the onreply_route and
don't initialise $avp(inv_timer) to 10 sec, everything works like
clockwork and max_inv_lifetime does kick in after 60 seconds, as expected.
So, there is definitely some logical connection between the
fr_[inv]_timers and max_inv_lifetime, although the documentation seems
to suggest otherwise.
Any insight would be appreciated!
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
More information about the sr-users
mailing list