29 Oct
2009
29 Oct
'09
1:54 a.m.
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
30 Oct
30 Oct
7:01 p.m.
New subject: [Kamailio-Users] LCR problem with "id" column and match priorities
2009/10/28 Juha Heinanen <jh(a)tutpro.com>om>:
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.
7:12 p.m.
New subject: [Kamailio-Users] LCR problem with "id" column and match priorities
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
7:27 p.m.
New subject: [Kamailio-Users] LCR problem with "id" column and match priorities
2009/10/30 Juha Heinanen <jh(a)tutpro.com>om>:
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
<ibc(a)aliax.net>
Iñaki Baz Castillo writes:
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.
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.
7:45 p.m.
New subject: [Kamailio-Users] LCR problem with "id" column and match priorities
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
7:53 p.m.
New subject: [Kamailio-Users] LCR problem with "id" column and match priorities
2009/10/30 Juha Heinanen <jh(a)tutpro.com>om>:
Hope it tries it.
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Iñaki Baz Castillo writes:
There could be some case in which that's not the expected behavior.
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. 
11:52 p.m.
New subject: [Kamailio-Users] LCR problem with "id" column and matchpriorities
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(a)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(a)lists.kamailio.org
Asunto: Re: [Kamailio-Users] LCR problem with "id" column and matchpriorities
2009/10/30 Juha Heinanen <jh(a)tutpro.com>om>:
Hope it tries it.
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Iñaki Baz Castillo writes:
There could be some case in which that's not the expected behavior.
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.
31 Oct
31 Oct
12:13 a.m.
New subject: [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
4 Nov
4 Nov
7:39 p.m.
New subject: [Kamailio-Users] LCR problem with "id" column and matchpriorities
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(a)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
5 Nov
5 Nov
5:08 p.m.
New subject: [Kamailio-Users] LCR problem with "id" column and matchpriorities
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
5289
days inactive
5297
days old
9 comments
3 participants
participants (3)
-
Iñaki Baz Castillo -
jh＠tutpro.com -
Ricardo Martinez