We’ve written a fair amount on this site about session border controllers (SBCs) and the various functions they perform relative to real-time, IP-based communications. But we haven’t really tackled head-on the topic of how to know when you need an SBC and, once you determine you do, how to decide on the best deployment option.
How to Determine Whether You Need an SBC
Deciding whether you need an SBC is a pretty straightforward proposition. As you migrate real-time applications such as voice, video and instant messaging to IP-based services, chances are you’re going to need an SBC. That is, you will if you care at all about security, interoperability, performance and scalability.
As we’ve covered previously, real-time IP applications are managed using the session initiation protocol (SIP) for session setup and teardown. While traditional firewalls provide security for IP-based data sessions, they are not built to deal with the real-time nature of SIP traffic. SBCs are, and will be able to prevent denial of service (DOS) attacks while supporting security features such as topology hiding, encryption (for both media content such as phone calls as well as signaling data), NAT traversal and more.
Keeping your network secure is likely reason enough to invest in an SBC. But it also performs a number of other valuable functions, says Brad Chalker, senior product manager with SBC vendor Sonus Networks. They include interworking (and possibly transcoding) between unified communications systems, SIP implementations, legacy phone networks, different codecs and more. If you’ve got more than one vendor’s UC implementation within your enterprise, such as from a merger, an SBC will help them talk to each other.
Similarly, an SBC provides interworking between different signaling systems, such as the DTMF signaling common with legacy telephone networks and IP-based PBXs. That’s crucial if you don’t want to throw away investments in legacy interactive voice response systems, for example. SBCs can also save money by helping to choose the most effective, least-cost route for sessions over your network, Chalker says.
Choosing Among the SBC Deployment Options
So hopefully it’s now clear that if you’re using SIP-enabled applications, you need an SBC. The next question, then, is how to determine the best deployment option. You’ve got several, Chalker notes, namely:
- Installing and managing an SBC appliance on your own premise. This is a viable option if you’re confident you’ve got the IT know-how and availability to take on the task of not only installing the SBC but managing it over the long haul.
- Installing and managing virtual SBC software on your premise. If you’re already virtualizing other resources, such as servers, firewalls, load balancers and the like, then it likely makes sense to go with a virtual SBC as well. You get all the same benefits as with any other virtual implementation in terms of greater resource utilization, lower cost and ease of management.
- Have a third party reseller or service provider install and manage an SBC appliance or virtual SBC on your premise. This is a good option if you do not have the spare IT cycles or expertise to install and manage an SBC. Or maybe you just prefer to dedicate those IT resources to other tasks and more strategic IT efforts.
- Buying an SBC-as-a-service (SBCaaS) offering from a service provider. The rationale here is similar to number 3, the only difference being your level of comfort with having no equipment on your premises and instead having the entire SBC hosted in a virtualized, cloud environment.
I talked with Chalker quite a bit about the whole topic of outsourcing the SBC function and will delve into it more in a future post, exploring the various options and rationales for going the service provider route as well as the benefits to be had.