SBC is a Swiss Army Knife

Not a Toaster after All

I like reading the posts of Andrew Prokop, that’s why his blog SIP Adventures is featured on the sidebar of our blog as one of those we follow. Recently, Andrew posted an interesting and humorous post on Nojitter titled When the Session Border Controller Became a Toaster.

Comparing an SBC to a toaster, Andrew concludes that a commoditized SBC competes on capacity and price. Very much like a toaster that competes on the number of slots it has and the price, as after all, you just “put in a slice of bread and it pops out all nice and brown”.

In his post, Andrew looks for more interesting capabilities (of the SBC, not the toaster) and calls the companies to the challenge.

So Andrew, Challenge Accepted! J, hence this blog post.

A Swiss Army Knife

I view the SBC more as the Swiss Army Knife of VoIP rather than a toaster. Similar to the Swiss Army Knife, the SBC needs to handle many tasks and be flexible enough to live up to those challenges. It need to work in various environments, connect to different network devices and normalize SIP traffic to support this.

SBC is a Swiss Army Knife
This post relates to the challenge presented by Andrew and to his question how it is handled by different SBC vendors, Therefore, I will review how the AudioCodes SBCs not only tackles it but go beyond Andrew’s expectations. Hence, this post is AudioCodes product specific.

Dismantling the Challenge

Licensing – buy a bunch of SBCs and license them as needed from a pool of licenses.

To serve this customer need, AudioCodes provides its EMS (Element Management System) SW that handles among other things SW upgrade and license distribution. This allows service provides and enterprises to buy a pool of license and distribute them as needed between those SBCs from one central management system.

Virtualization – get rid of boxes.

There are a few modes in which an SBC can come. It can be a proprietary HW device, an appliance that comes bundled with the SBC SW of the vendor, SW on a CD that is installed on a server provided by the customer or a virtual SBC running on a virtual machine.

All 4 modes are supported by the AudioCodes SBC. Moreover, it supports Hyper-V, VMware and KVM hypervisors. We are working with NFV orchestrator vendors on integration with their platforms so customers will have a pre-integrated solution for NFV.

Support for WebRTC & Opus in the SBC

There are different ways to support WebRTC. Many implementations have taken the approach of supporting WebRTC in a box external to the SBC. This imposes quality issues as well as architecture complexities. The AudioCodes approach was to provide native support for WebRTC as an integral part of the SBC. This simplifies the architecture and gives the flexibility to bridge WebRTC to any network, including TDM, all with a one box solution.

The other side of WebRTC support is the media itself. Here also, the approach of the AudioCodes SBC is native support for Opus transcoding in the SBC.

The SBC, of course, comes in any of the 4 modes described above so it can be a virtualized SW SBC as well.

The support for WebRTC doesn’t stop at the SBC level but extends to the client. Some implementations have defaulted to G.711 in order to avoid the need for the transcoding of Opus to G.7xx. This is a bad choice as G.711 is not the best option for VoIP over the open Internet.

To solve this issue, AudioCodes has added Opus to the IP Phone. Through this we give our customers the option to hold the rope at both ends. On one hand the enterprise or service provider can use the best codec for VoIP over the Internet – Opus – and on the other hand there is no need for transcoding if the AudioCodes IP Phone is at the client side. Transcoding is, of course, supported for cases that require it.

Webification of Communications

Continuing from WebRTC to the general trend of Webification of communications, more and more non-VoIP developers need to integrate WebRTC into their applications. We have come across cases of services that are pure Web-based that wanted to add voice and video communications with external call control requirements. These developers know how to implement great Web services but they are not experts in VoIP call control. For them we have added REST APIs into the SBC that allow for configuration and 3rd party call control through an interface known and common among Web developers.

Web services and HTTP

Many IP Phones on the market have an integrated browser that fetches screens and information from the server. This works well when working on the same LAN but in cases of remote workers that don’t have a VPN connection to the enterprise things can get tricky. HTTP can go out of the organization to the Internet but the firewall will not allow HTTP traffic to come in to the servers of the enterprise. To solve this, the AudioCodes SBC also functions as an HTTP/HTTPS proxy keeping the PBX secured while supporting remote workers.

Hybrid cloud and on premise

A hybrid cloud and on premise mode means I can separate SBC functionalities and decide which to run in the cloud and which to run on premise. Since enterprise communication requirements and architectures vary, it is important to allow for this flexibility.

The AudioCodes SBC handles this by offering both cloud access SBCs (at the service provider core edge) and on premise SBCs. The enterprise has the flexibility to choose to run functions that are more fit for on premise locally while keeping other functionalities in the cloud. Examples of such functionalities are:

  • Survivability – PSTN backup and alternate WAN connection
  • Quality monitoring – putting this in the enterprise on premise demarcation point allows to know if the problem is between the enterprise and the service provider or perhaps in the enterprise LAN.
  • 911 – In many cases it is better to run 911 services on premise for emergency services
  • Remote worker support – Simplifies the architecture on the SP server side as remote workers access the service provider cloud from the on premise SBC and not directly. By this, they look as if they are an on premise workers.
  • Bandwidth optimization and quality enhancement
  • Normalize the uniqueness of each enterprise simplifying the complexity of service provider access


The service provider and enterprise can decide which of these functions are deployed locally and which in the cloud.

Why this is important

While in a commoditized toaster you simply put in a slice of bread and it pops out all nice and brown, SBCs are far more complex than just port count and price.

The technology advancements of WebRTC, cloud and NFV impose new requirements for media quality and support for heterogeneous environments. This makes the selection process of the SBC that best fits your need far more complex than selecting a new toaster.

3 replies
  1. Alan Percy says:

    I sometimes use a little more “everyday” explaination of the real value of SBCs:

    Have you ever been to the plumbing aisle at Lowes (or any other large national hardware store chain)? You know those rows of boxes filled with various plumbing adapters? The aisle is filled with adapters – 1/2″ PVC to 3/4″ threaded, copper to PEX, hose bibs to flexible…and on and on. That’s what our SBCs and gateways do, converting from one protocol to another, sometimes making minor adjustments, other times major changes to signaling and media.

    The value we bring is we’ve done the work, know what needs fixing and have documented with both parties that it works and will be supported.

    You can think of SBCs and the professional services behind them as “Interoperability as a Service”.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha * Time limit exceeded. Please complete the captcha once again.