After Oracle announced the acquisition of Acme Packet, a lot of people asked me about the role Acme Packet plays in the network. I started piecing together bits of information to understand the tumultuous history of session border controllers that led to the acquisition. The result is this article that hopefully explains the value of Session Border Controllers (SBCs) in the network and Acme Packet’s role in this market segment.
SBC Origin
SBCs have been around since the early days of Voice over Internet Protocol (VoIP) and have always been in the center of heated debates in the industry. The VoIP purists believed that the VoIP client should communicate directly with the VoIP proxy, so that the session can be established end-to-end, that is, between the two communication parties (clients). The model first broke when telecom-style soft switches started terminating sessions to clients and messing with the session parameters; they became so-called Back to Back User Agents (B2BUA). The benefit of B2BUAs is that they can implement telephony style features like forwarding, transfer, conference, and the “holy grail” of enterprise telephony - multiple line appearance.
Once the end-to-end session was broken however, folks decided that it can be broken several times, and put another type of session breakers – session border controllers – between VoIP clients and soft switches. VoIP purists were enraged but, as time passed, the practicality of SBCs won over the argument for clean architecture. At the end of the day, SBCs solved the most difficult problem for VoIP, firewall/NAT traversal, and the choice was really between successful call based on “bad” architecture vs. failed call following the “good” VoIP blueprint.
Over the years, I have attended a lot of IETF meetings and the issue of bad SBCs messing up the clean VoIP architecture was frequently discussed. Since IETF created SIP as a signaling standard for VoIP, the discussions there were always about SIP clients, SIP SBCs, and SIP servers. In the parallel universe of video conferencing, the ITU standard H.323 was in use long before SIP emerged. Firewall traversal was as much an issue in the H.323 world as it was in SIP; therefore, H.323 SBCs started appearing in product portfolios, mostly based on the ITU-T H.460 standard.
SBC Functionality
The original firewall traversal function in SBCs was later enhanced with other connectivity services such as manipulation of SIP messages (for example to hide the senders address), IPv4 to IPv6 interworking (for connecting VoIP clients on IPv4 networks with VoIP clients in IPv6 networks), and SIP - H.323 translation (for example, to connect H.323 video systems with SIP video clients). Additional security services were introduced to protect the network from Denial-of-Service (DoS) and other attacks and from malformed IP packets.
More powerful SBCs could also encrypt/decrypt signaling (via TLS and IPSec) and media (SRTP). SBCs gradually evolved to enforce Quality of Service (QoS) policies (for example, to limit bandwidth or limit number of calls), perform regulatory compliance functions (emergency calls prioritization, lawful interception, etc.)
Many of the new generation of SBCs also provide built-in digital signal processors (DSPs) to provide media services, such as media transcoding. The bottom line is that SBCs started as firewall traversal tools and ended up as complex elements of the VoIP network doing pretty much everything but call control (that was prerogative of the soft switch/application server).
SBC Market Dynamic
Acme Packet was at the forefront of the SBC market, some may say they defined the market segment. In the early 2000s, service providers started offering hosted VoIP services and needed reliable and scalable SBCs for their new networks. Since tier 1 service providers usually buy from a small group of vetted vendors, Acme Packet built partnerships with Ericsson and others, and became very successful selling through such channels to service providers. Two other SBC vendors - Kagoor Networks and Jasomi Networks – were less successful. I remember meeting with these companies in the early 2000. At the time I was leading the Product Management team for Devices at Siemens, and our SIP phones always went through some kind of SBCs before connecting to SIP servers / soft switches; we therefore tested interoperability. Around 2005, the SBC market became very hot and big players started buying SBC startups. Juniper Networks acquired Kagoor in 2005. Ditech Communications acquired Jasomi in 2005 (Nuance Communications acquired Ditech in 2012). Nextone was swallowed by Nextpoint which Genband acquired in 2008. AudioCodes acquired Netrake in 2006.
Big VOIP vendors took various approaches to adding SBC functionality to their portfolios. Cisco developed its own Cisco Unified Border Element (CUBE) while Avaya acquired Sipera in 2011. In the service provider market, BroadSoft relied on Acme Packet (in fact that is how I first came across Acme Packet years ago) while others like 8x8 developed their own SBC technology.
The SBC market attracted competition. In 2010, Sonus Networks newly hired CEO Ray Dolan set the goal to make Sonus “strong #2 in the SBC space”. Sonus quickly transitioned from making soft switches to making high-end SBCs but needed medium and small sized models to complete its portfolio. In August 2012, Sonus acquired Network Equipment Technologies (NET) of Fremont, CA and – with now complete line of SBC products – is positioning itself to directly compete with Acme Packet in both the enterprise and SP markets. Sansay, the #3 in SBC market, emerged from the former Nuera Communications team in San Diego in 2002. At ITexpo 2013, Sansay won the “Best Service Provider Solution” award for their transcoding technology, integrated into the SBC product.
Through the years, I got to know two other players in the SBC market. Edgewater Networks focuses on SIP SBCs for service providers and H.323 SBCs for Polycom (Video Border Proxy = VBP portfolio), although recent version of the Polycom branded product support SIP as well. Ingate Systems focuses on SIP trunking and hosts its SIP Trunking Summit / Workshop at every IT Expo event; this event evolved into the SIP Trunking - UC Seminars. I had the pleasure to present at several Ingate events, and can say that they are very well-organized, well-attended, and very educational.
SBC’ Role in the Enterprise
While many speculate about Oracle using Acme Packet to build a stronger position in the service provider market, I see a lot of applications for SBCs in the enterprise environment.
Enterprises increasingly use services from the cloud, including cloud-based voice/video services, and need tools to control the traffic to and from the cloud. SBCs provide this session control functionality. In the new architecture, enterprise users do not access the cloud services directly but through the enterprise SBC which provides security, accounting, etc. services and, if necessary, protocol translation and media transcoding. The SBC therefore becomes the official entrance for real-time communication to the enterprise.
In addition, SBCs are critical for enterprise VoIP deployments that require connections among existing IP-PBX systems, new deployments (such as Microsoft Lync), and other enterprise applications (such as Contact Centers). When I think about it, SBCs with H.323 support can also connect the installed base of H.323 video conferencing equipment in the enterprise. In this scenario, the SBC becomes the universal connector, the glue that connects all parts of the currently disparate enterprise communication infrastructure.
