1&1 BLOG

Using Kamailio’s Carrierroute module for Least Cost Routing

Kamailio is RFC 3261 SIP v2.0 compliant proxy. Used for SIP signalling routing in medium to large scale networks, it can have several roles like registrar, SIP balancer etc. Kamailio’s core only performs the lower layers of the SIP protocol stack: parsing and transport, but also provides a plugin infrastructure that can be built upon. Modules come into place here, starting from AAA, to transaction and UA support, RADIUS and DIAMETER, DB support (MySQL, Postgresql, Oracle), dialog, authentication etc.

One common task for a SIP Proxy is performing Least Cost Routing (LCR) in a SIP enabled environment. This is achievable by using the carrierroute module developed by 1and1 and released with an open-source license. The carrierroute module provides routing, balancing and blacklisting capabilities, but this discussion is focused on using the module for LCR, the process of selecting an outbound hop based on call costs.

The requirements for carrierroute with LCR support are: Database access and configuration (only SQL databases are accepted, because raw queries are executed), libconfuse and TM, the transaction module. The carrierroute works by matching an R-URI with a set of prefixes stored in a tree (a deterministic finite automaton also called a prefix tree). The longest prefix match overwrites the R-URI to a new destination. The prefix tree is loaded at startup (or reloaded via a fifo command) from the carrierroute table. The table’s fields might look overwhelming at start, but for LCR one easy configuration might look like this:

This means that for calls to Romania (the 40 prefix represents the country code) the selected outbound proxy will be ro-1.carrierr2.com. But longest prefix matching means that calls to Romania destined to a mobile number (the 407 prefix) are routed to ro-2.carrier2.com. Just load the table and call cr_route () in kamailio’s configuration script and you are good to go. Implementations range from a couple of thousands of routing rules in carrierroute table to over 1 million rules. The configuration of rules exceeds the scope of the module.

This is a trivial setup. In real life, you would also want balancing and fallback routes for the same scan_prefix (the prob field handles the probability), but also blacklisting to certain numbers (like 0900 numbers).