We are looking at offloading routing logic out of our existing softswitch using openser as an external redirect server. Our routing logic is not terribly complicated and I think both carrierroute and LCR modules would be able to handle it but we have a pretty large route list table with around 30 million records (our routing table is 300k codes but keep different tables per client), 25-30 calls per sec would be enough. From a performance point of view, what would be the best bet within both modules? also, are both modules actively maintained?

On Monday 06 September 2010, anthony thomas wrote: Hello Anthony, well, i think this depends on the database configuration and memory setup of the machine, but normally this is what you want. I was referring to the fact that in my experience one not insert complete number ranges in the database but certain prefixes, and then do a longest prefix match to find the optimal route. But of course you could do also something like this with some SQL. I was referring to the setup you just described, use a standard DB with the a module like sqlops instead of something more specialized, e.g. cr.

From: Alex Balashov <abalashov(a)evaristesys.com> Subject: Re: [SR-Users] High performance routing options To: "Daniel-Constantin Mierla" <miconda(a)gmail.com> Cc: "sr-users(a)lists.sip-router.org" <sr-users(a)lists.sip-router.org> Date: Monday, September 6, 2010, 12:57 PM We use this in our solutions and search hundreds of millions of routes with it in 2-3 ms.  It works very well, to say the least, because it is an approach that allows application of complex business logic (using stored procedures) to the results, something which is much harder with a more primitive (if faster) in-memory structure.  Best of all, it is specifically designed to deal with the problem of variable-length prefixes, so many of the prefix length constraints and/or homogeneity requirements of other routing and LCR engines are eliminated. It is not possible to say whether a database-backed structure is loaded "from memory"; this is a gross oversimplification of a very complex issue.  Clearly, an RDBM cannot load all data into heap;  there is plenty of demand-loading of data from disk.  RDBM caching, filesystem and I/O caching, disk caching, etc. all play a big role in what the result will actually look like from a median performance perspective. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Sep 6, 2010, at 12:06 PM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: wrote: (we already use it for our supports proper prefix matching (i think postgres is done in memory, right? configuration and memory setup of was referring to the fact number ranges in the database match to find the optimal like this with some SQL. custom module?" use a standard DB with the a specialized, e.g. cr. details: sr-users mailing list _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

We use this in our solutions and search hundreds of millions of routes with it in 2-3 ms. It works very well, to say the least, because it is an approach that allows application of complex business logic (using stored procedures) to the results, something which is much harder with a more primitive (if faster) in-memory structure. Best of all, it is specifically designed to deal with the problem of variable- length prefixes, so many of the prefix length constraints and/or homogeneity requirements of other routing and LCR engines are eliminated.

It is not possible to say whether a database-backed structure is loaded "from memory"; this is a gross oversimplification of a very complex issue. [..]