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@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!