In early 2013, more than five years ago, I wrote an article: “Kamailio as an SBC (Session Border Controller)”. It was in response to the often-asked question in the Kamailio and open source-focused VoIP consulting arena about whether Kamailio is an SBC, or can be made to serve as an SBC.
Far from having been put to bed, the question rages on; we get it now more than ever, and certainly even more than at the time the article was written. In that original article, the essential thesis was: “Kind of, depending on what exactly you mean by ‘SBC'”.
That answer continues to be broadly accurate, in our view. However, five years of additional industry experience, observation of broad trends in our corner of the SIP platform-building universe, and Kamailio project evolution have certainly shifted the contours somewhat.
Let’s revisit the topic with an updated 2018 view.
Is it the right question?
In the original article, I made the point that there are two different understandings of “SBC” floating around out there. One is highly nuanced and product-specific, generally held by large telco types who are highly specialised on mainstream commercial SBC platforms. The other view, which enjoys much wider currency, is that of a carrier and/or customer endpoint-facing SIP element that performs traffic aggregation and routing in a rather generic sense. I argued that Kamailio is suitable to the latter, but falls rather short of what qualified specialists mean relative to the former.
Having had half a decade to ponder this, I’ve come to increasingly see it as an ontological problem. The marketing departments of major SBC vendors, starting from Acme Packet, have successfully convinced IP telecoms practitioners, in the enterprise market at least, that this thing called an “SBC” is the basic building block of a “carrier-grade” SIP service delivery platform. It’s a Swiss Army Knife routing box, a reassuring “voice firewall” for helpless Class 5 platforms exposed to the brutal storms and harsh, cold winds of the public Internet, a solution to the problem of juggling multiple signalling IPs, an adaptation layer for non-interoperable behaviour, a place where the vicissitudes of NAT can be sheathed off, and everything in between.
But more importantly, it’s just how it’s done. SBC is the word we use to describe the sort of thing that this eclectic grab-bag o’ SIP gateway is. Rare is a marketing triumph so total that it reshapes our mental categories and how we think about things at an almost metaphysical level, regardless of the objectively available options in underlying technology. It’s on par with the crystallisation of Kleenex® as a moniker for “paper tissue” here in America; only one kind of “paper tissue” is now allowed to exist. It pretty much has to come in a rectangular box with a plastic aperture on the top, regardless of brand. It’s risen to the level of conventional wisdom. All (non-bath) paper tissue putatively comes in such boxes. All tissue is Kleenex®.
In this scenario, I view that as a serious problem. Considering the wealth of concepts that exist in the market space of SIP platform-building, it’s rather grim that our answers about Kamailio in the carrier space so often have to be framed in terms of the SBC question.
A great many generic industrial uses of SBCs amount to little more than “SIP gateway + RTP relay + server-side NAT traversal intelligence in a box”. That’s a more accessible and open-minded framing of the desiderata. Talking to telco-heads about this stuff easily leads to the impression that this vocabulary is Ancient Greek, lost in long-forgot ancient manuscripts. It’s just all subsumed under “SBC”. I’m not trying to lead an anti-corporate revolt here, but from an engineering perspective, it’s really time to reclaim and re-democratise some of this language, lest it give way to trafficking exclusively in trademarked proper nouns of product names.
Some may say that’s rather tendentious, considering we’re an open-source VoIP platform consultancy and product vendor. Maybe so. Far it be from me to say that SBCs don’t have their place; they certainly do. But I think everyone would be well-served if people requesting a “Kamailio SBC replacement” took a step back and asked:
1. What do I actually need?
2. What is the SIP vernacular for that, from the point of view of someone conversant with SIP standards and market realities alike?
3. Does #2 actually compute to an “SBC” from Oracle, Genband, Sansay, Metaswitch, etc?
4. Do I actually need it to behave that way? Why?
5. Is it reasonable or desirable for Kamailio to behave that way?
6. Is there a compelling alternative that has different formal technical properties but substantially the same effect to the bottom line?
We’ve built our entire business on competent exploration of those kinds of issues.
By way of final addendum to the philosophical portion of this article, I will note that the colonisation of The Cloud™ by the service provider world has been productive inasmuch as it has increasingly exposed some of this notion, that Real VoIP Networks are built out of Big SBC Appliances, to be somewhat intellectually fraudulent. (Shameless plug: I gave a whole talk on ITSPs moving to the cloud at Kamailio World 2018 in Berlin recently.) Major SBC vendors, who lobbied so hard to establish this reflexive social convention of the Big SBC Appliance as the universal Lego block of service provider networks, are — without a trace of irony — putting out virtual machine images of their platforms in an effort to remain cloud-relevant.
If you can virtualise a Sonus SBC—it’s just SIP software!—who knows what else you can virtualise instead?
So much, then, for fighting the power.
My original article feebly pointed to rtpproxy as an RTP relay solution and implied that it cannot compete with the horsepower of ASIC-assisted RTP forwarding in proprietary boxes.
A few years ago now, SIPwise released RTPEngine, which most certainly can. RTPEngine uses kernel-mode packet forwarding, making use of the Linux kernel netfilter APIs, to achieve RTP relay at close to wire speed and in a manner which bypasses userspace I/O contention. It’s got a raft of other features, from SRTP/crypto support to WebRTC-friendly ICE, not to mention recent innovations (admittedly in user-space) in call recording and transcoding.
RTPEngine has been shown to be able to handle over 10,000 concurrent bidirectional RTP sessions on commodity hardware, and RTPEngine instances can be trivially scaled out of Kamailio without reloading or restarts, so if that call volume isn’t enough for you, just stack more gateways. It even supports replicating RTP session state to a redundant mate in real time using Redis.
Considering it’s under open-source licence, it’s hard to argue with the unit economics or port density of that, more especially on modern multi-core commodity hardware. It’s hard to see the necessity of dense ASIC-assisted RTP forwarding for cost scaling in 2018.
If topology hiding for commercial reasons is your overriding concern, so that your customers can’t discover your vendors and vice versa, you’ve probably got it in your head that you need a B2BUA (back-to-back user agent).
It’s true; Kamailio is a SIP proxy, and that’s not going to change. Logical call leg A goes in, logical call leg A comes out, largely unadulterated.
Nevertheless, a great deal of work has gone into the topoh and topos modules, which take two different approaches to hiding the network addresses on the other side of Kamailio. Both approaches make use of Kamailio’s ability to remain in the signalling path, both in the context of a SIP transaction and the more persistent SIP dialog. Both comply with the fundamental dictum that a SIP proxy shall not alter the essential state-defining characteristics of a SIP message as constructed by the respective UAs (User Agents) in a manner that shall be known to those UAs.
By the very nature of the complex state management and sleight of the hand that these modules do, there are likely always going to be edge-cases where they don’t work as expected.
For those cases, I continue to recommend a high-performance signalling-only B2BUA in series to the call path. Although the community edition of SEMS (SIP Express Media Server) suffers from some neglect, I still wholeheartedly recommend its SBC module on the basis of sheer performance.
In the original article, I made the claim that many registrars don’t properly support the SIP Path extension. Experience suggests the number of these has dwindled, and Path is a very reasonable way to handle a scenario such as relaying registrations to specific hosted PBX instances inside a private network.
As has been the case for most of the project’s history, Kamailio continues to perform admirably as an actual registrar. If your architecture allows for the concentration of large amounts of registrations in a centralised registrar, this is the best bet.
Truly originating registrations is the province of the UAC module, and some additional management handles have been added to make the process more controllable in real time. Nevertheless, Kamailio cannot reasonably re-originate registrations on a one-to-one basis.
In large-scale platforms, there is significant demand out there for a
registration “middlebox” which can absorb high-frequency re-registrations and parlay them into lower-frequency re-registrations upstream. This requirement arises in large measure due to the irony that many expensive enterprise platforms cannot cope with high message volume nearly as well as open-source, and fall over easily in the face of the registration onslaughts from modern NAT’d customer environments.
OpenSIPS have taken the lead here with the mid-registrar module, which caters to this very need. It is possible to implement something like this manually with Kamailio, but it would take a great deal of state-keeping on the part of the route script programmer. A module to accommodate this niche may be forthcoming in the future.
Edit: As is so often the case, it turns out that perceived limitations are more a failure of the author’s knowledge than technology. While it is true that Kamailio does not have a module specifically named and geared toward the “registrar middlebox” role, Daniel-Constantin Mierla, the chief developer of Kamailio, helpfully pointed out to me in this post on the VoiceOps mailing list that Kamailio’s UAC module has existing functionality that can be used toward the same end. Additionally, one of the virtues of open-source is that enhanced functionality can be added in a reasonable time.
Replication and sharing state
One of the most exciting developments in Kamailio in recent years has been the introduction of DMQ, a SIP-transported distributed replication system with sensible node discovery and failover features.
Previously to DMQ, most Kamailio redundancy strategies involved reliance on shared database backing. This is an inefficient bottleneck and a significant I/O burden. DMQ presents us with the possibility of using in-memory storage backing for things like the registrar and cutting the database bottleneck out. Dialogs can also be replicated with DMQ, as can generic hash tables (frequently used as a distributed data store), and a number of other things. DMQ’s dynamic character is also very complementary to cloud architecture. Watch this space.
SIP over TCP and TLS transports has seen significantly increased uptake in recent years, and session state replication for those remains a sore topic for sophisticated connoisseurs. TCP sessions cannot be transferred from one Kamailio host to another in the event of a failure, as that would take significant operating system network stack involvement. It’s potentially important because we live in a NAT’d world where new TCP connections cannot be opened to customers on demand, instead requiring reuse of existing ones (conforming to the general thesis of SIP Outbound). That level of network stack coupling is achievable by the big SBC brands and remains a selling point, and although worst-case exposure is mitigated by low re-registration intervals, that puts pressure on the throughput side of the registrar and is subject to the minimum re-registration interval of many devices, which remains 60 seconds. Getting databases out of the registration persistence business can help with that nevertheless.
If you are interested in this topic, you should also take a look at OpenIMSCore.
There has been a great deal of interest in Kamailio from mobile operators and MVNOs.
For some years now, Kamailio has supported SIP Outbound (RFC 5626). Use of it in the wild remains very limited, but when you have Outbound-ready clients, you’ll have an Outbound-ready server, a long time in the making.
SIP over WebSocket / WebRTC support
Kamailio has its limits, and there are absolutely cases where a mainstream commercial SBC would be an appropriate choice. For instance, due to its architecture, Kamailio cannot accommodate listening on a large number of network interfaces, so if you are in the business of forwarding signalling across a large amount of customer VLANs/VRFs, you may need an SBC.
More pointedly, Kamailio is a SIP proxy at heart. No amount of clever topology hiding modules can change the very real sense in which the UAs on both sides of Kamailio are interoperating with each other rather than with Kamailio per se. We are a far cry from the mid-2000s, and most mainstream SIP endpoints are shockingly interoperable these days. Nevertheless, if SIP interoperability is your particular woe for any number of niche reasons, remember the rule of “garbage in, garbage out”. At the very least, you would need to pair Kamailio with a B2BUA that can be generous in what it accepts and conservative in what it emits.
Those of you who work with WebRTC know that it presents a rich and fertile field for interoperability woes as well. We tend to take the view that this is part of a larger conversation about whether WebRTC is ready for prime time.
The other key point about Kamailio is that it’s configured in an imperative manner, driven by a programmatic route script. In this respect, it’s not like a finished product with a static feature set that simply need to be enabled or disabled via declarative configuration files. I often compare Kamailio to an SDK with a SIP proxy core, and I think that comparison is meritorious. You will need some software engineering expertise to use Kamailio in a non-trivial way. You must meticulously script your SIP outcomes at a rather low level.
Nevertheless, we come full-circle to the idea that Kamailio presents a compelling, full-featured and viable SBC alternative, if you insist on that terminology. You’ll have to approach the question in a technically SIP-savvy and open-minded way. Moreover, while Kamailio has always catered well to the needs of large-scale service providers, it has evolved even more technical capabilities in recent years to facilitate that.
Service provider work is the only kind of work we do, and the reason we’re in business is because quite a lot of them are quietly subverting conventional SBC wisdom and thinking outside the traditional SBC. Don’t take my word for it; their numbers speak for themselves.