As SIP Sessions Evolve, So Must Session Border Controllers

By Aashu Virmani

What is a conversation? Is it an email, a 3-minute phone call or an IM session? In reality, those are just the elements of a conversation. Today, people don’t communicate in short, self-contained bursts like telegraphs; they engage in organic, ongoing dialogues that can take days or weeks to complete, often include voice, video and email at different stages along the way, and traverse different networks and devices. It’s this evolving nature of communications that will define the network requirements of tomorrow.

Our industry understands this evolution, and is changing to meet the new demand by migrating to IP-based networks and implementing new devices like session border controllers (SBCs). Yet our push toward the future is still entrenched in old thinking. We define SBC performance in terms of calls per second and concurrent calls supported even as we admit that our definition of what constitutes a call is just a small part of a much larger picture. 

This outmoded view of a SIP session resulted in the production of first-generation SBCs designed primarily for Voice over IP (VoIP) applications. But SBCs will clearly not live and die by voice alone. In order to be effective in the future, SBCs need to expand their notion of a SIP session to encompass the fast approaching reality where sessions live on for days, incorporate multiple kinds of media, and shift between different devices. In short, what’s needed is a second-generation SBC.

The Evolution of SIP Sessions

To move forward, we need to stop thinking of SIP sessions as a voice call. Voice is only one of several aspects that will define tomorrow’s SIP sessions, alongside constant connectedness, multiparty as well as point-to-point communications, variable media (Web, video, voice) and form-factor changes as the parties switch between different terminals/devices. For example, I may start watching on a video on my iPod and resume watching it later on my high-definition TV. It’s still the same session, but one with two very different characteristics in terms of bandwidth consumption and transcoding needs.

Viewed from this perspective, the scalability requirements for an SBC grow an order or two of magnitude higher. Suddenly, how many voice calls an SBC can handle becomes irrelevant when it takes only a dozen high-bandwidth video sessions to bring it down. First-generation SBC makers are beginning to realize this problem by adding features like media transcoding onto their first-generation boxes, but like the efforts of latter-day TDM switch makers who bolted IP functionality onto their legacy products, it’s probably too little too late. What’s required is a fundamental redesign of the SBC to handle this next generation of SIP communications.

The Second-Generation SBC

So how do we define what this next-generation SBC looks like? It really comes down to two distinct features: multidimensional scalability (that is, SBCs that can scale independently across three axes of general computing, network processing and media services) and what I refer to as the Networked Effect.

To illustrate the Networked Effect, let’s step outside of the telephony world for a moment and into the gaming world. Recently, when the Sony PlayStation network was hacked into and shut down for a few days, PlayStation owners were beside themselves because they’d become accustomed to playing on a network with other people. No one wanted to simply play against a computer anymore. This is an extension of Metcalfe’s Law, which states that the value of a network is directly related to the square of the number of people connected to that network. In other words, the power for a lot of things lies in the network itself. Facebook, Twitter and Skype are all examples of this.

The same principles apply to SBCs in a network. The trend for carriers and enterprises is to add more peers in more places. I know of one of our carrier customers, for example, that peers with over 600 other networks. If they were using first-generation SBCs (essentially point products) to manage these connections, they would have to solve the same problem 600 different times for each peering relationship. By using second-generation networked SBCs, however, the carrier has an end-to-end view of its entire network from a single perspective. Because each of their SBCs is connected to one another through a centralized routing and policy management system, the carrier can see exactly where they have excess capacity, where they don’t, which SIP trunks are getting more ingress traffic, etc., and manage their network accordingly.

This networked view is especially important when you consider Service Level Agreements (SLAs). A networked system of SBCs lets network operators track Quality of Service metrics like latency and jitter for each session on each SIP trunk, and allows them to re-route the session to the next lowest cost trunk if necessary to ensure SLA compliance. First-generation SBCs simply don’t support this kind of network-wide visibility, which needs to be architected into the solution design from the beginning to be effective. 

The second feature that distinguishes a second-generation SBC is multidimensional scalability. What this means simply is that SBCs must be designed to scale across several independent dimensions in order to effectively handle different kinds of traffic. As SIP sessions become more complex, the SBCs will need to adapt to handle this complexity, whether it’s IPv4-IPv6 interworking, encryption or video transcoding. More to the point, SBCs will need to handle shifting complexity — i.e., the SBC that handles 90 percent SIP-to-H.323 voice sessions today may need to handle 90 percent video-transcoded sessions tomorrow. In short, second-generation SBCs must support multi-party, multi-device, multimedia communications including: presence-based traffic that changes as users move between devices; conversations that are dormant for a day and then suddenly resume; changing form factors for different device displays (iPhone, iPad, laptop, TV); and sessions that use multiple codecs.

In the second-generation SBC, this multidimensional scalability becomes part of the DNA of the SBC. For example, media transcoding can’t be an afterthought, but should be seamlessly integrated into the SBC with embedded digital signal processors. Similarly, there should be dedicated co-processors to handle encryption, so as the need for secure SIP sessions arises, the overall session performance of the SBC doesn’t decline. And, as the number and types of peering arrangements grow in the network, the SBC should have broad support for a myriad of signaling protocols. These kinds of architectural considerations distinguish an SBC that’s prepared for complexity versus one that assumes simplicity.

Looking Ahead: What’s Next for SBCs?

A natural follow-on question to this discussion is what will the next, next-generation of SBCs look like? In my opinion, the next frontier is to leverage the networked intelligence of the second-generation SBC and create a closed feedback loop in the network where the measurements for the last session help determine the routing for the next. For example, if the last session on trunk group A has higher-than-normal jitter, the centralized policy and routing server can automatically route the next session to a different trunk group based on the peer/subscriber SLA. This kind of networked self-intelligence will be essential if today’s carriers and service providers hope to keep the conversation (and the cash) flowing smoothly into the future.

Aashu Virmani, senior director of marketing at Sonus Networks , is an almost 20-year telecom industry veteran with extensive product and corporate marketing experience.  Prior to Sonus, Virmani served as a director of core network strategy for Motorola and lead marketing for mobile video infrastructure startup Aylus Networks.