Maybe I should ask this question another way that is more applicable to my end-goal: What exactly happens when max_inv_lifetime is reached without a final response? Is a failure_route invoked? If so, is the appropriate means of dealing with this to check t_is_expired() and handle it at that level?

Daniel, Will failure_route will be called immediately when the transaction expires? I tried a call where max_inv_lifetime was set at 50000 ms and fr_inv_timer at 40000 ms. Several new branches were attempted, each sending some 183s or 180s, and Kamailio did not CANCEL the last pending branch until 83 sec into the call. Is there something I'm missing about how to handle the transaction expiration in real time? -- Sent from my BlackBerry. Please excuse errors and brevity. Original Message From: Daniel-Constantin Mierla Sent: Wednesday, January 21, 2015 5:59 PM To: Kamailio (SER) - Users Mailing List Reply To: miconda(a)gmail.com Subject: Re: [SR-Users] Does forking impact max_inv_lifetime? Hello, somehow your emails are a bit confusing, in first one you say that you cannot get max_inv_lifetime as per transaction, being reset by a new branch, is that still true? The failure route should be called when the transaction is expired. Cheers, Daniel On 21/01/15 18:16, Alex Balashov wrote: > Maybe I should ask this question another way that is more applicable > to my end-goal: > > What exactly happens when max_inv_lifetime is reached without a final > response? Is a failure_route invoked? If so, is the appropriate means > of dealing with this to check t_is_expired() and handle it at that level? >

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/