Enterprise Session Border Controller Interoperability
I've had a fascination with linguistics throughout my entire academic life. Learning new languages is more than memorizing new vocabularies – it also includes learning new grammar and phraseologies. Specifically, the history and evolution of languages pique my interest, such as the adoption of new words and phrases within a language, as well as their deprecation, produce a very curious lens for viewing a society. My interest was likely instilled in me by my high school Greek and etymology teacher, Professor Krumpe. He could spend an entire lecture lamenting the passing of words like "wither" and "thither" from conversational English.
Unsurprisingly, it is easy to draw an analogy between the evolution of spoken language and the evolution of computer protocols like SIP, humans created both of them, after all. Differences in SIP dialects can be traced to the different "tribes" that implemented them. For example, conveying telephone key presses from a caller to a callee can be done in at least four different ways, and the "Cisco dialect" differs from the "Avaya dialect" in this regard. It's the story of the Tower of Babel all over again – lest SIP get too consistent and powerful, let's scatter it amid all of the implementers and deliberately make it confused!
The problems introduced by differing implementations or dialects helped forge the early market for session border controllers (SBCs). For ten years and counting, service providers have been deploying SBCs at the edge of their networks to normalize the SIP signaling they receive from external sources, among other important functions. When acting as a gateway to the PSTN, the scope of the SIP semantics that their infrastructure needs to support is relatively small. Since the PSTN doesn't traditionally support things such as video calling or presence updates, these signaled events are discarded or silently ignored – a sort of "lossy" translation, to borrow a term from audio encoding. These service provider SBCs churn away, crunching key press events from one format to another, re-writing call transfer events from one format to another, and other basic operations. For more than 10 years, the SBCs at the edge of service provider networks have been doing yeoman's work. The interworking aspects of their SBCs need to do little more than recognize the events that the PSTN supports.
However, the translation function that interworks a PBX's dialect of SIP when sending or receiving calls from the PSTN is very different than the translation functions required in an all-IP environment. The SIP trunking market emerged when enterprises began using their PBX to support native VoIP interfaces to connect to VoIP-capable service providers. A case for SIP trunking was also built as enterprises started to "federate" – create collectives where unified communications sessions pass from enterprise to enterprise without passing through the PSTN on their way. Federating an enterprise that owns unified communications (UC) equipment from Vendor A with another enterprise that owns UC equipment from Vendor B presents a very different problem with respect to interworking. No longer is the translation from Vendor A's dialect of SIP into "PSTN-ese," and back from "PSTN-ese" into Vendor B's dialect. The lossiness associated with these translations can and will affect the intent of the signaling.
An example I like to use to illustrate my "double translation" or lossy problem with respect to relaying signaling to and from the PSTN, is to use an online translation service to take a paragraph of text and convert it to another language, then take those results and convert it back to English. Here is one such example, using this very paragraph.
"In the example you want to use to describe the problem or lossy translation "double" In my opinion for the relay signaling from the PSTN and I are taking a paragraph of text, you can use an online translation service to convert to another language in, I will convert it back to English and take the consequences of them. Here is one such example, using this very paragraph."
In more drastic cases, the intent of the language is nigh indecipherable.
Enter the enterprise SBC (E-SBC). Built on the same basic technology and principles as a service provider SBC, an E-SBC's role in interworking different dialects of SIP is arguably much more involved. Unlike service provider SBCs, where one side of the translation is usually "fixed" to normalize traffic toward PSTN gateways, E-SBCs have dynamic interworking shoes to fill – where the same E-SBC may be called upon to mediate between Vendor A, Vendor B, and Vendor C's dialects all within the scope of a single call. In order to enable features, such as video calling and presence between vendor implementations, it needs to understand the semantics of the exchanges – it cannot blithely ignore or throw away the types of events that the PSTN doesn't support. After all, these UC systems are federating for a reason!
Flexibility is key, therefore, when deploying into heterogeneous VoIP environments. Acme Packet's approach toward solving inter-vendor incompatibilities is twofold:
1) Affect the conversation between the caller and callee as little as possible to avoid the "double translation" problem.
2) Create reusable configuration or code "plug-ins" that allow our customers to draw upon our experience with previous interactions.
While the first approach is fascinating, and probably worthy of a future blog post in and of itself, it is the second aspect that I will focus on here: reusable configuration and/or code. It's probably no surprise to anyone reading this post that Acme Packet has a powerful tool for solving interworking problems, colloquially referred to as "Header Manipulation Rules” (HMR), which represents a metalanguage – a symbolic description of a language's syntax, and for its translation. Once an E-SBC's administrator becomes "fluent" in HMR, they can solve many problems on their own, with no software changes required on any equipment in the network, but we do not want our customers to have to re-invent the wheel with each new deployment.
Our continued efforts into assisting our partners and customers to be fluent in apply HMR led us to develop technical seminars, cookbook-style documentation with sample configurations, and a thriving community portal where new questions are asked and answered daily. With the ability to import and export HMR configuration bundles, our software facilitates the exchange of configuration between E-SBCs.
Whether your E-SBC is connecting to a SIP service provider, federated partners, or simply your own datacenter, there's a good chance that the PBX and UC equipment you're navigating between has been navigated somewhere, by someone already. Designing clean, scalable architectures is made simpler with E-SBCs performing interworking functions using proven plug-in modules. Use the resources at your disposal, and by all means contribute your experiences back into the community too!
Biography: Patrick brings more than 15 years of communications experience to his technologist role at Acme Packet. At Acme Packet, Patrick helped build and oversee a global systems engineering organization before transitioning to product design and engineering team leadership. As the vice president of technology in the office of the CTO, he currently concentrates on enterprise session management and unified communications architectures.
Visit Acme Packet's Community
Acme Packet's Community was designed to enable collaboration among Acme Packet customers, partners, and employees – facilitating peer-to-peer support for answering how-to questions and validating configuration concepts.