From abalashov@evaristesys.com Wed Jan 28 23:40:30 2015
From: Alex Balashov <abalashov@evaristesys.com>
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Does forking impact max_inv_lifetime?
Date: Wed, 28 Jan 2015 17:40:23 -0500
Message-ID: <54C96557.7030608@evaristesys.com>
In-Reply-To: <54C169E4.40907@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2017616844=="

--===============2017616844==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

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(a)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/


--===============2017616844==--