Hello List.
I'm having a weird behavior with the LCR module.
I have a particular prefix routed as follows (according to the LCR tables) :
mysql> select * from lcr where prefix=0251;
+-----+--------+----------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+-----+--------+----------+--------+----------+
| 89 | 1351 | | 51 | 1 |
| 127 | 1351 | | 43 | 2 |
+-----+--------+----------+--------+----------+
The gw's group are as follows :
mysql> select * from gw where grp_id=51;
+-----+----------------+--------+---------------+----------+------+----- -------+-----------+-------+------+--------+------+-------+
| id | gw_name | grp_id | ip_addr | hostname | port | uri_scheme | transport | strip | tag | weight | ping | flags |
+-----+----------------+--------+---------------+----------+------+----- -------+-----------+-------+------+--------+------+-------+
| 100 | GW1.TERMN1 | 51 | XX.XXX.XXX.16 | | 5060 | 1 | 1 | 4 | 1351 | 25 | 1 | 0 |
| 101 | GW2.TERMN1 | 51 | XX.XXX.XXX.13 | | 5060 | 1 | 1 | 4 | 1351 | 25 | 1 | 0 |
| 102 | GW3.TERMN1 | 51 | XX.XXX.XXX.32 | | 5060 | 1 | 1 | 4 | 1351 | 25 | 1 | 0 |
| 103 | GW4.TERMN1 | 51 | XX.XXX.XXX.35 | | 5060 | 1 | 1 | 4 | 1351 | 25 | 1 | 0 |
+-----+----------------+--------+---------------+----------+------+----- -------+-----------+-------+------+--------+------+-------+
4 rows in set (0.00 sec)
mysql>
mysql> select * from gw where grp_id=43;
+----+------------------+--------+---------------+----------+------+---- --------+-----------+-------+------+--------+------+-------+
| id | gw_name | grp_id | ip_addr | hostname | port | uri_scheme | transport | strip | tag | weight | ping | flags |
+----+------------------+--------+---------------+----------+------+---- --------+-----------+-------+------+--------+------+-------+
| 76 | GW1.TERMN222 | 43 | XX.XXX.XXX.16 | | 5060 | 1 | 1 | 4 | 1343 | 25 | 1 | 0 |
| 77 | GW2.TERMN222 | 43 | XX.XXX.XXX.13 | | 5060 | 1 | 1 | 4 | 1343 | 25 | 1 | 0 |
| 78 | GW3.TERMN222 | 43 | XX.XXX.XXX.32 | | 5060 | 1 | 1 | 4 | 1343 | 25 | 1 | 0 |
| 79 | GW4.TERMN222 | 43 | XX.XXX.XXX.35 | | 5060 | 1 | 1 | 4 | 1343 | 25 | 1 | 0 |
+----+------------------+--------+---------------+----------+------+---- --------+-----------+-------+------+--------+------+-------+
4 rows in set (0.00 sec)
So, when a call with prefix 1351 arrived at the proxy, the LCR module is changing the RURI for 1343 (matching the 2nd priority for that prefix).
This keep happening even if change the priority value 2 for priority value 5. I even changed the priority 1 for priority 0 as follows :
+-----+--------+----------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+-----+--------+----------+--------+----------+
| 89 | 1351 | | 51 | 0 |
| 127 | 1351 | | 43 | 1 |
+-----+--------+----------+--------+----------+
But the LCR module keep using the "second" priority.
After doing some tests I've found two ways to use the "first" priority for the prefix.
1.- Removing the second priority
2.- Re-ordering the "id" column and using correlative values as indicated in the next table :
mysql> select * from lcr where prefix=0251 order by id;
+-----+--------+----------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+-----+--------+----------+--------+----------+
| 127 | 1351 | | 51 | 1 |
| 128 | 1351 | | 43 | 2 |
+-----+--------+----------+--------+----------+
So, when the prefix are with "no correlatives" values in the "id" column seems to be a problem to match the first priority. But when the values are correlative there is no problem.
Is this the correct behavior? Maybe I'm missing something?
What happens for example if I need to add a third priority to a certain prefix after doing several changes in the LCR table? I need to re-order every time the "id" values to make them correlatives?
I really hope that someone could give me a hand here.
Ricardo Martinez.-
El Martes, 20 de Octubre de 2009, Ricardo Martinez escribió:
So, when the prefix are with "no correlatives" values in the "id" column seems to be a problem to match the first priority. But when the values are correlative there is no problem.
Is this the correct behavior? Maybe I'm missing something?
What happens for example if I need to add a third priority to a certain prefix after doing several changes in the LCR table? I need to re-order every time the "id" values to make them correlatives?
Please comment with Kamailio version you use. However, it cannot be the expected behaviour but an important bug.
Hello Iñaki. I'm using :
version: kamailio 1.5.2-notls (i386/linux) flags: STATISTICS, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4194304 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: 2:5918M @(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $ main.c compiled on 10:35:04 Sep 1 2009 with gcc 4.1.2
Ricardo.-
-----Mensaje original----- De: users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] En nombre de Iñaki Baz Castillo Enviado el: martes, 20 de octubre de 2009 20:00 Para: users@lists.kamailio.org Asunto: Re: [Kamailio-Users] LCR problem with "id" column and matchpriorities.
El Martes, 20 de Octubre de 2009, Ricardo Martinez escribió:
So, when the prefix are with "no correlatives" values in the "id" column seems to be a problem to match the first priority. But when the values are correlative there is no problem.
Is this the correct behavior? Maybe I'm missing something?
What happens for example if I need to add a third priority to a certain prefix after doing several changes in the LCR table? I need to re-order every time the "id" values to make them correlatives?
Please comment with Kamailio version you use. However, it cannot be the expected behaviour but an important bug.
Ricardo Martinez writes:
This keep happening even if change the priority value 2 for priority value 5. I even changed the priority 1 for priority 0 as follows :
+-----+--------+----------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+-----+--------+----------+--------+----------+
| 89 | 1351 | | 51 | 0 |
| 127 | 1351 | | 43 | 1 |
+-----+--------+----------+--------+----------+
But the LCR module keep using the "second" priority.
After doing some tests I've found two ways to use the "first" priority for the prefix.
2.- Re-ordering the "id" column and using correlative values as indicated in the next table :
mysql> select * from lcr where prefix=0251 order by id;
+-----+--------+----------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+-----+--------+----------+--------+----------+
| 127 | 1351 | | 51 | 1 |
| 128 | 1351 | | 43 | 2 |
+-----+--------+----------+--------+----------+
there is something wrong in above, because where clause is not matching the output.
So, when the prefix are with "no correlatives" values in the "id" column seems to be a problem to match the first priority. But when the values are correlative there is no problem.
are you saying that the problem goes away if you in the first table change id 89 to id 127?
rather that printing your mysql tables, show what lcr dump mi commands give.
-- juha
Hello Juha. Yes, sorry for the "wrong output" I made a mistake trying to protect the data. Let's assume the next table :
mysql> select * from lcr where prefix=1351 order by id; +-----+--------+----------+--------+----------+ | id | prefix | from_uri | grp_id | priority | +-----+--------+----------+--------+----------+ | 127 | 1351 | | 51 | 1 | | 128 | 1351 | | 43 | 2 | +-----+--------+----------+--------+----------+
The dump command shows the correct order and priority for the prefix 1351:
GW:: GRP_ID=51 IP_ADD=XX.XX.XX.13 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=51 IP_ADD=XX.XX.XX.16 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=51 IP_ADD=XX.XX.XX.32 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=51 IP_ADD=XX.XX.XX.35 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 RULE:: PREFIX=1351 FROM_URI= GRP_ID=51 PRIORITY=1 RULE:: PREFIX=1351 FROM_URI= GRP_ID=43 PRIORITY=2
In both cases the "dump" show the correct information.
To solve the problem I just reorder the "records" in the lcr table. I deleted the 89 and 127 record and then added two correlative records : 127 and 128.
Regards, Ricardo.-
-----Mensaje original----- De: Juha Heinanen [mailto:jh@tutpro.com] Enviado el: miércoles, 21 de octubre de 2009 3:10 Para: Ricardo Martinez CC: users@lists.kamailio.org Asunto: [Kamailio-Users] LCR problem with "id" column and match priorities.
Ricardo Martinez writes:
This keep happening even if change the priority value 2 for priority value 5. I even changed the priority 1 for priority 0 as follows :
+-----+--------+----------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+-----+--------+----------+--------+----------+
| 89 | 1351 | | 51 | 0 |
| 127 | 1351 | | 43 | 1 |
+-----+--------+----------+--------+----------+
But the LCR module keep using the "second" priority.
After doing some tests I've found two ways to use the "first" priority for the prefix.
2.- Re-ordering the "id" column and using correlative values as indicated in the next table :
mysql> select * from lcr where prefix=0251 order by id;
+-----+--------+----------+--------+----------+
| id | prefix | from_uri | grp_id | priority |
+-----+--------+----------+--------+----------+
| 127 | 1351 | | 51 | 1 |
| 128 | 1351 | | 43 | 2 |
+-----+--------+----------+--------+----------+
there is something wrong in above, because where clause is not matching the output.
So, when the prefix are with "no correlatives" values in the "id" column seems to be a problem to match the first priority. But when the values are correlative there is no problem.
are you saying that the problem goes away if you in the first table change id 89 to id 127?
rather that printing your mysql tables, show what lcr dump mi commands give.
-- juha
Ricardo Martinez writes:
mysql> select * from lcr where prefix=1351 order by id; +-----+--------+----------+--------+----------+ | id | prefix | from_uri | grp_id | priority | +-----+--------+----------+--------+----------+ | 127 | 1351 | | 51 | 1 | | 128 | 1351 | | 43 | 2 | +-----+--------+----------+--------+----------+
The dump command shows the correct order and priority for the prefix 1351:
GW:: GRP_ID=51 IP_ADD=XX.XX.XX.13 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=51 IP_ADD=XX.XX.XX.16 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=51 IP_ADD=XX.XX.XX.32 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=51 IP_ADD=XX.XX.XX.35 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 RULE:: PREFIX=1351 FROM_URI= GRP_ID=51 PRIORITY=1 RULE:: PREFIX=1351 FROM_URI= GRP_ID=43 PRIORITY=2
there is still something wrong with your data, because grp 43 has no gateways.
i'm trying to reconstruct your configuration.
-- juha
Juha.. I'm just using "snippets" from the configuration and dumps. The grp 43 exist and have their own gateways.
GW:: GRP_ID=43 IP_ADD=XX.XX.XX.13 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1343 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=43 IP_ADD=XX.XX.XX.16 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1343 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=43 IP_ADD=XX.XX.XX.32 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1343 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=43 IP_ADD=XX.XX.XX.35 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1343 WEIGHT=25 FLAGS=0 PING=1
Ricardo.-
-----Mensaje original----- De: Juha Heinanen [mailto:jh@tutpro.com] Enviado el: miércoles, 21 de octubre de 2009 10:25 Para: Ricardo Martinez CC: users@lists.kamailio.org Asunto: RE: [Kamailio-Users] LCR problem with "id" column and match priorities.
Ricardo Martinez writes:
mysql> select * from lcr where prefix=1351 order by id; +-----+--------+----------+--------+----------+ | id | prefix | from_uri | grp_id | priority | +-----+--------+----------+--------+----------+ | 127 | 1351 | | 51 | 1 | | 128 | 1351 | | 43 | 2 | +-----+--------+----------+--------+----------+
The dump command shows the correct order and priority for the prefix 1351:
GW:: GRP_ID=51 IP_ADD=XX.XX.XX.13 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=51 IP_ADD=XX.XX.XX.16 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=51 IP_ADD=XX.XX.XX.32 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 GW:: GRP_ID=51 IP_ADD=XX.XX.XX.35 HOSTNAME= PORT=5060 SCHEME=sip TRANSPORT=udp STRIP=4 TAG=1351 WEIGHT=25 FLAGS=0 PING=1 RULE:: PREFIX=1351 FROM_URI= GRP_ID=51 PRIORITY=1 RULE:: PREFIX=1351 FROM_URI= GRP_ID=43 PRIORITY=2
there is still something wrong with your data, because grp 43 has no gateways.
i'm trying to reconstruct your configuration.
-- juha
ricardo,
i cannot reproduce your problem using sr_3.0 lcr module. i don't have access to k 1.5 system right now, but this part of the code, i.e., selecting gateway groups is the same.
in my test i have
root@rautu:~# sip-proxy_ctl lcr.dump_gws { lcr_id: 1 grp_id: 1 ip_addr: 192.98.101.1 hostname: port: 5060 scheme: sip transport: UDP strip: 0 tag: weight: 1 flags: -1078994760 defunct_until: -1253612224 } { lcr_id: 1 grp_id: 2 ip_addr: 192.98.101.2 hostname: port: 5060 scheme: sip transport: UDP strip: 0 tag: weight: 1 flags: -1078994760 defunct_until: -1253612096 }
root@rautu:~# sip-proxy_ctl lcr.dump_lcrs { lcr_id: 1 prefix: 091351 from_uri: grp_id: 2 priority: 1 } { lcr_id: 1 prefix: 091351 from_uri: grp_id: 1 priority: 2 }
in this case gw from grp 2 is selected and if i swap the priorities, gw from grp 1 is selected. the ids in lcr table are 89 and 127.
-- juha
Hello Juha. This is happening to me with version 1.5.2 svnrevision: 2:5918M. In your test, do you have records between the id's 89 and 127?... could this something to do with it ?
Ricardo.-
-----Mensaje original----- De: Juha Heinanen [mailto:jh@tutpro.com] Enviado el: miércoles, 21 de octubre de 2009 10:51 Para: Ricardo Martinez CC: users@lists.kamailio.org Asunto: RE: [Kamailio-Users] LCR problem with "id" column and match priorities.
ricardo,
i cannot reproduce your problem using sr_3.0 lcr module. i don't have access to k 1.5 system right now, but this part of the code, i.e., selecting gateway groups is the same.
in my test i have
root@rautu:~# sip-proxy_ctl lcr.dump_gws { lcr_id: 1 grp_id: 1 ip_addr: 192.98.101.1 hostname: port: 5060 scheme: sip transport: UDP strip: 0 tag: weight: 1 flags: -1078994760 defunct_until: -1253612224 } { lcr_id: 1 grp_id: 2 ip_addr: 192.98.101.2 hostname: port: 5060 scheme: sip transport: UDP strip: 0 tag: weight: 1 flags: -1078994760 defunct_until: -1253612096 }
root@rautu:~# sip-proxy_ctl lcr.dump_lcrs { lcr_id: 1 prefix: 091351 from_uri: grp_id: 2 priority: 1 } { lcr_id: 1 prefix: 091351 from_uri: grp_id: 1 priority: 2 }
in this case gw from grp 2 is selected and if i swap the priorities, gw from grp 1 is selected. the ids in lcr table are 89 and 127.
-- juha
Ricardo Martinez writes:
This is happening to me with version 1.5.2 svnrevision: 2:5918M. In your test, do you have records between the id's 89 and 127?... could this something to do with it ?
no, just those two records. if you are able to try, i could add some more debugging to the group selection process.
-- juha
This is a production machine.. I can't do too much debug.
Any other ideas?
Ricardo.-
-----Mensaje original----- De: Juha Heinanen [mailto:jh@tutpro.com] Enviado el: miércoles, 21 de octubre de 2009 12:11 Para: Ricardo Martinez CC: users@lists.kamailio.org Asunto: RE: [Kamailio-Users] LCR problem with "id" column and match priorities.
Ricardo Martinez writes:
This is happening to me with version 1.5.2 svnrevision: 2:5918M. In your test, do you have records between the id's 89 and 127?... could this something to do with it ?
no, just those two records. if you are able to try, i could add some more debugging to the group selection process.
-- juha
-
Iñaki Baz Castillo -
jh＠tutpro.com -
Ricardo Martinez