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@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.