When was the last time a product announcement spotlighted and bold-faced its hardware aspect? Sonus's announcement of two new SBC (session border controller) models today does just that, and the rationale for this emphasis has a lot to say about how network architectures for UC may evolve in the coming years.
Sonus released the new SBC 5210 for service providers and 5110 for large enterprises, and announced that the major innovation is a change in hardware configuration; the new models increase DSP capacity and can accept up to 4 DSP cards, to make the units field-upgradeable.
Big deal, right? Actually, it kinda is, because of the role that DSPs play in SBCs.
David Tipping, VP and GM of Sonus's SBC business unit, explained that customers were asking for more power and flexibility in DSPs because DSPs are critical in helping SBCs handle transcoding and other key media processing tasks. The focus on DSPs suggests:
1. That in a future where there will still be a need for lots of transcoding among unlike endpoints, the SBC will be positioned to take on this role, and handle it in a more comprehensive way.
2. That there will still be centralized choke points where media traffic flows through a single network device (or device type). This is in contrast to the original SIP vision--and many people's vision of WebRTC--which was that in IP communications, endpoints would communicate through central servers to set up their sessions, but would then send media back and forth directly, without any middlebox involved.
This is something that Sorell Slaymaker talked about in a recent piece he wrote for No Jitter on future architectures; Sorell wrote that, "With modern collaboration, conferencing, and third-party communication systems, more than 90% of an enterprise's real time traffic ends up needing to be handled by some communications elements between the two peer endpoints. 'Peer to peer' communications is actually a rarity in enterprise communications, and is likely to continue that way."
With its new SBC release, Sonus appears to be ratifying that idea.
There's a debate under way in the infrastructure world about the future role of the SBC. By packing DSPs into its box, Sonus is coming down hard on the side of the SBC moving toward center stage in the communications networks of the future, where a critical factor is how communications are handled as they cross multiple network borders--from enterprise to carrier and carrier to carrier, along the way requiring multiple types of adaptation so that whatever it is you have can be understood by whatever it is that I have.
Though the Sonus announcement led with the hardware story, the company also announced 100 new feature enhancements in software, including:
* Comprehensive media interworking; call recording for contact center, regulatory compliance, and security applications; expanded transcoding support for G722.1 for Polycom high definition voice; and DTMF and fax enhancements
* Bandwidth-based call admission control (CAC) to assure voice quality and simplify management
* Support for Proxy Call Session Control Function (P-CSCF) to enable the SBC 5000 Series to act as an access device bridging endpoints into the IP Multimedia Subsystem (IMS) core
* Increased security and management capabilities, such as improved call detail record capabilities (CDR) and expanded alarms and notifications.
Software is also an important part of the discussion here, since it really defines what the SBC should be doing, versus what tasks belong elsewhere in the network. At our Enterprise Connect SIP Trunking Tour stop last week in Las Vegas, this was described as the division between Session Management and Session Control. Though these haven't been formally defined nor detailed positions staked out, the general division was between:
* Tasks that already reside in SBCs (Session Control), including operations like call admission control (CAC), acting on sessions that have already been set up.
* Session Management tasks that now reside in the PBX. These are tasks that determine how sessions will be set up; the example used was dial plan, which many enterprises would like to centralize across a communications infrastructure that generally comprises many vendor products and types of implementation for these functions.
In our panel discussions, the Sonus and Cisco representatives broke down along predictable lines on this: Cisco, which does a booming business in IP-PBXs that perform Session Management, insists that functions like centralized dial plan don't belong in the SBC, while Sonus suggests it does or at least could--though Sonus's David Sauerhaft was careful to say that he doesn't see the SBC supplanting the PBX within the enterprise.
It's not surprising that Sonus or any other SBC maker wouldn't want anything to do with the letters P-B-X, but what else do you call a privately-owned network element that centralizes the setup and teardown of all communications sessions, and through which all media must flow?
By stressing the continued separation of the SBC from many of the core PBX functions, Cisco is betting that either enterprises will be willing to go all-Cisco, or will be willing to live with a multi-vendor call control architecture with little centralized control over the diverse PBXs. In other words, they're betting that some version of the status quo will continue to be good enough for most enterprises. It's not a bad bet; inertia is powerful and transitions take a long time.
Sonus and the other SBC-focused companies are betting that the enterprise network of the future will need more--a tighter connection with public networks, the ability to "normalize" signaling protocols and dial plans across legacy PBX systems, and the ability to handle and increasingly heavy load of transcoding, recording, and other real-time media processing.
At this point, we don't know which vision will prevail--but it's likely to be a debate we'll hear more of.
Follow Eric Krapf and No Jitter on Twitter and Google+!
@nojitter
Eric Krapf on Google+
