Page 10 of 10
- The LCR is not routing. What do I check?
LCR by default looks for the best match, if it does not find anything it is because there is no match. The most common reason is the notation you are using. LCR should have the rates including the international code: 1613 for the Ottawa region, 1514 for Montreal, and 5255 for Mexico City (just to name some). If your users are dialing 10 digits instead of 11 (missing the leading one for North America), you should implement diaplans to prefix it and send 1613XXXYYYY instead of 613XXXYYYY. Same with international codes, if your users dial 0115255XXXXYYYY, you should configure dialpans to strip the 011 and send 5255XXXXYYYY to the LCR. - My LCR routes, but it is very slow. What's the problem?
There are multiple causes and most of them database related.
If you have many carriers with huge rate lists (let's say you have more than 100k records in your v_lcr table), it is very likely your database needs more memory to void excessive I/O.
Another reason could be a lack of proper indexing. FusionPBX/CoolPBX creates some basic indexing, but it may not be enough on huge datasets.
If you are a FusionPBX user, you may be missing Memcached and mod_memcached. Install them, the LUA part of the LCR takes advantage of it. - My termination carrier offers me two kinds of routes. How do I input that?
Create one carrier per route kind. Let's say CarrierA-R1, and CarrierA-R2 and input each rating list into each carrier. - I am offering my customers Value routes and Premium routes. How do I tell the LCR to use some routes depending on the service?
Edit all your carriers and in the tags textbox input a tag to identify what service kind it belongs. If you already have a tag there, use a comma. Then on the dialpan, set the lcr_tag variable to the right tag. - How do I see what decision the LCR took?
You can use fs_cli to see the actual routing decision or you can later review the CDR details and look for all the lcr_* variables.
";