The VoIP Peering Puzzle�Part 19: The SIPconnect Reference Architecture
Our previous tutorial discussed the concepts of trunkshigh bandwidth connections between switchesand the work of the SIP Forum to further SIP trunking technology. In this tutorial, we will dive further into that work, and look at an interface specification called SIPconnect. But before we do, lets look at the concept of industry forums, and what these organizations are trying to accomplish.
In many cases, networking standards bodies, such as the International Telecommunications UnionTelecommunications Standardization Sector (ITU-T, see www.itu.int), the Institute of Electrical and Electronics Engineers (IEEE, see www.ieee.org), and the Internet Engineering Task Force (IETF, see www.ietf.org) develop and publish a standards that are designed to be implemented in many different jurisdictions.
For example, a device compliant with one of the IEEE LAN or MAN networking standards (the IEEE 802 series) may be installed in either North America or Europe. If that device requires commercial power, two different subsets of that standard might be requiredone that addressed implementations in North America (where we have 120 volt AC power), and another version aimed at implementations in Europe (where they have 220V AC power). But that would mean that the standards documents would get quite lengthy, take even longer for the committee to arrive at a consensus, and invariably leave out some implementation scenario that would not come to light until a hidden installation gotcha was discovered. Accordingly, standards frequently gloss over some of these details, and make the assumption that local implementation teams will figure it out.
Unfortunately, these intentional omissions can lead to confusion, as different implementers each do what they deem best, leaving the situation wide open for interoperability problems. These (understandable) frustrations led to the forum concept some years ago. Simply put, a Forum is a consortium of parties interested in a particular subject that band together to promote that technology, iron out implementation challenges, and act as a clearinghouse for information on that segment of the networking industry. The first of these that I can recall were the Frame Relay and ATM Forums from the 1990s, but suffice it to say, if there is a hot technology today, there is likely to be an industry forum to support and promote it.
Such is the case for the Session Initiation Protocol (SIP), and its SIP Forum. One of that groups most recent industry contributions is an interface specification called SIPconnect, published in July 2006. That work is the result of a joint effort between IP PBX vendors and service providers, to enable direct peering between a SIP-enabled service provider network and a SIP-enabled enterprise network.
The SIPconnect document:
- specifies a reference architecture
- defines a minimal set of ITU-T and IETF standards that must be supported
- provides guidance in the areas where the standards allow multiple implementation options
- and specifies a minimal set of capabilities that should be supported by the service provider and the enterprise network.
The SIPconnect interface specification is anchored by a reference architecture that outlines its required functional components (see figure). These elements, which may be implemented by combining several elements in the same box, include an IP PBX, which provides for call origination and termination services on the Enterprise side; a SIP Proxy Server, which performs SIP message routing and Transport Layer Security (TLS) at the enterprise and service provider network edges; a SIP Application Server within the service provider network which provides Public Switched Telephone Network (PSTN) call origination and termination services to enterprises; and a Signaling Gateway, which translates between SIP signaling and Signaling System 7 (SS7) messages. Note that the Real Time Protocol (RTP) is used for connections that extend from the enterprise to the PSTN.
Implementing the SIPconnect interface should benefit both enterprises and service providers, as it:
- provides specific instructions for peering relationships
- eliminates the need for VoIP gateways (because of the direct enterprise-to-service provider connection), thus reducing data network expenses
- enables end user-specific application information to pass from the IP PBX to the network without alteration
- defines specific transport issues, including Quality of Service (QoS), echo cancellation, the codec to be supported, and so on
- and requires Transport Layer Security, thus providing a more secure peering connection.
Further details on the SIPconnect specification are available at www.sipforum.org/sipconnect/. Our next tutorial will examine some of the key technical details included in this specification.
Copyright Acknowledgement: © 2007 DigiNet Corporation ®, All Rights Reserved
Mark A. Miller, P.E. is President of DigiNet Corporation®, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.