The flexibility of SIP has unique capabilities and limitations
When it comes to building interoperable unified communications architectures, “SIP is it” as far as standards go. Session Initiation Protocol (SIP) provides the “glue” that enables users to quickly initiate a voice, video, or web conference—all through a few clicks of a mouse.
Standardizing on SIP reduces integration complexity by creating a single communications protocol layer for all UC elements. Enterprise IT architects can simplify deployment and management by managing one suite of protocols rather than separate protocols for each type of UC application. IT managers also can take advantage of emerging SIP-based services for extranet connectivity to support communications and collaboration sessions across company or network boundaries.
But SIP’s strength as an open, flexible signaling protocol also brings interoperability challenges. The protocol’s developers envisioned it only as a signaling protocol—a way for one device to contact another, tell it what kind of session it wanted to establish (e.g., voice, video, etc.), establish the session, then tear the session down once the conversation was complete. SIP provides developers the flexibility to define the actual details of connectivity (e.g. media type, codecs, encryption schemes, priority, and so on).
This flexibility has led vendors to develop their own custom SIP-based implementation approaches—meaning compatibility challenges in multi-vendor environments. The Internet Engineering Taskforce (IETF) and the SIP Forum have worked, and are still working, to define many common SIP implementations (or primitives, as they’re called) to standardize common functions, such as call-waiting, three-way calling, message-waiting light indication, etc. But both groups still have work to do.
IT managers implementing SIP need to spend some time with their vendors to understand the capabilities and limitations of multi-vendor integration. They should look into what works and what doesn’t; mitigation strategies such as gateways or session border controllers; and the plans their vendors have to address interoperability issues. Finally, they need to work with their vendors to learn how to best integrate SIP-based applications into their existing environment, tying together the SIP and non-SIP worlds as seamlessly as possible.
IT architects should also follow efforts within the SIP Forum and IETF to define further interoperable primitives.
