Among the many hurdles VoIP users have encountered in the past ten years, no challenges have been as persistent as those associated with interoperating SIP across multiple networks, core network systems, and endpoints. I want to define this problem and to offer some tangible suggestions for creating a more resilient VoIP-based service.
With RFC 2543 and subsequently RFC 3261, the Internet Engineering Task Force issued a roadmap for manufacturers of SIP-enabled network gear and endpoint devices to construct their own SIP stacks around a common set of parameters. Widespread adoption/interpretation of these protocols has taken place in a loose manner-more like legal interpretation than precise mathematics. Each manufacturer of SIP endpoint devices-hardware or software-and each manufacturer of core network elements has constructed their own SIP stack. In a manner often compared to the evolution of HTTP for Web browsing and SMTP for coordination among email systems, SIP deployments usually encounter myriad challenges (some based on mismatched codec), though most are based on incompatibility between different SIP stacks, such as end point device registration problems, DTMF relay issues, extension to new features (SIP-B), backwards compatibility, and protection against erratic end-points, among others.
HTTP and SMTP took decades to evolve to the point where these protocols could be used across heterogeneous networks, so it should come as no surprise that these problems continue to exist in the SIP arena. However, because SIP has been commercialized so quickly and placed into multinetwork and multi-manufacturer revenue generating deployments, this has become a problem that requires a short-term solution.
We all experience SIP interoperation problems in our day-to-day use of the technology: when you dial into a conference bridge from your SIP phone and it appears not to hear your DTMF dialed digits; when your desktop phone loses dial tone; when you experience one-way audio. At the network core, these take a different form, but create the same predicament-interoperation failure, such as: problems when interconnecting to peering partners using multiple network components like soft switches, TDM Gateways, application servers, etc; problems when rolling out new products that require integrating additional network components; problems when performing upgrades/patches as part of regular maintenance cycles or as part of issue resolution.
With many more complex IP session based services to come, such as video, application sharing, wireless integration, gaming, etc., it is frustrating that interoperation increase churn rates, and undermine technology credibility.
The session-border controller is the network element that attempts to "normalize" the protocols, signaling stacks variants (like SIP), endpoint communication and session routing complexities - a daunting task and an ongoing process of interoperation testing as many devices and endpoints as possible. Ultimate success will mean plug and play VoIP/SIP interoperation or "turn-up" and intelligent routing of media both to minimize quality problems and to maximize profitability.
I see a lot of interest from carriers and service providers as they handle more VoIP endpoints to use an SBC. We have experienced it in the growth of our own SBC as a Managed Services product. I believe that as networks become more complex, the SBCs' value as points of security and policy enforcement will continue to increase.
Accordingly, I think you'll agree that it is wise to consider your current and future interoperation needs early on in your VoIP deployment.
-- Micah Singer - CEO, VoIP Logic