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 }
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
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
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
-
Geoffrey Mina -
Juha Heinanen