Hello,
I'm testing LCR module in Kamailio and everything works as expected so far.
Before going further , I just want to ask about how much rule in LCR_rule table and target in LCR_rule_target can Kamailio support .
We are dealing with hundreds of millions of rules and targets.
Kindly advise if Kamailio can support this number of rules.
Thanks
Ali
Ali Taher writes:
Before going further , I just want to ask about how much rule in LCR_rule table and target in LCR_rule_target can Kamailio support .
LCR module stores rules and gateways in shared memory and thus can support as many of those as fits in your allocated shared memory. You can find from lcr_mod.h how much memory one entry requires.
Regarding execution time of load_gws() function, README tells
Execution time of load_gws() function is O(N) * O(M), where N is number of different prefix lengths and M is number of collisions for matching prefix(es) in lcr rules hash table of the LCR instance.
-- Juha
In the past, we used the LCR module with hundreds of thousands (perhaps millions) of entries in the LCR tables. The only drawback was that it took a long time to start up Kamailio (maybe 30 seconds), however it was fast once it was running.
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. -H
On 2015-06-09, 5:54 AM, "Juha Heinanen" jh@tutpro.com wrote:
Ali Taher writes:
Before going further , I just want to ask about how much rule in LCR_rule table and target in LCR_rule_target can Kamailio support .
LCR module stores rules and gateways in shared memory and thus can support as many of those as fits in your allocated shared memory. You can find from lcr_mod.h how much memory one entry requires.
Regarding execution time of load_gws() function, README tells
Execution time of load_gws() function is O(N) * O(M), where N is number of different prefix lengths and M is number of collisions for matching prefix(es) in lcr rules hash table of the LCR instance.
-- 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
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
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
-
Ali Taher -
Henry Fernandes -
Juha Heinanen