Sponsored By

Enterprise SBCs: Deployment Secret RevealedEnterprise SBCs: Deployment Secret Revealed

Security often gets top billing when talking about why enterprises need session border controllers, but that's not really the primary driver.

Alan Percy

December 24, 2014

3 Min Read
No Jitter logo in a gray background | No Jitter

Security often gets top billing when talking about why enterprises need session border controllers, but that's not really the primary driver.

It's time to come clean. I have a little secret that I want to share with you about enterprise session border controllers.

During the early days of enterprise SBCs, most of the marketing messages and pitches we created would start with dire warnings of SIP security holes, what ifs, doom and gloom of what would happen if an intruder hacked the enterprise. Toll fraud, eavesdropping, theft of services and even the boogeyman under your desk were lurking around the corner, just waiting to ruin your IP PBX or contact center and destroy your career if you didn't do something now!

You see, fear sells. But the reality is much different.

The real reasons an enterprise deploys SBCs have a lot more to do with getting the work done than worrying about the boogeyman.

Getting the work done requires interoperability -- without interoperability, in fact, none of the other issues really matter. SIP as a standard is blessed and cursed at the same time. The openness of the protocol and the IETF RFC process has allowed developers to create SIP extensions and enhancements -- which, in turn, makes for its biggest flaw. Which enhancements and derivatives does your service provider use? Which does the application require? Making things more complicated, most enterprises expect to use multiple applications from different vendors, which means an interoperability headache.

What the SBCs really bring to the enterprise is interoperability, which sometimes doesn't come easy. Getting a particular service provider's SIP trunking to work with a contact center could require some simple header fixup... or it could require media conversion to a different codec (transcoding). You really don't know unless you do extensive homework on both sides of the puzzle. If there are incompatibilities, you'd likely grow old waiting for a service provider or an application vendor to make the required changes and retest the entire system.

I often describe what we do as "interoperability as a service," building a library of test cases, documents and tools that facilitate connectivity between systems. When selecting an SBC vendor, look for the commitment to broad SIP trunking compatibility and an extensive list of applications that are likely to be part of your enterprise. Does the vendor offer professional services to aid in custom or specialized integrations? If something changes down the road, what services are available to prevent service interruptions?

Once the interoperability is in place, then the focus turns to security and other issues.

It may be true that fear sells, but the reality is that interoperability gets the work done.

We'll be talking about this and more during Enterprise Connect 2015 in a session titled, "SBCs: The Evolution Continues," on Tuesday, March 17, 2015, from 8:00 a.m. to 8:45 a.m. You can also learn more in the SBC Resource Center, an online education tool from AudioCodes.

Please do share your feedback in the comments below!

About the Author

Alan Percy

Alan Percy is Senior Director of Product Marketing at Dialogic, responsible for marketing of the the company's media server and WebRTC solutions, with the goal of helping developers build new and innovative applications for new networks. Alan focuses heavily on enterprise applications, whether on premises or in the cloud, including UC, contact center, collaboration and conferencing, emergency services and E911, and hosted services. Previously, Alan served as Director of Market Development at AudioCodes. He is a frequent industry speaker and contributes to a number of industry journals and blogs.