VoIP Industry Newsletter: The challenges of SIP Interoperation

Apr 2009

A Connectivity Revolution

The number of new SIP-based systems in the market is rapidly growing. Early adopters of SIP and VoIP in general have touted lower costs and trotted out dozens of ROI models, while traditional telephony manufacturers are entering the market with IP adaptations to their traditional PBX products.

Emerging SIP products must be highly flexible and customizable, and are rigorously tested for multi-vendor interoperability. By using the existing IP infrastructure and blending with the current telephony infrastructure, SIP provides a first step toward making this a reality.

SIP represents the capability to reach someone regardless of location or device, and has many of the characteristics of HTTP (looks and acts like a URL) SIP resides at the application layer of the network and establishes, modifies, and terminates multimedia sessions between intelligent devices. Traditionally, data networks have been unintelligent, but with very smart endpoints and devices. In contrast, telephone networks are inherently very smart, but with unintelligent endpoints (telephones).

As the number of SIP connections to a carrier’s network increases, so does the need for protocol normalization. Each new connection added to a network may include new softswitches, gateways, application servers, or direct user endpoints. Many enterprises are still in the process of deploying SIP and today only have support for H.323 based IP-PBXs exclusively. For service providers who want to deploy next generation networks and keep their core networks to SIP, this creates a challenge to offer solutions to such enterprises.

To address this incompatibility, SBC’s include a protocol interworking function (IWF) to support both H.323 to SIP translations and normalization between various vendor SIP implementations. This reduces a carrier’s need for expensive and time consuming multi-vendor interoperability exercises and allows providers to successfully address enterprises either in transition or of mixed environments.

There are other types of incompatibilities to consider as well. In access deployments such as VoBB, a large number of subscribers register by sending SIP messages to the core application server (or registrar). These access devices (user phones) are generally behind firewalls and, to keep the pinhole open, send re-registration messages at very frequent intervals, say every 60-90 sec instead of every 3600 sec as typically required. This increases the reregistration traffic and imposes a requirement on application servers in the core to handle such high registration traffic. Registration messages, being compute intensive, can impact the performance of application servers. To address this class of issues, SBCs provide support for registration throttling, i.e. when such re-registration messages are received by the SBC (deployed in front of an application server), it locally responds to those registrations and does not forward every registration received to the upstream application server.

Finally, SIP extends the intelligence of a data network to the end-user on the edge, while allowing the less intelligent core to forward communication requests without much effort. This makes the data network run more efficiently and effectively by putting intelligence where it is needed most. But operators must be careful. Because of the potential number of possible incompatibilities, proven and field tested SBC solutions, with vast interworking and certification through external industry organizations, can best protect networks from potentially harmful, proprietary SIP extensions or poorly implemented protocol stacks and vendor incompatibilities.

- Natasha Tamaskar, Genband
  Next>>