Session Border Controller: Competing Devices, Language Barriers and SIP Normalization

By Braden Becker
Copy Editor

Advancements in communication have obviously been extraordinary, but dissect why these things woo us, and it’s not just the existence of a new computer or mobile device. One might say Apple (News - Alert) started the smartphone arms race, ushering in a breadth of subsequent products that, let’s face it, do more or less the same thing – just slightly differently. Phone (News - Alert)-A has Chat Feature-B, Phone-C has Multiplayer Game-D, and so on. And they compete, constantly, to see who can do it better.

Yet everyone texts, calls, plays with, and sees each other, regardless of what’s in their pockets or on their desks. It’s called Session Internet Protocol (SIP), and it’s happening all the time. 

SIP is a signaling practice that engages the barriers distinguishing every operating system from one another, and establishes a common “language” in which every platform communicates – much like dialectic differences in English between the U.S. and Great Britain. Not every message will make sense; it’s SIP’s job to bridge these gaps.

The problem, confronted in 1999, according to Sonus Networks, inspired a set of guidelines issued by the Internet Engineering Task Force (IETF) to which all SIP processes comply. Sonus Networks (News - Alert) has since accompanied a number of firms around the world in pursuing scenarios to render standards for the way in which devices connect and process “foreign” information.

The process now employs those standards, so a single modern SIP is the unconditional common denominator among the hundreds of devices on shelves today. Practiced by Session Border Controller (SBC) vendors, this “SIP normalization” detects and translates differences in data strings so users experience messages in the format they and their devices are familiar with.

“Service Provider X’s core network,” the source suggests, “might display a SIP Uniform Resource Identifier (e.g., sip:jane@company.com) using one format, Service Provider Y’s core network another (e.g., sip:jdoe@home.company.com), and so SIP normalization is required to go into the packet headers and alter the SIP URI naming convention both for the [incoming] and [outgoing] SIP packets so that they match the way Provider X and Y are used to seeing them.”

 More “holistic” approaches to SIP normalization include the use of media gateways and routing engines, which view systems’ language barriers from a less particular vantage point and operate more intuitively.

The options reflect Sonus’ philosophy that network operators should seek solutions that support both static and dynamic SIP normalization. While static SIP focuses on modifications in the SIP header, dynamic SIP is concerned with rules that influence data within the communication process – telephone digits, call parameters and processes that aren’t as unchanging as more basic displays.

SIP will continue to evolve with portals for communication, but our approach to these problems are always the same. Paying attention to third-party applications can only help IT professionals better shape how SIP navigates, but solutions that view issues of compatibility more collectively are the best way to keep pace with the next set of devices to toe the line.      

Edited by Juliana Kenny