Posts

Who-needs-an-SBC-Anyway-Thumbnail

Who Needs an SBC Anyway?

[Post is better viewed on the blog Website]

In the early days of SIP, I was working on VoIP protocol stacks at Radvision. As part my role there I used to attend many of the IETF meetings and SIPit interoperability events. The standards where the holy grail and we were a bit naïve in assuming that everyone would be implementing the standard and nothing but the standard…and networks and products would interconnect easily.

The SBCs Come to life

In those days, almost 15 years ago, new startups that focused on something they called a Session Border Controller (SBC) were coming to life. Later down the road of VoIP deployment, more established companies adopted this concept.

I remember a panel at one of the VON shows in which I came out against this trend. At the end of the day, I said, every single SBC function is handled by the standards. As long as the VoIP community will follow the standards, life will be good and simple.

Reality check

I guess it is needless to say that the world of VoIP is more complex than simply implementing the standard. The reality is that networks and products usually don’t interwork without a special effort to make this interworking possible. There are 2 fundamental reasons for this:

  • Standards are complex, very detailed with multiple options, and many times companies interpret them differently
  • Companies want to add their special secret sauce into their products and sometimes, due to technical or commercial reasons, they implement some of the functionalities in a proprietary manner

Regardless of the reasons this is the reality. The naïve position of the past didn’t pass the reality check of real life.

Who-needs-an-SBC-Anyway

The business communications angle

VoIP is deployed in many enterprises and service providers’ networks, yet there are still many enterprises and SMBs that are not connected to VoIP services. Taking a closer look at those already using VoIP in the enterprise or receiving such a service from their service providers, we see several common characteristics:

  • Not all branches use the same PBX. This is due to acquisitions or changes along the life of the network that were not implemented across the board
  • A hosted service was added servicing some of the branches, requiring the connecting of the on-premise PBX and phones with the hosted service network
  • A unified communications service such as Microsoft Lync was added in addition to the existing telephony system requiring the connection of the 2 networks together
  • Survivability needs and local PSTN termination require an on-premise “box” to provide these capabilities

Each one of the points above introduces complexity and a mix of standard and proprietary (or as some vendors call it, “SIP like” or “in the spirit of SIP”). As this phenomenon is the reality of today’s business networks, a smart mediation box is required to connect between the different elements and support these requirements.

What is special about the SBC that makes it the “Swiss Army Knife” of VoIP?

An SBC is like a Swiss Army Knife as it handles many functions. It is well aware of the specific environment in which it is deployed and typically has a flexible configuration that allows adapting it to the specific deployment environment. On the other hand, SBCs are also known for complex configuration due to their complex functionality. As such, a configuration wizard that contains various vendor product profiles for automatic and easy configuration of the SBC for specific deployment scenarios comes in handy for simplifying SBC configuration.  

A typical SBC would have the following functions:

Mitigation & connectivity – connect between different PBXs and different hosted services, connectivity with different SIP trunk providers.

Security – detect security threats such as denial of service, call theft and eavesdropping and protect the network from them. The SBC may also perform encryption/decryption functions to force a policy requiring all outbound traffic to be encrypted.

Quality of Service – the SBC monitors call quality, reports on issues and may enhance quality through media manipulation

Routing & policy enforcement– making sure calls routed based on the enterprise policy-based on user identity & privileges, call termination cost, quality requirements and network conditions

Regulatory compliance – route calls to recording services

The list of functions above is a general and non-exhaustive list. Naturally, there are different functionalities required depending on the type of the SBC, be it an access SBC or an enterprise SBC.

In conclusion, if in the past there was a debate about the need for an SBC, today SBCs are found in most deployments, on-premise as well as in hosted services, providing functionalities such as security and resiliency. Moreover, the SBC is included in many of the architectures defined in the standards.

Image credit: Flickr user Hiking Artist

 

Image: AudioCodes SBC Configuration Wizard

Making SBC Configuration Human

When I visited a 777 cockpit for the first time, what struck me most was all the buttons. I thought to myself, how on earth do the pilots know what to do with them all?

Looking at an SBC configuration reminds me of that same experience and over the years I played aroundwith quite a few SBCs of the SBCs out on the market.

Putting things into perspective, a typical SBC user manual is a few hundred pages long. A typical vendor’s beginner SBC course would run three days or more.

In light of this reality, one of the first questions an experienced customer would ask when considering an SBC would be, “just how complex is the SBC to configure?”

The perception of complexity is well rooted in reality and for good reason. It is not that SBC vendors lack UX (User Experience) knowledge or capabilities. The complexity is derived from the flexibility of the different VoIP standards, which means that every vendor can implement the standards in a different way. An advanced SBC is expected to deal with all of this complexity and interwork between different parts of the network on multiple layers, including SIP, media and IP. The SBC needs to be able to classify groups of users according to multiple attributes, to maintain access lists, manage security, routing and more.

Complexity has its price

The implications of SBC complexity are serious. For one, such complexity raises the cost of installation as technicians need to spend more time on site; it increases the chance of misconfiguration resulting in communication errors and increased support costs. Overall, the complexity of an SBC constitutes a hurdle in the transition to SIP trunking.

But does it have to be that complex?

Consider the following:

  • As it does elsewhere, the 80/20 rule holds true for SBCs as well. 80 percent of SBC customers only use 20 percent of the SBC’s configuration options.
  • The variance between similar deployments of different customers is relatively small. By ‘similar deployments’ I refer to a setup which involves certain kinds of PBX (and software releases), a SBC, and a service provider’s SIP trunk service.

The bottom line is that when looking at two different customers that have similar setups, each customer’s configuration will only differ marginally. The difference would usually include IP addresses and other layer 3 to 4 settings, number manipulation rules, authentication passwords and several additional parameters.

Taking the wizard route

A configuration wizard is a well-known user interface concept common in desktops and web applications. The wizard is used to get the user up and running quickly in just a few steps, leaving the advanced application configuration to a later stage using a parameter centric GUI.Image: AudioCodes SBC Configuration Wizard

The 80/20 rule and the typical similarity between deployments makes the wizard approach a perfect fit for an SBC configuration.

At AudioCodes, we adopted this approach and have developed an SBC configuration wizard application.

Starting with the deployment similarities, we defined “interoperability templates” which in practice is a configuration set which relates to a certain kind of PBX and a service provider’s SIP trunk service. (It can also relate to hosted services and PBX to PBX setups.)

The user configuring the SBC is asked to insert the PBX model, service provider and SBC types into the wizard. After that, all that’s left to do is to provision a few more parameters.

AudioCodes routinely updates its interoperability templates database, which currently comprises over 60 different templates! Every time the SBC wizard is used, it connects to the AudioCodes cloud database and downloads the latest interoperability templates.

After filling in the wizard screens, an SBC configuration file is created. The file can be sent directly to the SBC from the wizard.

In some cases, the configuration will now be complete, leaving the SBC in an operational mode. In other cases, the user would already be able to send calls through the SBC, but would still need to complete the installation by configuring a few additional parameters on the device web GUI.

The end result achieved through using the SBC configuration wizard is a substantial reduction in time and complexity in configuring an AudioCodes SBC. In most cases, it takes no more than five minutes to get initial calls going.

If you, too, have felt “lost in configuration”, where finding the right knob to turn is like finding a needle in a haystack, we would like to hear about your experience and how you navigated through.