UCbuyer Logo

Your Source For Enterprise Communications & Collaboration News & Insights

Next Move: Session Border Controllers (SBCs) Get the Virtualization and Cloud Treatment

Posted by Kevin Gulley

Oct 6, 2015

Cloud_Virtual_Session_Border_Controller_SBC

We’ve seen the virtualization of servers, storage, networks, applications, infrastructure, and probably a few other crucial IT components that I’m forgetting. So why not session border controllers (SBCs)?

SBCs, of course, are crucial to any unified communications implementation, providing functions including security, interworking, transcoding and SIP trunking (as detailed in our previous coverage). Just as with all other forms of virtualization, there are savings to be had in virtualizing the SBC function and providing it as a cloud-based offering.

Explaining Virtual, Cloud-based SBCs

To explain what a virtual, cloud-based SBC is and who might want to make use of it, I talked with Brad Chalker, senior product manager with SBC vendor Sonus Networks.

Providing the SBC function online isn’t much different from most other virtual, cloud-based services or applications. The first key is to be able to perform the SBC functions in software, so they can be extracted from the hardware-based appliance on which they typically run on a user’s premises.

Sonus, for example, has a version of its SBC, dubbed SBC Software Edition (SBC SWe), that can run on virtual servers, Chalker says. The only question then is how, exactly, the service is deployed – whether in a multitenant fashion with multiple users sharing the same SBC instance or in more of a one-to-one fashion.

“We support multiple customers in a single SBC instance,” he says. “But what I’m finding is, because it’s so cost-effective to just bring up another virtual machine in an existing server, most providers offer a single SBC instance per customer.”

Target Market for Cloud-based SBCs: Enterprises and Service Providers

As for who would be interested in a cloud-based SBC, and why, Chalker cites use cases for both enterprises and service providers.

On the enterprise side, he says he sees two main use cases. The first is for an enterprise that’s building a private cloud environment for its own users. All or most of its applications will run in that cloud environment, including the UC infrastructure. It makes sense, then, to also have the SBC running in the same environment.

++++++++++++++++++++
++++++++++++++++++++

Another potential enterprise use is when companies want to provide SBC services to employees in a region where they don’t have a data center. In that case, the company could have a public cloud provider host the SBC in a data center near the target users, who would then tap in from wherever they may be.

Service providers would be similar to the first enterprise example: put the software-based SBC in its own data centers and use it to offer SBC-as-a-Service to customers.

Both enterprises and service providers have been using software-based SBCs for a couple of years now. But Chalker acknowledges some customers have been hesitant to take the plunge, mainly due to concern that a cloud-based SBC won’t be able to keep up with the real-time nature of the sessions SBCs handle.

“The virtual version of our SBC is rock-solid and can provide the same service it does in hardware,” he says. “But convincing the world of that is hard.”

One can imagine. It brings to mind the early days of the whole software-as-a-service movement, or what we once called application service providers (ASPs). It took a name change before that concept caught on in a big way.

Considerations When Using a Cloud-based, Virtual SBC

That said, there are some limited instances when the virtual SBC may need some help from its hardware-based sibling, Chalker says.

Companies that have to perform lots of interworking or transcoding, such as between one type of audio or video codec and another, will need to size the implementation accordingly. Some instances, such as converting between the G.729 and G.711 audio codec standards, are CPU-intensive processes when performed in software, he notes.“Our hardware does it in DSPs that are designed for that task,” Chalker says. “Moving it to general purpose processors to do it in software is hard, although we’ve made tons of advancement in that area.” (Learn more about that from this previous post.)

Still, if you need a whole lot of interworking, it may be wise to supplement the virtual SBC with a hardware-based one, he says. That could mean installing an SBC appliance near the virtual instance in your private or public cloud to handle sessions that require interworking.

Sonus is also working on employing next generation data center technologies to  handle transcoding and interworking functions, including specialized processors intended to offload compute-intensive tasks from traditional CPUs.

Virtualization and cloud computing have proven they can save money by improving utilization rates, saving money on power, management, maintenance and the like. It seems bringing the trend to SBCS is a sound (and inevitable) idea.

What do you think?  Is your company ready to move your SBC to the cloud?  Let us know your thoughts in the comments section below.


 

Topics: cloud, networking, Business Case, SIP, Session Border Controller