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.
2010/5/12 Maciej Bylica mbsip@gazeta.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:
- 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.
2010/5/12 Iñaki Baz Castillo ibc@aliax.net:
2010/5/12 Maciej Bylica mbsip@gazeta.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:
- 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@aliax.net
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@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
2010/5/12 Maciej Bylica mbsip@gazeta.pl:
2010/5/12 Iñaki Baz Castillo ibc@aliax.net:
2010/5/12 Maciej Bylica mbsip@gazeta.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:
- 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@aliax.net
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@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.
Still the call matches id=3 and just after failure id=1.
Thx, Maciej.
2010/5/12 Maciej Bylica mbsip@gazeta.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.
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 am about to follow your instructions tomorrow morning and get back with a feedback.
Thx, Maciej.
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.
2010/5/13 Maciej Bylica mbsip@gazeta.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").
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.
2010/6/20 Maciej Bylica mbsip@gazeta.pl:
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,
Great ;)
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@aliax.net:
2010/6/20 Maciej Bylica mbsip@gazeta.pl:
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,
Great ;)
-- Iñaki Baz Castillo ibc@aliax.net
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
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.
Maciej Bylica writes:
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?
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
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.
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
Maciej Bylica writes:
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 |
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
-
Iñaki Baz Castillo -
Juha Heinanen -
Maciej Bylica