3 Mar
2010
3 Mar
'10
6:51 p.m.
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 <ibc(a)aliax.net>
4 Mar
4 Mar
9:03 a.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
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
11:10 a.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
El Jueves, 4 de Marzo de 2010, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
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.
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:
But this should be needed if default fr_inv_timer is already valid, right?
Thanks.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
9:26 a.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
Iñaki Baz Castillo writes:
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.
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
11:23 a.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
El Jueves, 4 de Marzo de 2010, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
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.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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.
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.
7:57 p.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
Iñaki Baz Castillo writes:
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.
inaki,
lcr module does nothing to any timer nor does not explicitly refer to
any.
-- juha
9:49 p.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
El Jueves, 4 de Marzo de 2010, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Ok, so the issue must be in TM. I'll check it.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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.
inaki,
lcr module does nothing to any timer nor does not explicitly refer to
any.
25 Mar
25 Mar
2:46 p.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
2010/3/4 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
El Jueves, 4 de Marzo de 2010, Juha Heinanen
escribió:
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
<ibc(a)aliax.net>
lcr module does nothing to any timer nor does not
explicitly refer to
any.
Ok, so the issue must be in TM. I'll check it.
3:20 p.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
I aki Baz Castillo writes:
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)).
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.
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.
i don't understand why you would try the second gw, if you got for
example ringing reply from the first one.
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.
lcr module gw functions do not do anything to any timer.
-- juha
3:29 p.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
2010/3/25 Juha Heinanen <jh(a)tutpro.com>om>:
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
<ibc(a)aliax.net>
I aki Baz Castillo writes:
I've a UAC waiting for a ringing call "forever" (the typicall
callcenter in which calls are made by a not properly configured
dialer).
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)).
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. 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.
i don't understand why you would try the second gw, if you got for
example ringing reply from the first one. 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.
lcr module gw functions do not do anything to any timer.
3:42 p.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
I aki Baz Castillo writes:
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?
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
4:15 p.m.
New subject: [Kamailio-Users] fr_inv_timer not honored (fr_inv_timer/2 is used in fact)
2010/3/25 Juha Heinanen <jh(a)tutpro.com>om>:
This is not what it happens to me :(
Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
I aki Baz Castillo writes:
I really believe what you say. Just wondering how this issue is possible...
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?
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.
5167
days inactive
5189
days old
11 comments
2 participants
participants (2)
-
Iñaki Baz Castillo -
jh＠tutpro.com