One of the most common enquiries we get is about using Kamailio as an SBC. I don’t think it’s an exaggeration to say it’s our top FAQ, as a consulting organisation.
“SBC” is a term that has a lot of different meanings to different people in different contexts. To answer this question, you need to:
- Develop a proper understanding of “SBC”.
- Determine whether you actually need an SBC, enlightened by a correct understanding of the concept.
- Evaluate the extent to which Kamailio can play this role.
I think it’s safe to say, from my observations, that there are two primary understandings of the concept of an SBC: a pedestrian understanding, and a professional one, as used in an intra-industrial/domain-specific context.
- Pedestrian definition: some kind of network edge proxy, administrative border and/or call transit element at the edge of a voice network, designed to face carriers and/or peer networks. It is expected to provide routing functionality and some security and rate-limiting type capabilities, to shield the internal network elements from DDoS attacks and so on.
When most people come along and ask me, “Can you deploy Kamailio for us as an SBC?”, they are proceeding from the pedestrian definition, and haven’t had to look at the terminology critically. It often turns out that they are just looking for an aggregation point to condense their variable IP endpoints to a single signaling endpoint, in order to interface with a carrier. Many other customers are looking for LCR (least cost routing) gateway functionality, or some other type of internetwork routing intelligence. They, too, some reason choose to put the “SBC” label on it, because that’s what industry marketing has taught them to do for anything that sits at the network edge.
That’s not what an SBC is, at least, not to professional VoIP topology architects and network implementors.
- Professional definition: an appliance with a SIP B2BUA (back-to-back user agent) core, usually able to do some combination of policy-based access control, transcoding, topology concealment, call accounting (usually via RADIUS), QoS and call quality statistics, etc.
- Ability to gracefully single-source and distributed handle attacks from the Internet
- Traffic from numerous VRFs (so that customer A’s 10.0.0.1 is not the same as customer B’s 10.0.0.1)
- Hosted NAT Traversal
- Transcoding media
- Lawful Intercept hooks
- Demultiplexed SIP trunks (so that each SIP “path” can come from a different IP address or port)
- Constraints like Calls-per-second or Concurrent-calls (so legitimate customers don’t cause a failure)
- Failover from one SBC to another
- Distributed SBC models where one box handles signaling and many more handle media
- 802.1q VLAN tagging support
- Support for failover to BroadWorks-style registrar redundancy (where the mated registrar servers have distinct IP addresses)
- SNMP management
- Interworking SIP/UDP and SIP/TCP
- Jumbo SIP (SIP datagrams over 1300 bytes, out of compliance with RFC 3261)
- SIP/TLS and SRTP, and decryption thereof
- Configurable media management (to release media when possible, steer it through the SBC when not)
Higher-end SBCs usually also incorporate at least for ASIC (application-specific integrated circuit)-assisted RTP relay and transcoding, in order to achieve higher port densities.
This is the sort of thing I, and others in my profession, hear when customers say “SBC”. In most cases, that’s probably not what they mean, but it’s what we hear. When I tell people all this, they usually say, “no, no, I don’t need all that”. If you don’t need the bulk of the aforementioned capabilities, you don’t need an SBC, and you shouldn’t call it that. Perhaps this meta draft can help with the classification of the network element itself.
Kamailio fails out of the gate on the B2BUA aspect, which seems to be a requirement of the SBC concept. A B2BUA accepts one logical call leg A, and creates another, logically unrelated call leg B, and bridges signaling events between them in as transparent or opaque a manner as it desires. A proxy receives logical call leg A, and pushes call leg A right back out, and by and large, that’s what proxies do–they proxy; garbage in, garbage out.
There are relatively few things that a proxy can modify in a SIP request or reply, formally speaking. It can modify the Request URI and a few other message fields, and it can attach custom headers. However, critically, it cannot rewrite or fundamentally regenerate the request or reply, as a B2BUA might. This makes it a rather poor mediator for interoperability issues and security purposes–a key selling point of SBCs.
Kamailio has some hacks that allow it to go a bit beyond these limitations, in defiance of its standards-prescribed role as a proxy element, such as the UAC module’s ability to statefully rewrite the From and To header, and the topology hiding module‘s stateful encryption of topology-revealing details in Record-Route header parameters. However, these should be understood for what they are: hacks with limitations–limitations that a B2BUA does not have.
Kamailio can use rtpproxy to relay RTP on commodity hardware, which is mostly done for far-end NAT traversal (which Kamailio supports through the nathelper module) and topology concealment reasons (combined with topoh). This horizontally scales rather well, but is not exactly like the port-dense ASIC-driven RTP forwarding setup of a commercial SBC. Also, there is no transcoding capability in rtpproxy.
With some effort, Kamailio can be set up to bridge signaling between multiple network interfaces, and rtpproxy can operate in a “bridging mode” which allows it do to the same. However, implementing this is challenging, and does not provide the multi-realm flexibility of an SBC; it is, by its nature, a hard-coded setup, and if you’re expecting to maintain “realms” in half a dozen subnets, as with an SBC, you’re setting yourself up for a world of pain. It is technically possible, but just because some things can be done does not mean they should, methodologically speaking, be done.
Kamailio can relay REGISTER messages upstream, and supports the Path extension. Whether the upstream registrar supports it is another question; many do not. It is possible to do some clever hacking involving encoding of the original Contact URI received from the registrant into the Contact header, but this is a dirty hack, not a true registrar front-end.
In sum, it is possible to deploy Kamailio in select subsets of an SBC role, but the probability is quite high that “SBC” is not really what is meant when the term is used. Things I’ve seen classified as SBCs in the context of Kamailio project requisitions include:
- Far-end NAT traversal gateways.
- Load balancers.
- Proxy-based security elements.
- Traffic aggregation proxies.
- Intelligent routing gateways for voice application silos.
- Least Cost Routing gateways.
- Class 4 carrier trunking interfaces.
None of these things, in and of themselves, an SBC make. In fact, most of these things are functions that an SBC would not directly perform, though it is likely to front-end network elements that do perform them.
On the other hand, trying to front-end a classic Class 5 type SIP subscriber softswitch, such as a Metaswitch or a Broadsoft assembly, ought to be classified as an anti-pattern. While it is possible, in principle, cajole a reluctant proxy into a mostly-functional role doing that, it is the wrong tool for the job, it will create as many management problems as the technical objectives it crudely achieves. There are lots of threads on sr-users from hapless souls who got stuck in the quagmire of multiple Record-Route headers corresponding to different forwarding network interfaces, and conditional rewriting of SDP based on the originating and terminating subnet, and keeping it all straight by encoding it in some sort of dialog-persistent parameters. From a best-practical point of view, you really don’t want to go there.
Bottom line: Kamailio is not an SBC. Not at all. It’s a proxy with some SIP server features inside. However, depending on what you’re actually looking for and whether you’re using the term correctly, that may not be a problem.