12 May
2010
12 May
'10
3:20 p.m.
Hi ALL,
I have a problem to configure LCR module to work properly (kamailio rel. 1.5)
The task in my case is to handle:
1) All calls coming with CLD number prefix 482223344 from my MGW
(77.77.77.77) towards kamilio and direct them to sip world
(88.88.88.88)
2) Calls with CLD starting with 48 coming from SIP world towards
kamailio and direct them to my MGWs. Additionaly i need to route it on
the basis of CLI number.
So MGWs <---> Kamailio <---> SIPProxies (88.88.88.88)
In db:
+----+-----------+----------------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+----+-----------+----------------+--------+----------+
| 1 | 48 | 48 | 1 | 1 |
| 2 | 48 | 49 | 2 | 1 |
| 3 | 482223344 | 77.77.77.77 | 3 | 1 |
+----+-----------+----------------+--------+----------+
gw,
+----+--------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+
| id | gw_name | grp_id | ip_addr | hostname | port |
uri_scheme | transport | strip | tag | weight | ping | flags |
+----+--------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+
| 1 | CLI48 | 1 | 77.77.77.70 | NULL | 5060 | NULL |
NULL | NULL | NULL | 150 | 0 | 0 |
| 2 | CLI48backup | 1 | 77.77.77.71 | NULL | 5060 |
NULL | NULL | NULL | NULL | 150 | 0 | 0 |
| 3 | CLI49 | 2 | 77.77.77.75 | NULL | 5060 | NULL |
NULL | NULL | NULL | 15 | 0 | 0 |
| 4 | CLI49backup | 2 | 77.77.77.76 | NULL | 5060 |
NULL | NULL | NULL | NULL | 15 | 0 | 0 |
| 5 | SIPWORLD | 3 | 88.88.88.88 | NULL | 5060 |
NULL | NULL | NULL | NULL | 250 | 0 | 0 |
+----+--------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+
Unfortunately:
- call is originated on 77.77.77.77 with CLD 48222334455 number and
kamailio forward this call to grp_id=3 SIPWORLD which is okay. The
problem is that if the call fail, kamailio will try to use 77.77.77.70
and 77.77.77.71 from grp_id=1 which is wrong. I have no idea how to
provide a kind of huntstop in grp_id=3.
I've been trying with
+----+-----------+----------------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+----+-----------+----------------+--------+----------+
| 1 | 48 | 88.88.88.88 | 1 | 1 |
| 2 | 48 | 88.88.88.88 | 2 | 1 |
| 3 | 482223344 | 77.77.77.77 | 3 | 1 |
+----+-----------+----------------+--------+----------+
but in this case i am unable to provide kamailio with CLI number routing.
Here is a part of my config file...
if (!load_gws()) {
sl_send_reply("503", "Unable to load
gateways");
exit;
}
if (!next_gw()) {
sl_send_reply("503", "Unable to find a
gateway");
exit;
}
route(1);
exit;
and failover for route(1)...
failure_route[11] {
# In case of failure, send it to an alternative route:
if (t_check_status("408|404|5[0-9][0-9]")) {
if (!next_gw()) {
t_reply("503", "Service not available, no more
gateways");
exit;
}
else {
t_on_failure("11");
t_relay();
}
exit;
}
}
Anybody could help my to get out of that?
Thx,
Maciej.
12 May
12 May
4:45 p.m.
2010/5/12 Maciej Bylica <mbsip(a)gazeta.pl>pl>:
Hi ALL,
I have a problem to configure LCR module to work properly (kamailio rel. 1.5)
The task in my case is to handle:
1) All calls coming with CLD number prefix 482223344 from my MGW
(77.77.77.77) towards kamilio and direct them to sip world
(88.88.88.88)
2) Calls with CLD starting with 48 coming from SIP world towards
kamailio and direct them to my MGWs. Additionaly i need to route it on
the basis of CLI number.
So MGWs <---> Kamailio <---> SIPProxies (88.88.88.88)
In db:
+----+-----------+----------------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+----+-----------+----------------+--------+----------+
| 1 | 48 | 48 | 1 | 1 |
| 2 | 48 | 49 | 2 | 1 |
| 3 | 482223344 | 77.77.77.77 | 3 | 1 |
+----+-----------+----------------+--------+----------+
Unfortunately:
- call is originated on 77.77.77.77 with CLD 48222334455 number and
kamailio forward this call to grp_id=3 SIPWORLD which is okay. The
problem is that if the call fail, kamailio will try to use 77.77.77.70
and 77.77.77.71 from grp_id=1 which is wrong. I have no idea how to
provide a kind of huntstop in grp_id=3.
Why do you set "77.77.77.77" in the from_uri field of the third entry
in 'lcr' table? It makes no sense. As you don't pass a pseudovariable
to the command load_gw() then LCR tries to match the *From URI* of the
INVITE with the 'from_uri' of the 'lcr' table.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:01 p.m.
2010/5/12 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
2010/5/12 Maciej Bylica <mbsip(a)gazeta.pl>pl>:
Hi,
Thx for prompt answer.
I was playing around with lcr table and found that i may place an IP
address which is a part of sip uri there.
It means that if a call is originated from 77.77.77.77 (from sip uri
482223344(a)77.77.77.77) then grp_id=3 should be chosen.
Of course i may wipe this out but i am unsure if it help.
Thx,
Maciej
Hi ALL,
I have a problem to configure LCR module to work properly (kamailio rel. 1.5)
The task in my case is to handle:
1) All calls coming with CLD number prefix 482223344 from my MGW
(77.77.77.77) towards kamilio and direct them to sip world
(88.88.88.88)
2) Calls with CLD starting with 48 coming from SIP world towards
kamailio and direct them to my MGWs. Additionaly i need to route it on
the basis of CLI number.
So MGWs <---> Kamailio <---> SIPProxies (88.88.88.88)
In db:
+----+-----------+----------------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+----+-----------+----------------+--------+----------+
| 1 | 48 | 48 | 1 | 1 |
| 2 | 48 | 49 | 2 | 1 |
| 3 | 482223344 | 77.77.77.77 | 3 | 1 |
+----+-----------+----------------+--------+----------+
Unfortunately:
- call is originated on 77.77.77.77 with CLD 48222334455 number and
kamailio forward this call to grp_id=3 SIPWORLD which is okay. The
problem is that if the call fail, kamailio will try to use 77.77.77.70
and 77.77.77.71 from grp_id=1 which is wrong. I have no idea how to
provide a kind of huntstop in grp_id=3.
Why do you set "77.77.77.77" in the from_uri field of the third entry
in 'lcr' table? It makes no sense. As you don't pass a pseudovariable
to the command load_gw() then LCR tries to match the *From URI* of the
INVITE with the 'from_uri' of the 'lcr' table.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:12 p.m.
2010/5/12 Maciej Bylica <mbsip(a)gazeta.pl>pl>:
2010/5/12 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Still the call matches id=3 and just after failure id=1.
Thx,
Maciej.
2010/5/12 Maciej Bylica <mbsip(a)gazeta.pl>pl>:
Hi,
Thx for prompt answer.
I was playing around with lcr table and found that i may place an IP
address which is a part of sip uri there.
It means that if a call is originated from 77.77.77.77 (from sip uri
482223344(a)77.77.77.77) then grp_id=3 should be chosen.
Of course i may wipe this out but i am unsure if it help. Hi ALL,
I have a problem to configure LCR module to work properly (kamailio rel. 1.5)
The task in my case is to handle:
1) All calls coming with CLD number prefix 482223344 from my MGW
(77.77.77.77) towards kamilio and direct them to sip world
(88.88.88.88)
2) Calls with CLD starting with 48 coming from SIP world towards
kamailio and direct them to my MGWs. Additionaly i need to route it on
the basis of CLI number.
So MGWs <---> Kamailio <---> SIPProxies (88.88.88.88)
In db:
+----+-----------+----------------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+----+-----------+----------------+--------+----------+
| 1 | 48 | 48 | 1 | 1 |
| 2 | 48 | 49 | 2 | 1 |
| 3 | 482223344 | 77.77.77.77 | 3 | 1 |
+----+-----------+----------------+--------+----------+
Unfortunately:
- call is originated on 77.77.77.77 with CLD 48222334455 number and
kamailio forward this call to grp_id=3 SIPWORLD which is okay. The
problem is that if the call fail, kamailio will try to use 77.77.77.70
and 77.77.77.71 from grp_id=1 which is wrong. I have no idea how to
provide a kind of huntstop in grp_id=3.
Why do you set "77.77.77.77" in the from_uri field of the third entry
in 'lcr' table? It makes no sense. As you don't pass a pseudovariable
to the command load_gw() then LCR tries to match the *From URI* of the
INVITE with the 'from_uri' of the 'lcr' table.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:30 p.m.
2010/5/12 Maciej Bylica <mbsip(a)gazeta.pl>pl>:
>>> In db:
>>> +----+-----------+----------------+--------+----------+
>>> | id | prefix | from_uri | grp_id | priority |
>>> +----+-----------+----------------+--------+----------+
>>> | 1 | 48 | 48 | 1 | 1 |
>>> | 2 | 48 | 49 | 2 | 1 |
>>> | 3 | 482223344 | 77.77.77.77 | 3 | 1 |
>>> +----+-----------+----------------+--------+----------+
>>
>>> Unfortunately:
>>> - call is originated on 77.77.77.77 with CLD 48222334455 number and
>>> kamailio forward this call to grp_id=3 SIPWORLD which is okay. The
>>> problem is that if the call fail, kamailio will try to use 77.77.77.70
>>> and 77.77.77.71 from grp_id=1 which is wrong. I have no idea how to
>>> provide a kind of huntstop in grp_id=3.
This occurs because the rules with id=1 and id=3 do match the INVITE
so if the first fails (longest matching prefix) the other will be
executed. This is how LCR works.
Use load_gws() with a pseudo-variable as I recommend you in the other
mail so you won't rely on the From URI but on the call origin you have
previously analized in the script.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
13 May
13 May
12:08 a.m.
>>> In
db:
>>> +----+-----------+----------------+--------+----------+
>>> | id | prefix | from_uri | grp_id | priority |
>>> +----+-----------+----------------+--------+----------+
>>> | 1 | 48 | 48 | 1 | 1 |
>>> | 2 | 48 | 49 | 2 | 1 |
>>> | 3 | 482223344 | 77.77.77.77 | 3 | 1 |
>>> +----+-----------+----------------+--------+----------+
>>
>>> Unfortunately:
>>> - call is originated on 77.77.77.77 with CLD 48222334455 number and
>>> kamailio forward this call to grp_id=3 SIPWORLD which is okay. The
>>> problem is that if the call fail, kamailio will try to use 77.77.77.70
>>> and 77.77.77.71 from grp_id=1 which is wrong. I have no idea how to
>>> provide a kind of huntstop in grp_id=3.
This occurs because the rules with id=1 and id=3 do match the INVITE
so if the first fails (longest matching prefix) the other will be
executed. This is how LCR works.
Use load_gws() with a pseudo-variable as I recommend you in the other
mail so you won't rely on the From URI but on the call origin you have
previously analized in the script.
1:53 p.m.
> This occurs because the rules with id=1 and id=3
do match the INVITE
> so if the first fails (longest matching prefix) the other will be
> executed. This is how LCR works.
>
> Use load_gws() with a pseudo-variable as I recommend you in the other
> mail so you won't rely on the From URI but on the call origin you have
> previously analized in the script.
>
It works :)
In lcr:
+----+-----------+----------------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+----+-----------+----------------+--------+----------+
| 1 | 48 | ^from_sip$ | 1 | 1 |
| 2 | 48 | ^from_pstn$ | 2 | 1 |
+----+-----------+----------------+--------+----------+
gw,
+----+--------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+
| id | gw_name | grp_id | ip_addr | hostname | port |
uri_scheme | transport | strip | tag | weight | ping | flags |
+----+--------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+
| 1 | CLI48 | 1 | 77.77.77.70 | NULL | 5060 | NULL |
NULL | NULL | NULL | 150 | 0 | 0 |
| 2 | CLI48backup | 1 | 77.77.77.71 | NULL | 5060 |
NULL | NULL | NULL | NULL | 150 | 0 | 0 |
| 3 | CLI49 | 1 | 77.77.77.75 | NULL | 5060 | NULL |
NULL | NULL | NULL | 15 | 0 | 0 |
| 4 | CLI49backup | 1 | 77.77.77.76 | NULL | 5060 |
NULL | NULL | NULL | NULL | 15 | 0 | 0 |
| 5 | SIPWORLD | 2 | 88.88.88.88 | NULL | 5060 |
NULL | NULL | NULL | NULL | 250 | 0 | 0 |
+----+--------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+
if (allow_source_address("1")) {
$var(origin) = "from_sip";
}
else if (allow_source_address("2")) {
$var(origin) = "from_pstn";
}
else {
sl_send_reply("403", "Forbidden");
exit;
where "1" and "2" are MGWs and SIPWORLD ips.
Then load_gws("$var(origin)") is called.
But still one issue remains (only from SIPWORLD ---> Kamailio ---->
MGWs scenario).
As aforementioned i need to inspect calling number and choose proper
MGWs to have the call terminated.
I need to be able to identify calling numbers like 48 (only two
starting digits), 48221112233 (the whole number), and the rest.
Is there any way i can implement this functionality with lcr module?
Thx,
Maciej.
2:15 p.m.
2010/5/13 Maciej Bylica <mbsip(a)gazeta.pl>pl>:
But still one issue remains (only from SIPWORLD
---> Kamailio ---->
MGWs scenario).
As aforementioned i need to inspect calling number and choose proper
MGWs to have the call terminated.
I need to be able to identify calling numbers like 48 (only two
starting digits), 48221112233 (the whole number), and the rest.
Is there any way i can implement this functionality with lcr module?
You can inspect manually (via script) the calling number and set the
"from_uri" pseudo variable according to it. Would it be valid?
Setting "48" and "48221112233" in the lcr entries is not valid as
when
the CLI is 48221112233 both entries would match it (perhaps randomly
or based on first entry in the table). I strongly prefer to play with
cusom "from_uri" values manually set in the script befor invoking
load_gws("pseudovariable").
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
20 Jun
20 Jun
7:03 p.m.
Hi Iñaki,
You can inspect manually (via script) the calling
number and set the
"from_uri" pseudo variable according to it. Would it be valid?
Setting "48" and "48221112233" in the lcr entries is not valid as
when
the CLI is 48221112233 both entries would match it (perhaps randomly
or based on first entry in the table). I strongly prefer to play with
cusom "from_uri" values manually set in the script befor invoking
load_gws("pseudovariable").
Sry for delay.
I followed Your instructions and the effect is possitive - it works.
Many thanks,
Maciej.
21 Jun
21 Jun
12:53 a.m.
2010/6/20 Maciej Bylica <mbsip(a)gazeta.pl>pl>:
Hi Iñaki,
Great ;)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
You can inspect manually (via script) the calling
number and set the
"from_uri" pseudo variable according to it. Would it be valid?
Setting "48" and "48221112233" in the lcr entries is not valid as
when
the CLI is 48221112233 both entries would match it (perhaps randomly
or based on first entry in the table). I strongly prefer to play with
cusom "from_uri" values manually set in the script befor invoking
load_gws("pseudovariable").
Sry for delay.
I followed Your instructions and the effect is possitive - it works.
Many thanks,
4 Jul
4 Jul
10:15 p.m.
Hi again,
Last question in this topic i hope.
Could I use regex in prefix column (lcr table)?
I just want to have a minimum number of entries created there, and to
block the rest of prefixes in this way.
Thx,
Maciej.
2010/6/21 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
2010/6/20 Maciej Bylica <mbsip(a)gazeta.pl>pl>:
Hi Iñaki,
Great ;)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
You can inspect manually (via script) the calling
number and set the
"from_uri" pseudo variable according to it. Would it be valid?
Setting "48" and "48221112233" in the lcr entries is not valid as
when
the CLI is 48221112233 both entries would match it (perhaps randomly
or based on first entry in the table). I strongly prefer to play with
cusom "from_uri" values manually set in the script befor invoking
load_gws("pseudovariable").
Sry for delay.
I followed Your instructions and the effect is possitive - it works.
Many thanks, 
10:14 p.m.
Maciej Bylica writes:
Could I use regex in prefix column (lcr table)?
no you can't. searching for longest matching prefix would not really
slow if prefix could be regex.
dialplan module supports regexs. perhaps you can you that to produce an
attribute that you can match to lcr prefixes.
-- juha
5 Jul
5 Jul
5:28 p.m.
Hi Juha,
no you can't. searching for longest matching
prefix would not really
slow if prefix could be regex.
dialplan module supports regexs. perhaps you can you that to produce an
attribute that you can match to lcr prefixes.
What do You mean by saying that?
How to produce an attribute that may be matched to lcr prefixes?
Thx,
Maciej.
5:43 p.m.
Maciej Bylica writes:
if dp_translate matches a dialplan match_exp then corresponding attr
value is assigned to attrs_pvar. you can then prefix $rU with that
value and call load_gws().
-- juha
dialplan
module supports regexs. perhaps you can you that to produce an
attribute that you can match to lcr prefixes.
What do You mean by saying that?
How to produce an attribute that may be matched to lcr prefixes?
7 Jul
7 Jul
11:23 a.m.
Hi,
My script is almost done.
I am wondering how weights are calculated in order to choose proper gws list.
For this test I've modified gw table in following way (the same weights).
LCR table points to grp_id=1.
+----+----------------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+
| id | gw_name | grp_id | ip_addr | hostname |
port | uri_scheme | transport | strip | tag | weight | ping | flags |
+----+----------------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+
| 1 | GW11 | 11 | 33.44.55.66 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
| 2 | GW1 group 1 | 1 | 11.22.33.10 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
| 3 | GW5 | 2 | 22.33.44.55 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
| 4 | GW6 | 3 | 22.33.44.56 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
| 5 | GW2 group 1 | 1 | 11.22.33.11 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
| 6 | GW3 group 1 | 1 | 11.22.33.12 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
| 7 | GW4 group 1 | 1 | 11.22.33.13 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
+----+----------------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+
According to syslog debugs:
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:lcr_hash_table_lookup: looking for <482221>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:lcr_hash_table_lookup: looking for <48222>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:do_load_gws: added matched_gws[0]=[2, 5, 1, 238659200]
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:do_load_gws: added matched_gws[1]=[6, 5, 1, 13052500]
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:do_load_gws: added matched_gws[2]=[5, 5, 1, 769501300]
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:do_load_gws: added matched_gws[3]=[3, 5, 1, 440887600]
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:lcr_hash_table_lookup: looking for <4822>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:lcr_hash_table_lookup: looking for <482>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:lcr_hash_table_lookup: looking for <48>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:add_gws_into_avps: added gw_uri_avp
<1|0||4274347715||5060|0|0> with weight <13052500>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:add_gws_into_avps: added gw_uri_avp
<1|0||3552927427||5060|0|0> with weight <238659200>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:add_gws_into_avps: added gw_uri_avp
<1|0||3569704643||5060|0|0> with weight <440887600>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:add_gws_into_avps: added gw_uri_avp
<1|0||4240793283||5060|0|0> with weight <769501300>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:generate_uris: r_uri <sip:48221112233@11.22.33.12:5060>,
dst_uri <>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:next_gw: added ruri_user_avp <48221112233>
Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]:
DBG:lcr:next_gw: added flags_avp <0>
So it means that weights are calculated different way, not directly
and only according to weight column.
What is more defining wieght column does not make any sense, because
data provided there produce different output.
Anybody could point me in right direction.
Thanks,
Maciej.
12:29 p.m.
Juha,
it is weight column, not priority column. weight
gives a probability of
the gw being chosen from among gws of the same group.
What other parameters are taken into account while defining probability?
Is that means, that to achieve 100% predictable "routing" (not to
count on probability), i need to
+------+--------+----------------------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+------+--------+----------------------+--------+----------+
| 140 | 4822 | ^from_sip$ | 1 | 1 |
| 142 | 4822 | ^from_sip$ | 2 | 2 |
| 143 | 4822 | ^from_sip$ | 3 | 3 |
| 144 | 4822 | ^from_sip$ | 4 | 4 |
| 2 | GW1 group 1 | 1 | 11.22.33.10 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
| 5 | GW2 group 2 | 2 | 11.22.33.11 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
| 6 | GW3 group 3 | 3 | 11.22.33.12 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
| 7 | GW4 group 4 | 4 | 11.22.33.13 | NULL | 5060 |
NULL | NULL | NULL | NULL | 100 | 0 | 0 |
Thx,
Maciej
12:15 p.m.
Maciej Bylica writes:
as you see in above, there is priority column in lcr table. use that
and arrange so that each gw group has only one gw. then you will be
sure in which order gws are tried.
-- juha
it is weight
column, not priority column. weight gives a probability of
the gw being chosen from among gws of the same group.
What other parameters are taken into account while defining probability?
Is that means, that to achieve 100% predictable "routing" (not to
count on probability), i need to
+------+--------+----------------------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+------+--------+----------------------+--------+----------+
| 140 | 4822 | ^from_sip$ | 1 | 1 |
| 142 | 4822 | ^from_sip$ | 2 | 2 |
| 143 | 4822 | ^from_sip$ | 3 | 3 |
| 144 | 4822 | ^from_sip$ | 4 | 4 |
5050
days inactive
5106
days old
19 comments
3 participants
participants (3)
-
Iñaki Baz Castillo -
Juha Heinanen -
Maciej Bylica