The problem is that the LCR module matches to the longest prefix rather than longest prefix per route/carrier. Take a look at the example below.
Let’s say you have the following info in your LCR.
Prefix, Carrier/Route, Rate 1306, A, 1.5 1306343, A, 1.7 1306, B, 1.4
If you have phone number 13063431111, the LCR module matches it to the longest prefix (1306343) and routes the call to Carrier A. However, that is incorrect. It should match it to Carrier B which is the cheapest. Carrier B has provided a rate of 1.4 for all calls with prefix 1306.
-H
On 2015-06-09, 12:15 PM, "Juha Heinanen" jh@tutpro.com wrote:
Henry Fernandes writes:
We eventually decided to stop using the LCR module because it doesn¹t implement LCR in the way that most people think of LCR. It doesn¹t obtain the most specific prefix match for a called number.
Could you give more details, since longest prefix match is the most important match criteria:
When the function load_gws() is called, matching gateways (that are not currently designated as defunct) are ordered for forwarding purposes as follows:
(1) according to longest Request-URI user part match
(2) according to tuple's priority
(3) according to tuple's randomized weight
-- 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