Hi, I set fr_inv_timer=150 and use lcr module to balance (and failover) between two gateways.
In the failure route I set (simplified):
failure_route[FAILURE_ROUTE_OUT] {
if (t_local_replied("last")) { next_gw(); t_relay(); }
}
This means that if a INVITE routed to gateway-1 replies a provisional response but no final response within 150 seconds, then Kamailio should generate a local 408 and failure route would relaty to gateway-2.
But what I see is that such "timeout" time is 75 seconds (the half of 150 !).
I remember a similar "issue" when handling with SRV DNS domains returning more than one destinations, but in my case I just use single IP's in lcr module. But the fact is that I use exactly 2 gateways in lcr (150/2 = 75). But anyhow it doesn't make sense.
Do I miss something? Thanks.
PD: Important, could occur the same with fr_timer?
Iñaki Baz Castillo writes:
Hi, I set fr_inv_timer=150 and use lcr module to balance (and failover) between two gateways.
is this with kamailio or sr? how did you set the timer? in k, it should be something like this:
$avp(FR_TIMER_AVP) = GW_TIMEOUT; t_relay();
where GW_TIMEOUT is in seconds, and in sr:
t_set_fr(INVITE_TIMEOUT, GW_TIMEOUT); t_relay();
where INVITE_TIMEOUT and GW_TIMEOUT are ms.
-- juha
El Jueves, 4 de Marzo de 2010, Juha Heinanen escribió:
I use Kamailio 1.5.2. I don't override the timer value with an AVP, I mean the default fr_inv_timer parameter of TM module.
But this should be needed if default fr_inv_timer is already valid, right?
Thanks.
Iñaki Baz Castillo writes:
i have always set the avp explicitly after calling next_gw() and before calling t_relay() and i have set the avp again in failure route. try that.
But this should be needed if default fr_inv_timer is already valid, right?
i don't know. try my way and see if it works for you.
-- juha
El Jueves, 4 de Marzo de 2010, Juha Heinanen escribió:
Ok, I'll try it. However it seems that lcr is modyfing the fr_inve_timer value by itself. Perhaps it depends on the number of gateways per lcr rule? Anyhow it shouldn't IMHO.
Regards.
El Jueves, 4 de Marzo de 2010, Juha Heinanen escribió:
Ok, so the issue must be in TM. I'll check it.
2010/3/4 Iñaki Baz Castillo ibc@aliax.net:
Hi, I couldn't yet try Juha's suggestion but I'm sure it must be a bug in TM module.
As I said (kamailio 1.5.4) I set "fr_inv_timer=200" for TM module and use LCR for serial forking (failover). I also do failover is no final reply is received from the first gateway, however I do not manually override fr_inv_timer, neither using LCR AVP's (as $avp(FR_TIMER_AVP)).
There are two gateways in lcr/gw tables and TM raises timout after 100 seconds if no final reply was received by the first contacted gateway, and later after 100 seconds again if no final reply was received from gateway-2.
This obviously means that, in some way, "something" is dividing the "fr_inv_timer" (200) by the number of LCR loaded gateways (so 408 occurs after 100 seconds). If I set "fr_inv_timer=300" then the 408 occurs after 150, this is => fr_inv_timer / 2.
There must be a bug somewhere as it doesn't honor the documentation of TM module:
------------------- 1.4.26. fr_inv_timer_next (integer) ... That can take up to the value of fr_inv_timer and this timer is configured to two minutes by default. Hence, if you have three serial branches then completing the transaction can take six minutes with default timer values. --------------------
This is not what it happens in my case, as the total time is "fr_inv_timer" and such time is divided by the number of serial forking it *could* occur. IMHO just the LCR module knows such information, retrieved during "load_gateways()" function.
I aki Baz Castillo writes:
in k 1.5 config, i have
modparam("tm", "fr_inv_timer", INVITE_TIMEOUT) modparam("tm", "fr_timer_avp", "$avp(FR_TIMER_AVP)")
where INVITE_TIMEOUT is something like 120.
then after calling next_gw() and before calling t_relay(), i set
$avp(FR_TIMER_AVP) = GW_TIMEOUT;
where GW_TIMEOUT is a small constant. i do not do anything in the script to fr_inv_timer. that simply tells the total time how long the process can last. it makes no sense for the proxy to try longer than something like 120 sec, because UACs usually timeout anyway if you increase the time much longer.
i don't understand why you would try the second gw, if you got for example ringing reply from the first one.
lcr module gw functions do not do anything to any timer.
-- juha
2010/3/25 Juha Heinanen jh@tutpro.com:
I've a UAC waiting for a ringing call "forever" (the typicall callcenter in which calls are made by a not properly configured dialer).
That's true, I should decite to stop the call (reply 408) or leave it ringing by the same gateway (so I would need to increase the fr_inv_timer for such branch). However this doesn't explain the bug I'm reporting :)
But how is possible that the effective fr_inv_timer per branch is exactly divided by the number of gateways loaded after load_gatways() ? How could the TM module do something like this?
NOTE: I'havent tryied with 3 or more gateways. Perhaps TM module is dividing the fr_inv_timer by 2 due to some other reason...
I aki Baz Castillo writes:
load_gws() just assigns a set gws to an avp and next_gw() creates a new branch with next gw from the set. lcr module is thus totally unaware of any tm stuff.
NOTE: I'havent tryied with 3 or more gateways. Perhaps TM module is dividing the fr_inv_timer by 2 due to some other reason...
in my case, when i set
modparam("tm", "fr_inv_timer", INVITE_TIMEOUT)
then that dictates the max time used for the call setup. if during that time i would (which i don't) try one gw for 60 secs then there is another 60 secs left for the next.
-- juha
2010/3/25 Juha Heinanen jh@tutpro.com:
I really believe what you say. Just wondering how this issue is possible...
This is not what it happens to me :(
Thanks.