Kamailio as an SBC (Session Border Controller)

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.

The most exhaustive list of SBC capabilities I’ve seen lately was compiled by Mark R. Lindsey in this post on the VoiceOps list, which I will quote here (with his prior permission):

  • 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.
  • Registrars.
  • 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.


7 Comments on “Kamailio as an SBC (Session Border Controller)”

  1. Thank you. This was very helpful. Now to explain this to customers 🙂

    Like

  2. Great article, thanks for posting. We used this to create an informational post for our own customers. Thanks.

    Like

  3. Brian LaVallee says:

    Your professional definition of an SBC is a bit off the mark. From inception, SBC’s had the sole purpose of NAT Traversal. To overcome the NAT issue inherent in SIP.

    Because an SBC has to pull the packet apart and reassemble it, SBC vendors saw the opportunity to add other functionality. Like firewall, and everything else under the sun. Deep packet inspection is easy when the packet is already laid out.

    This ultimately started an arms-race of one-upmanship, as each vendor tried to outdo the competition with more and more features.

    Out of necessity, SBC’s became B2BUA’s for better control of the packets it was responsible for. This is because the SBC had to store the status of each packet in the SIP conversation. By adding B2BUA functionality, it allowed the SBC recover that storage space once a session ended.

    In the end, the ONLY reason to install an SBC is NAT Traversal, all of the other features are just nice to have.

    Like

  4. Hi Brian, thanks for your contribution. Do you have any historical evidence for the claim that SBCs were initially conceived solely as NAT traversal fixtures?

    Like

    • Brian LaVallee says:

      After a quick search, this article probably provides enough historical evidence. http://goo.gl/o2ZoeP

      Reading the article (years later), I forgot how horrible SIP inter-operation really was between vendors. The unofficial definition of SIP was actually: Should Inter-operate Properly.

      In late 2000, SBC vendors primarily provided a solution for the NAT traversal issue. Of course anything on the network edge does need a layer of security. So an SBC would naturally provide security on the edge of the network. Some models even translated the SIP messages of vendor A to something the equipment from vendor B could understand.

      I think the most absurd feature that SBC vendors ever promoted was “Topology Concealment.” Think about it for a second, any private network (RFC1918) is already concealed.

      It was really just a marketing ploy to convince carriers to place an SBC inside their private networks, where NAT traversal wasn’t an issue.

      Like

  5. Max says:

    I was glad to see this article because really explain what an SBC really is….however I found that it should be more exhaustive regarding alternatives….OK, Kamailio is NOT as SBC, and now? What could be the alternative? An hardware SBC? Or what else?
    BTW, great article and very professional! Thank you so much

    Like

  6. Mike D. says:

    I know this is an older article, but still on point. If you wanted to interface between multiple clients and multiple providers, handling the signalling, media and of course logging, what route would you recommend? This is all of course considering open source type projects vs hardware.

    Thanks!

    Like


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s