Hi,
In this serial forking-based failover scenario
UAC --> Proxy --> UAS 1 UAS 2 ... UAS 3
I've got a requirement to terminate the call and return an error to the UAC if there is no final response within 60 seconds.
The usual fr_inv_timer / restart_fr_on_each_reply combination won't do, because even when restart_fr_on_each_reply == 0, the timer is still restarted on provisional replies of increasing response code value (e.g. 183 after 180). As the documentation states, fr_inv_timer is a branch-level construct anyway, so this approach doesn't make sense here.
That's why I looked into max_inv_lifetime. However, when I set it to 60000, I still get the same result, but only when there are new branches being formed on the proxy -> UAS side. It works fine if there is no forking and a single gateway does not provide a final reply within 60 seconds. So, my sense is that the max_inv_lifetime timeout is reset when a new branch is created to UAS 2...UAS N.
Is this accurate?
Thanks,
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?
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?
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@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?
I haven't used the feature myself (nor implemented it), but it is what I expect. Maybe you can run in debug mode and map the logs with the code to see what happens.
Cheers, Daniel
On 22/01/15 00:04, Alex Balashov wrote:
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@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!
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@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_lifetimehas 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/
-
Alex Balashov -
Daniel-Constantin Mierla