Discussion here on Hacker News.
Those of you who follow 2600hz know that we use OpenSIPs as our Session Border Controller, or perhaps more accurately, our Edge Proxy. This is about to change: 2600hz is moving to Kamailio.
Why?
SBCs or Edge Proxies are critical to the success of Communications Infrastructures. They serve as Traffic cops, permitting or denying access to our sensitive Core Infrastructure. We home equipment to at least two different proxies in order to facilitate failover in the event of an emergency or an outage. OpenSIPs has served us really well in this regard, and it’s not for performance reasons that we’re moving to Kamailio. In fact, in our testing, OpenSIPs and Kamailio performed almost identically, but there are key design decisions related to scripting, and a greater proliferation of Kamailio Infrastructure in the industry. Put simply, writing Scripts in OpenSIPs isn’t fun, and if there’s no performance gap between the two products, why not use the route with less friction?
Scripting
Writing Scripts for SBCs is critically important to our Infrastructure and our overall design. We write a lot of scripts, and they tend to have a lot of flags (defined functions). In OpenSIPs, Flags are simply listed as Flag1, Flag2, Flag3, ad infinitum… which is fine until you have a problem. Imagine debugging a script with four flags in it. Normally when you’re debugging, the name of the items inside of your script hint to the contents of your functions, but this is not the case in OpenSIPS. On the other hand, Kamailio supports the same Flag based scripting system, with the addition of naming flags. This is simple, but a critically important detail for us. If we have to rewrite sections of an SBC, we’d rather do it in a way that we’ll be able to understand later, as opposed to spending lots of time deciphering labels that don’t give any meaning. One of the problems we’re scripting around now has to do with the way Carriers present IPs to us in their system. They present Private IPs to us in a certain section of their API, and neither Kamailio or OpenSIPs can natively deal with this edge use case. A script with five flags becomes basically indecipherable, such that the engineer who wrote it originally has to essentially re-engineer the code in the event of a problem. Naming conventions for Flags are critically important.
Check out these code examples, see if you can note the differences (the code is functionally the same):
Kamailio:
if (is_method(“OPTIONS”)) {
if (isflagset(FLAG_INTERNALLY_SOURCED)) {
route(INTERNAL_TO_EXTERNAL_RELAY);
} else {
sl_send_reply(“503”, “Options Reply”);
}
exit;
}
Opensips:
if (is_method(“OPTIONS”)) {
if (isflagset(26)) {
route(internal_to_external_relay);
} else {
sl_send_reply(“503”, “Options Reply”);
}
exit;In the case of Kamailio we have the additional information “INTERNALLY_SOURCED” appended to the flag, whereas in OpenSIPs, we just have “Flag26”. This makes decoding finished code a pinch versus tedium.
Check out two more code examples here:
Retrieving Caching Data
Opensips:
cache_fetch(“local”, “$ci”, $avp(i:56))
Kamailio:
$var(prefered_route) = $sht(associations=>$ci);
Setting the reply timer
Opensips:
$avp(s:final_reply_timer) = 2;
Kamailio:
t_set_fr(0, 1000);
In each example, identifying what’s happening for a command is much easier in Kamailio.
But Naming conventions are hardly the only reason we’re making this change. We do a lot of work with new technology, in particular HTML5. Kamailio has a stricter adherence to modern technology (less backwards compatibility for the sake of making the stuff we do today easier), and they seem to be more prolific in the industry. This is purely anecdotal, but in our experience, many of our larger clients are already using Kamailio for their SBCs, and given how close these various technologies are to each other, it makes sense for us to use what our clients are already using if there’s no downside. And why would there be? All of the open-SBC projects come from one root project: OpenSER.
[http://sip-router.org/wp-images/sip-router-history.jpg]
In watching the development cycles for these projects, we note that Kamailio tends to release the features we’re looking for before OpenSIPS (our specific example in this case is WebRTC, for which support was present in Kamailio before OpenSIPS). Both projects have a lot of common modules, and the modules tend to proliferate between the platforms pretty quickly. Calling these two platforms similar in terms of design would be an understatement. Consider the two screenshots from each projects respective documentation:
Here’s Kamailio, and here’s OpenSIPS:
Notice anything similar? All of the modules are nearly identical, and it’s pretty convenient.
When we started our Kazoo Project, it seemed that OpenSIPs was the dominant player in terms of performance and development. Kamailio does; however, appear to be more widely used in the industry, and we think it’s now a much more even fight. We note that the JSON module for Kamailio was written and contributed by FlowRoute, a well regarded SIP Trunking Service. To our minds, a more active development community means that other users are likely to help solve bottlenecks for us, so we spend less time worrying about our proxy, and more time writing fun new applications!
Conclusion:
We’re switching to Kamailio because:
- Many of our Major Clients already use it
- The Naming Conventions are more sensible
- The Pace of Innovation on Kamailio is faster
![[http://sip-router.org/wp-images/sip-router-history.jpg]](http://sip-router.org/wp-images/sip-router-history.jpg){kind=link}