Hello Douglas,
I am using this module in production with more then 400k routes loaded
for 8 different providers and it is working like a charm.
As Henning mentioned, the interface is a little bit cumbersome but usable.
You can put all the carriers under the same table and prioritize the
gateway based on domains. Like tis you don't need to hardcode
anything in the config file.
Carrierroute was designed to deal with a big amount of routing rules
and it is doing an amazing job.
LCR was designed to deal with a limited number of routes/gateways but
it has a different level of flexibility and a more mature interface.
Carrierroute is a brand new module and for sure it will improve in
flexibility as times go by (just like the lcr did along releases).
Hope this helps,
Ovidiu Sas
On Tue, Mar 25, 2008 at 8:29 PM, Douglas Garstang <dougmig33(a)yahoo.com> wrote:
>On Tue, March 25, 2008 3:24 am,
Ovidiu Sas wrote:
>> The database config is right in the README file.
>>
>> Here are the trees:
>> [..]
>> I agree with you that the names are confusing :)
>> You may or may not need to use the subscriber tables, based on what
>> functions are you using.
>> In the example that I gave you, you don't need the location table.
>> Instead, you force a routing tree (in my example is the "default"
>> tree).
>Hi,
>yes, they are probably still a few
things in the whole module terminology
>that are not adequate explained, even if the documentation has already
>seen quite a lot of work. As this module can be used to implement pretty
>complex scenarios, the documentation shows this too, unfortunately.
Complex scenarios? To change the carrier mid-call, you need to hard code it.
Why isn't there a function which retrieves the next carrier from the
database, rather than having to hard code it? There is also NO lcr at all.
We absolutely need lcr. It also seems you are limited to a maximum of two
carriers?
>You need only data from a user
specific table, e.g. subscriber if you need
>to implement user specific routing. e.g. choose carrier A for one user
>set, carrier B for another one.. If you don't need this, then you not need
>to load data from this table.
What about multiple carriers per user with LCR and multiple gateways?
>You have a list of carriers in your
routing space, and each of them can
>have again a list of domains. As every domain can route also to many
>different prefixes (with several hosts per prefix), this module refers to
>them as "trees".
A list of carriers is fine, but how do I switch carriers without hard coding
the carrier in the cr_tree_rewrite_uri() function? Using a simple example,
using carrierroute, if we where calling say prefix 1303, we'd have to call
cr_tree_rewrite_uri('Verizon'), and then if Verizon fails, and we do
failover, call cr_tree_rewrite_uri('Teleglobe'). See the problem here? The
carriers are hard coded in the openser.cfg file, and there's no LCR. What am
I missing? It can't be that horrible.
>If you want to implement simple LCR,
then you don't need the functions
>that allows you to choose a carrier. Again, i agree that the actual
>interface in the stable branch is a little bit cumbersome to use, the new
>interface currently in development will be hopefully address some of this
>issues.
The LCR module seems to suit our need better, but the number of routes is
hard coded in the code to 256. Why is that? We use several carriers, and
each has THOUSANDS of routes. Verizon for example has about 10,000 routes
and Teleglobe has about 7,000 routes. Why is the limit so low? I increased
the limit in lcr_mod.c, and increased the size of the private and shared
memory, which allowed the lcr table to load, but what are the correct
values? How do I know that it won't run out of memory? If that happens, do I
just increase the private and shared memory?
Doug
________________________________
Never miss a thing. Make Yahoo your homepage.