[SR-Users] Does forking impact max_inv_lifetime?

[Daniel-Constantin Mierla]

Hello,

I will have to look at the code in tm module to be able to comment more.
Based on your findings, it seems that it is reset, and shouldn't.

Cheers,
Daniel

On Wed, Jan 28, 2015 at 11:40 PM, Alex Balashov <abalashov at evaristesys.com>
wrote:

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



-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/micond
<http://www.linkedin.com/in/miconda>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150130/ba538818/attachment.html>