Do I Have To? Why UC Needs the SBC

24 Nov 2014

When Microsoft first assigned me to lead one of its Lync partner engineering teams, I had to ramp up quickly on the infrastructure architecture needed to support the product. Most everything made sense to me except the Session Border Controller (SBC). From a simple architecture perspective, it seemed like a firewall solution should obviate the need for an SBC. Moreover, it seemed like the SBC would add latency to the communication traffic, clearly an undesirable outcome, plus it would add costs to the solution without obvious benefit.

My engineering team quickly educated me on why these are common misperceptions.

Corporate firewalls are multi-purpose devices that do not have the handling logic needed to manage voice and related UC communications. For example, imagine that your firm is undergoing a distributed denial of service (DDoS) attack - what happens to your voice traffic? The firewall's reaction is typically to block access to the affected port or, in a more advanced setup, to implement a proxy or filtering strategy that probably won't prioritize voice communications. The DDoS attack, in addition to overloading whatever server is being targeted, can result in a partial or complete loss of UC traffic.

Firewalls also cannot enforce least cost call routing or Call Admission Control (CAC) policies. Least cost routing is important on the cost side, but CAC is critical to ensuring that your VoIP system is not oversubscribed. Enforcement of CAC ensures that there is sufficient bandwidth available for authorized UC traffic.

Turns out that the SBC is the primary line of defense for protecting an enterprise's UC network from IP-based attack. Hackers and hacktavists have gotten clever enough to specifically target UC systems as entry points into the enterprise's networks. They've also gotten quite good at exploiting security holes in voice systems for committing toll fraud, which occurs when hackers access an inadequately protected VoIP system and use it for routing their own calls (or sell on the black market the right of others to illicitly make calls on the exploited network). Firewalls do not natively protect against toll fraud at all. SBCs can also encrypt UC traffic to keep voice and video traffic private as well validate mobile devices in the BYOD world most enterprises live in.

SBCs do impose a slight latency cost on UC traffic, but this is more than offset by the value extended by the SBC to ensuring quality of service (QoS). Policy-based call routing is an important tool in achieving QoS targets in service-level agreements (SLAs). Competent IT executives require SLAs that will provide high-quality real time communications through policies that are enforced by the SBC. This localized policy control will actually eliminate some latency in systems where otherwise a centralized service in some other location has to be queried.

As to costs, a well-configured and well-managed SBC infrastructure will actually reduce the amount of time spent managing the routers and transcoders that would otherwise be required to reproduce what the SBC does. SBCs can also reduce exposure to fraud costs, add financial impact with least cost routing, and help reduce demand pressure on campus bandwidth requirements.

What to look for in an SBC vendor? I am a big fan of simple configuration and management - I don't want to have to send expensive techs out for routine maintenance. I want a solution that is going to scale and integrate with the rest of the UC infrastructure. Obviously, an SBC needs to be performant and upgradeable. And the SBC absolutely has to have the fullest range of competent security features so that my UC platform is protected. And I would also feel a lot better if the SBC vendor was certified by or partnered with the vendor for my UC platform.

Background sources:

This paper is sponsored by Sonus.


There are currently no comments on this article.

You must be a registered user to make comments