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!

--
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/