IP PBXs are starting to dominate the enterprise equipment market. But TDM trunking remains the norm, unnecessarily limiting the advantages business customers can realize from IP voice in both capabilities and cost.
The answer to this dilemma is still relatively little used. End-to-end IP voice "peering" between those customers and service providers is urgently needed to release the capabilities of increasingly ubiquitous VoIP equipment from the constraints of TDM trunking.
IP PBX sales in North America, estimated at over $3 billion (including IP-enabled lines) by analyst firm Gartner, now well exceed those of traditional TDM-based PBXs. Research firm Dell' Oro estimates US IP PBX annual sales are tripling in value from 2005 to 2010. A majority of installed PBXs are now at least IP-enabled.
Today's VoIP communications systems offer a wealth of advanced features with the ability to readily add new ones as demands evolve. Service providers have meanwhile taken big steps to transform their networks with VoIP technology to deploy new services while heightening efficiency.
But business customers, by still using trunking gateways for their carrier links, are held back by traditional TDM technology. Employing PRI or analog connections to provider networks limits available features to the "lowest common denominator" those connections will support. Connection quality is meanwhile downgraded when converting traffic back and forth between IP and TDM.
The SIP Forum--an IP communications industry association--is trying to address these problems with SIPconnect, a technical recommendation designed to facilitate direct "peering" between SIP-enabled networks of service providers and enterprise-based IP PBXs.
While manufacturers and service providers have largely settled on Session Initiation Protocol (SIP) as the way to realize full IP connectivity, the protocol by itself does not resolve the dilemma.
Under SIP, there are often many ways to achieve the same interconnection tasks, complicating interoperability. VOIP network interconnection involves issues beyond signaling, such as security, for example, which must be addressed to fully define a predictable interface model, and this requires building further on SIP.
SIPconnect is a recommended set of interoperability guidelines that the SIP Forum is driving to establish as industry norms; it is not a new protocol. It. The SIPconnect Technical Recommendation defines a set of rules for seamless interconnection between SIP-enabled IP PBXs and SIP-enabled service providers, specifying required VoIP protocols and features to be supported, a reference architecture (see Figure 1, below) and implementation rules when protocols leave multiple options.
SIPconnect was conceived by Cbeyond in 2005 with the support of technology vendors. It was later turned over to the SIP Forum--the industry organization focused specifically on adoption of SIP-based products and services--for wider review and development, and an updated, improved version resulted.
In January, 2008, the SIP Forum formally ratified version 1.0 of the SIPconnect Technical Recommendation, validating that the proposal had survived credible and lengthy peer review, is stable and well-understood, and is believed to have resolved known design issues. To download the ratified SIPconnect Technical Recommendation Version 1.0, click here. At the same time, the SIP Forum Board of Directors announced formation of the SIPconnect v.1.1 Task Group to further enhance and update the recommendation. For an overview of this work in progress, please click here.
The reference diagram (Figure 1) outlines common functional elements required to support SIPconnect. SIPconnect treats the elements in the diagram as separate physical components for illustration only, as equipment manufacturers may combine functions in single physical devices.
For example, one vendor may integrate the SIP Proxy Server function with the IP PBX function, while another may integrate these two functions with the Firewall function as well. Both, as well as other combinations, are conformant as long as they adhere to the specific rules governing each integrated function.