Transcript for UCStrategies Experts Discuss SBCs

Hi, everyone, this is Russell Bennett from UCStrategies. Today I’m hosting a podcast on the session border control market, which is under fairly significant transformation. This is a very large and complex topic and we can probably talk for hours on this, each of us. However, the piece of news that’s brought this to the forefront this week is the announcement that Avaya is acquiring Sipera, which is a security and SBC company. So what this actually means is that now all the leaders of the Gartner Magic Quadrant for UC have their own SBC technology: Microsoft, Cisco, Siemens, Avaya and Alcatel-Lucent. And some of the kind of secondary and tertiary players also have a security element.

So clearly, this is an admission that session border control or network edge security is critical for UC, and this raises just a host of points that we’re going to try and cover today. I’d like to call first on Marty Parker.

Thanks, Russell. I first want to express that it’s just disappointing that we need session border controllers at all. The internet really is a disappointingly wild place from the view of security and behavior, so having said that bit of indignation, I’ll just go on to say therefore they are necessary. Session border controllers are certainly necessary for the interface of any session, and usually that applies to a SIP-type session, to the internet. Now in our telephony world, not so much in the UC world, Unified Communication, but over in the telephony world they’re primarily applied as the interface for session initiation protocol trunks, or SIP trunks. And again, it’s a puzzle that the carriers, who have been trusted to provide secure T1 / B1 transmission for so many years really are no longer trusted by most enterprises to provide the sole interface to the network for SIP trunking. So most enterprises are finding, and recommendations from their IP telephony providers, that they should install a session border controller. It’s seen really as part of the network infrastructure.  The application, the IP PBX is delivering voice and media and signaling into the network, in through switches, in through routers, and then if it wants to go out through the edge it will use a session border controller for that interface – products like the Cisco Unified Border Element, the Cube and products like that are well known. As Russell said, everybody in the Gartner Magic Quadrant for UC has them. Also, the leaders in the corporate telephony magic quadrant all have it.

Since we have them, the big question is how is that market going to evolve? And clearly what’s happening is that SBC functionality, the denial of service protections, the man-in-the-middle protections, the hidden protocol protections, all of those sorts of things are being done by very fast software. And they will over time be built into other products, whether it’s routers or it’s PBX gateway products, we’re going to see those built in. And then over time we’ll see another shift because in the end a SIP session or a connection to the internet should be part of, and most enterprises want it to be part of their integrated threat management. Because every enterprise of any size has some version of a threat management program for everything I’ve said about real time communications as well as all the non-real time communications. It’s likely that those providers, Radware would be an example, who has already added SBC functionality into their threat management portfolio, will suggest to the IT infrastructure manager that there’s no need for a separate product, “You can use our integrated threat management solution to manage this.”

It’s going to be a very rapidly developing world, I think, because software has that tendency. Certainly product releases will be the gating pace, but you can see the end from the beginning, that over time we will see SBC functionality built into integrated threat management tools and built into network infrastructure; not seen as a separate functionality of IP telephony. So I’ll pass it back to you, Russell, thanks.