it turned out that the problems ricardo reported on gw selection in lcr module were due to the fact that he has the same gw (same in terms of ip address) in more than one gw group and in each group the gw has different trip/tag attributes.
load_gws() function tries the same gateway only once, but it is not currently well defined from which group gw's attributes are taken when request is sent to the gateway. currently the attributes are taken from the gw group, which happens to be the first in in-memory gw table.
one could think that this is a feature, i.e., if the same gw is in many gw groups, it must have the same attributes in every group. the other alternative is that this is a bug, i.e., same gw's attributes can differ from group to group and the ones that are used must be the ones of the chosen group.
i have a fix written for sr_3.0 lcr module, but i'm hesitating to introduce the fix also to version 1.5, because the fix has not been tested well yet.
any opinions on what should be done?
-- juha
2009/10/28 Juha Heinanen jh@tutpro.com:
it turned out that the problems ricardo reported on gw selection in lcr module were due to the fact that he has the same gw (same in terms of ip address) in more than one gw group and in each group the gw has different trip/tag attributes.
load_gws() function tries the same gateway only once, but it is not currently well defined from which group gw's attributes are taken when request is sent to the gateway. currently the attributes are taken from the gw group, which happens to be the first in in-memory gw table.
What do you mean with "gw group"? I just know "gateways" (in "gw" table) and rules (in "lcr" table).
one could think that this is a feature, i.e., if the same gw is in many gw groups, it must have the same attributes in every group. the other alternative is that this is a bug, i.e., same gw's attributes can differ from group to group and the ones that are used must be the ones of the chosen group.
Definitively I don't understand what you mean with "gw group". Supposing there are just "lcr" and "gw" tables, I understand that each gateway (in "gw") has its own attrbutes and that's all. Do I miss something?
Note that I speak about Kamailio 1.5.
Regards.
Iñaki Baz Castillo writes:
What do you mean with "gw group"? I just know "gateways" (in "gw" table) and rules (in "lcr" table).
gw groups have been in lcr module as long as it has existed. see readme. a gw group consists of one or more gws. it is gw groups that are referred in lcr table, not individual gws. gws of the selected group are then tried based on their weight.
Definitively I don't understand what you mean with "gw group". Supposing there are just "lcr" and "gw" tables, I understand that each gateway (in "gw") has its own attrbutes and that's all. Do I miss something?
yes, each gw has its own attributes, but if the same gw appears in many groups, it can have different attributes (like strip/tag) in each.
-- juha
2009/10/30 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
> What do you mean with "gw group"? I just know "gateways" (in "gw" > table) and rules (in "lcr" table).
gw groups have been in lcr module as long as it has existed. see readme. a gw group consists of one or more gws. it is gw groups that are referred in lcr table, not individual gws. gws of the selected group are then tried based on their weight.
Yes, that's what I know: in lcr table you can define rules (group ids) with different priorities. For each group id, there are N gateways (those defined in "gw" table with matching grp_id), and selected based on weight.
So when a gateway is selected its attributes (strip, tag...) should be loaded. If there are various entries in "gw" table with same ip_addr but different attributes belonging to different groups, then the selected attributes should be those included in the selected "gw" row. How could be different that this? IMHO it's obvious, but perhaps I miss something.
> Definitively I don't understand what you mean with "gw group". > Supposing there are just "lcr" and "gw" tables, I understand that each > gateway (in "gw") has its own attrbutes and that's all. Do I miss > something?
yes, each gw has its own attributes, but if the same gw appears in many groups, it can have different attributes (like strip/tag) in each.
ok, so as I said above, IMHO it makes 100% sense that the selected attributes are those balonging to the selected gateway (by matching "grp_id" of course).
Regards.
Iñaki Baz Castillo writes:
So when a gateway is selected its attributes (strip, tag...) should be loaded. If there are various entries in "gw" table with same ip_addr but different attributes belonging to different groups, then the selected attributes should be those included in the selected "gw" row. How could be different that this? IMHO it's obvious, but perhaps I miss something.
there is a bug in k version of lcr module. if you have many gateways with same ip address, then attributes that are used can belong to any of them. i had assumed that same gateway would have same attributes in all groups.
ok, so as I said above, IMHO it makes 100% sense that the selected attributes are those balonging to the selected gateway (by matching "grp_id" of course).
i gave patch to ricardo to try. i'll apply it to k 1.5 when i hear from him.
-- juha
2009/10/30 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
> So when a gateway is selected its attributes (strip, tag...) should be > loaded. If there are various entries in "gw" table with same ip_addr > but different attributes belonging to different groups, then the > selected attributes should be those included in the selected "gw" row. > How could be different that this? IMHO it's obvious, but perhaps I > miss something.
there is a bug in k version of lcr module. if you have many gateways with same ip address, then attributes that are used can belong to any of them. i had assumed that same gateway would have same attributes in all groups.
There could be some case in which that's not the expected behavior.
> ok, so as I said above, IMHO it makes 100% sense that the selected > attributes are those balonging to the selected gateway (by matching > "grp_id" of course).
i gave patch to ricardo to try. i'll apply it to k 1.5 when i hear from him.
Hope it tries it.
Thanks a lot.
Hello. I compiled the lcr_mod.c that Juha sent to me. And I made a "make install", but I did not restart the kamailio process. Before I restart kamailio I tested one more time the "bug" and I changed again the value in the "id" column from two correlatives "id" to
Id prefix grp_id prio 89 1351 51 1 128 1351 43 2
I was expecting to see the same "weird" behavior described before, instead it started to work flawlessly. So I came up with a doubt. Just putting the lcr.so file in the path "/usr/local/lib/kamailio/modules/" is enough to make the changes work? Or I need to restart the kamailio process in order to make the new compiled file to work?. As I told you before I did not restarted the kamailio process yet and is working as expected.
Hope you can clarify this.
Ricardo.-
-----Mensaje original----- De: users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] En nombre de Iñaki Baz Castillo Enviado el: viernes, 30 de octubre de 2009 11:53 Para: Juha Heinanen CC: users@lists.kamailio.org Asunto: Re: [Kamailio-Users] LCR problem with "id" column and matchpriorities
2009/10/30 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
> So when a gateway is selected its attributes (strip, tag...) should be > loaded. If there are various entries in "gw" table with same ip_addr > but different attributes belonging to different groups, then the > selected attributes should be those included in the selected "gw" row. > How could be different that this? IMHO it's obvious, but perhaps I > miss something.
there is a bug in k version of lcr module. if you have many gateways with same ip address, then attributes that are used can belong to any of them. i had assumed that same gateway would have same attributes in all groups.
There could be some case in which that's not the expected behavior.
> ok, so as I said above, IMHO it makes 100% sense that the selected > attributes are those balonging to the selected gateway (by matching > "grp_id" of course).
i gave patch to ricardo to try. i'll apply it to k 1.5 when i hear from him.
Hope it tries it.
Thanks a lot.
Ricardo Martinez writes:
I compiled the lcr_mod.c that Juha sent to me. And I made a "make install", but I did not restart the kamailio process. Before I restart kamailio I tested one more time the "bug" and I changed again the value in the "id" column from two correlatives "id" to
Id prefix grp_id prio 89 1351 51 1 128 1351 43 2
I was expecting to see the same "weird" behavior described before, instead it started to work flawlessly.
it is pretty much random, which attributes get selected. so sometimes you see it "working" and sometimes not.
Just putting the lcr.so file in the path "/usr/local/lib/kamailio/modules/" is enough to make the changes work? Or I need to restart the kamailio process in order to make the new compiled file to work?.
you need to copy lcr.so to your /usr/lib/kamailio/modules dir and the restart your proxy.
save copy of the original lcr.so in case you need to revert the change.
-- juha
Hello. I was able to find a prefix with the same problem. So I run some test calls to make sure that the problem persist. After I restarted kamailio with the patch the problem with the prefix was solved. I tested a few more prefixes and it seems to be working ok. Anyway, since the random nature of the problem I'm not absolutely sure about is working 100% ok. I'll run a few more test during the next week, I can't make so many changes since is a production machine.
I'll keep you updated. Thanks to Juha for the patch.
Regards, Ricardo.-
-----Mensaje original----- De: Juha Heinanen [mailto:jh@tutpro.com] Enviado el: viernes, 30 de octubre de 2009 16:13 Para: Ricardo Martinez CC: Iñaki Baz Castillo; users@lists.kamailio.org Asunto: RE: [Kamailio-Users] LCR problem with "id" column and matchpriorities
Ricardo Martinez writes:
I compiled the lcr_mod.c that Juha sent to me. And I made a "make install", but I did not restart the kamailio process. Before I restart kamailio I tested one more time the "bug" and I changed again the value in the "id" column from two correlatives "id" to
Id prefix grp_id prio 89 1351 51 1 128 1351 43 2
I was expecting to see the same "weird" behavior described before, instead it started to work flawlessly.
it is pretty much random, which attributes get selected. so sometimes you see it "working" and sometimes not.
Just putting the lcr.so file in the path "/usr/local/lib/kamailio/modules/" is enough to make the changes work? Or I need to restart the kamailio process in order to make the new compiled file to work?.
you need to copy lcr.so to your /usr/lib/kamailio/modules dir and the restart your proxy.
save copy of the original lcr.so in case you need to revert the change.
-- juha
Ricardo Martinez writes:
Anyway, since the random nature of the problem I'm not absolutely sure about is working 100% ok. I'll run a few more test during the next week, I can't make so many changes since is a production machine.
ricardo,
thanks for your tests. let me know when you feel confident with the patch and i'll commit it to k 1.5.
-- juha
-
Iñaki Baz Castillo -
jh＠tutpro.com -
Ricardo Martinez