<div dir="ltr">Hello,<div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Daniel</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 11:40 PM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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.<br>
<br>
I tested with a UAS that sends continuous 183 Session Progress ad infinitum. My TM parameters are:<br>
<br>
   modparam("tm", "fr_timer", 3000)        # 3 seconds<br>
   modparam("tm", "fr_inv_timer", 120000)   # was: 40000.<br>
   modparam("tm", "fr_inv_timer_avp", "$avp(inv_timer)")<br>
   modparam("tm", "max_inv_lifetime", 60000)<br>
<br>
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:<br>
<br>
        if(t_check_status("1[1-9][0-9]<u></u>|200"))<br>
                t_reset_fr();<br>
<br>
The top of my failure_route looks like this:<br>
<br>
failure_route[ROUTE_OUTBOUND_<u></u>TRY_FAILURE] {<br>
        if(t_is_canceled()) {<br>
                xlog("L_INFO", "[FR-ROUTE-OUTBOUND-TRY-<u></u>FAILURE:$ci] -> "<br>
                        "Transaction cancelled\n");<br>
<br>
                return;<br>
        }<br>
<br>
        if(t_is_expired()) {<br>
                xlog("L_INFO", "[FR-ROUTE-OUTBOUND-TRY-<u></u>FAILURE:$ci] -> "<br>
                        "Transaction timed out because max_inv_lifetime has been reached; no more attempts will be made\n");<br>
<br>
                t_reply("503", "Service Unavailable");<br>
                exit;<br>
        }<br>
<br>
        if(t_branch_timeout()) {<br>
                xlog("L_INFO", "[FR-ROUTE-OUTBOUND-TRY-<u></u>FAILURE:$ci] -> "<br>
                        "Route attempt timed out\n");<br>
        }<br>
<br>
        ...<br>
}<br>
<br>
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.<br>
<br>
Instead, here's what happens:<br>
<br>
[Jan 28 16:24:36] Initial INVITE --><br>
[Jan 28 16:24:36] <-- 100 Trying<br>
[Jan 28 16:24:38] <-- 183 Session Progress<br>
[Jan 28 16:25:26] <-- 183 Session Progress<br>
[Jan 28 16:26:01] <-- 183 Session Progress<br>
[Jan 28 16:26:03] <-- 183 Session Progress<br>
[Jan 28 16:26:25] <-- 183 Session Progress<br>
[Jan 28 16:26:59] <-- 183 Session Progress<br>
[Jan 28 16:27:31] <-- 183 Session Progress<br>
[Jan 28 16:28:03] <-- 183 Session Progress<br>
[Jan 28 16:28:25] <-- 183 Session Progress<br>
[Jan 28 16:28:59] <-- 183 Session Progress<br>
[Jan 28 16:29:26] <-- 183 Session Progress<br>
[Jan 28 16:29:36] <-- max_inv_lifetime finally hits, and branch is CANCEL'd by Kamailio, i.e.<br>
<br>
Jan 28 16:29:36 sip /usr/local/sbin/kamailio[5816]<u></u>: INFO: <script>: [FR-ROUTE-OUTBOUND-TRY-<u></u>FAILURE:4551-5851-9ab6@x.x.x.x<u></u>] -> Transaction timed out because max_inv_lifetime has been reached; no more attempts will be made<br>
<br>
That's a full 5 minutes later!<br>
<br>
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.<br>
<br>
So, there is definitely some logical connection between the fr_[inv]_timers and max_inv_lifetime, although the documentation seems to suggest otherwise.<br>
<br>
Any insight would be appreciated!<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Alex Balashov - Principal<br>
Evariste Systems LLC<br>
235 E Ponce de Leon Ave<br>
Suite 106<br>
Decatur, GA 30030<br>
United States<br>
<br>
Tel: <a href="tel:%2B1-678-954-0670" value="+16789540670" target="_blank">+1-678-954-0670</a><br>
Web: <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.alexbalashov.com/" target="_blank">http://www.alexbalashov.com/</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Daniel-Constantin Mierla - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a></div><div><a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/micond</a></div></div></div>
</div>