22 Apr
2014
22 Apr
'14
12:47 a.m.
Greetings,
I need a little help with the LCR module. I am running Kamailio 4.1.2.
The LCR module is behaving in a way that is inconsistent with our old 1.5
versions. We have a customer that passes a certain caller-id. That
from_uri should be routing over a specific trunk. Here are the relevant
bits of the LCR data from kamcmd.
I would expect gw_index: 7 to match before gw_index: 6 here, but that is
not the case. Any help would be greatly appreciated. Please note, i Have
stripped out a bunch of other routes that are not in play here... hence the
reason gw_index starts at "6".
kamcmd> lcr.dump_gws
{
lcr_id: 1
gw_id: 11
gw_index: 6
gw_name: Route A
scheme: sip
ip_addr: 1.2.3.4
hostname:
port: 5060
params:
transport: UDP
strip: 0
prefix:
tag:
flags: 2
defunct_until: 0
}
{
lcr_id: 1
gw_id: 1
gw_index: 7
gw_name: Route P
scheme: sip
ip_addr: 4.3.2.1
hostname:
port: 5060
params:
transport: UDP
strip: 0
prefix: DLR#
tag:
flags: 0
defunct_until: 0
}
kamcmd> lcr.dump_rules
{
lcr_id: 1
rule_id: 31
prefix: +1
from_uri: 2089328663
request_uri:
stopper: 0
}
{
gw_index: 6
priority: 1
weight: 1
}
{
lcr_id: 1
rule_id: 5
prefix: +1
from_uri:
request_uri:
stopper: 0
}
{
gw_index: 7
priority: 1
weight: 1
}
22 Apr
22 Apr
9:56 a.m.
Geoffrey Mina writes:
The LCR module is behaving in a way that is
inconsistent with our old 1.5
versions. We have a customer that passes a certain caller-id. That
from_uri should be routing over a specific trunk. Here are the relevant
bits of the LCR data from kamcmd.
I would expect gw_index: 7 to match before gw_index: 6 here, but that is
not the case. Any help would be greatly appreciated. Please note, i Have
stripped out a bunch of other routes that are not in play here... hence the
reason gw_index starts at "6".
you didn't show how from uri of the call looks like. if it matches
from_uri: 2089328663, it will also match from_uri: and either rule can
get selected.
-- juha
kamcmd> lcr.dump_rules
{
lcr_id: 1
rule_id: 31
prefix: +1
from_uri: 2089328663
request_uri:
stopper: 0
}
{
gw_index: 6
priority: 1
weight: 1
}
{
lcr_id: 1
rule_id: 5
prefix: +1
from_uri:
request_uri:
stopper: 0
}
{
gw_index: 7
priority: 1
weight: 1
}
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:46 p.m.
OK. WE have made a change so that the priority is 0 for the route that has
the from_uri. We are still not seeing this route get matched properly.
Here is what the INVITE looks like:
INVITE sip:+19137274555@1.2.3.4:5060 SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK5b52e524;rport
From: "2089328663" <sip:2089328663@blah.com>;tag=as37fe796f
To: <sip:+19137274555@1.2.3.4:5060>
Contact: <sip:2089328663@1.2.3.4>
Call-ID: 09ed895a452fac516a0d11e237bd1f35(a)blah.com
CSeq: 102 INVITE
User-Agent: Kamailio
Max-Forwards: 70
Date: Tue, 22 Apr 2014 14:42:16 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
P-Account-ID: 12680001
P-Charge-Info: "4019921313" <sip:4019921313@blah.com>
Content-Type: application/sdp
Content-Length: 236
Here is what lcr.dump_rules looks like:
kamcmd> lcr.dump_rules
{
lcr_id: 1
rule_id: 31
prefix: +1
from_uri: 2089328663
request_uri:
stopper: 0
}
{
gw_index: 6
priority: 0
weight: 1
}
{
lcr_id: 1
rule_id: 5
prefix: +1
from_uri:
request_uri:
stopper: 0
}
{
gw_index: 7
priority: 1
weight: 1
}
On Tue, Apr 22, 2014 at 12:56 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
Geoffrey Mina writes:
The LCR module is behaving in a way that is
inconsistent with our old 1.5
versions. We have a customer that passes a certain caller-id. That
from_uri should be routing over a specific trunk. Here are the relevant
bits of the LCR data from kamcmd.
I would expect gw_index: 7 to match before gw_index: 6 here, but that is
not the case. Any help would be greatly appreciated. Please note, i
Have
stripped out a bunch of other routes that are not
in play here... hence
the
reason gw_index starts at "6".
you didn't show how from uri of the call looks like. if it matches
from_uri: 2089328663, it will also match from_uri: and either rule can
get selected.
-- juha
kamcmd> lcr.dump_rules
{
lcr_id: 1
rule_id: 31
prefix: +1
from_uri: 2089328663
request_uri:
stopper: 0
}
{
gw_index: 6
priority: 1
weight: 1
}
{
lcr_id: 1
rule_id: 5
prefix: +1
from_uri:
request_uri:
stopper: 0
}
{
gw_index: 7
priority: 1
weight: 1
}
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:27 p.m.
Geoffrey Mina writes:
OK. WE have made a change so that the priority is 0
for the route that has
the from_uri. We are still not seeing this route get matched
properly.
i tried to say that from uri plays no role in your lcr setup, because +1
matches both rules 31 and 5. if you want it match only rule 31, you
have to replace empty from pattern in rule 5 with one that does NOT
match to 2089328663 or define another lcr instance for this caller.
-- juha
8:01 p.m.
OK, has this behavior changed since Kamailio 1.5 because this previously
worked.
Right now, I would think that with our Priority of 0 on the route with the
from_URI match, the algorithm should always look at that one first and
route the calls accordingly.
Since we have the priority correctly set to evaluate in the order we want,
what next can we look to?
On Tue, Apr 22, 2014 at 9:27 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
Geoffrey Mina writes:
OK. WE have made a change so that the priority
is 0 for the route that
has
the from_uri. We are still not seeing this route
get matched
properly.
i tried to say that from uri plays no role in your lcr setup, because +1
matches both rules 31 and 5. if you want it match only rule 31, you
have to replace empty from pattern in rule 5 with one that does NOT
match to 2089328663 or define another lcr instance for this caller.
-- juha
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
23 Apr
23 Apr
9:47 a.m.
Geoffrey Mina writes:
Right now, I would think that with our Priority of 0
on the route with the
from_URI match, the algorithm should always look at that one first and
route the calls accordingly.
Since we have the priority correctly set to evaluate in the order we want,
what next can we look to?
i made same kind of test that you have and routing worked as expected,
i.e., when request uri matched a common prefix, the one with lower
priority was tried first.
if you remove from uri constraint from the rule that had it, is lower
priority gw then selected first or doesn't priorities work at all for
you?
-- juha
26 Apr
26 Apr
2:24 a.m.
Juha,
Thank you for all of your help so far, but we are still totally stuck
trying to make this work. We have double and triple checked our
configuration, database, and INVITE and everything is in-line with what
previously worked (in 1.5). We are running 4.1.3, is that what you were
testing on?
What can I do to debug this? I checked and we aren't seeing any of the
"failed to compile regex" errors in the logs. We have 4 servers that are
all displaying the same behavior (read: ignoring the from_uri match on a
lower priority).
Any further help would be really appreciated.
Thanks,
Geoff
8:05 a.m.
Geoffrey Mina writes:
What can I do to debug this? I checked and we
aren't seeing any of the
"failed to compile regex" errors in the logs. We have 4 servers that are
all displaying the same behavior (read: ignoring the from_uri match on a
lower priority).
you didn't answer if this issue is related to from uri pattern or
priorities in general. if you remove from uri patterns, do priorities
then work?
if you can give me a simple example configuration where this problem
appears, i'll try it myself.
-- juha
3892
days inactive
3897
days old
7 comments
2 participants
participants (2)
-
Geoffrey Mina -
Juha Heinanen