Perhaps, like me, your first experience with voice communication systems design and implementation involved two tin cans and a piece of string. That string was important, as it provided the connection between the transmitter (your mouth) and the receiver (your buddy’s ear).
Private Branch Exchange (PBX) switching systems operate in a somewhat similar fashion, but on a much grander scale. They too have a transmitter (at the originating end station), a receiver (at the terminating end station) and a connection between the two. If both end stations are connected to the same PBX, that connection is made internal to the switch. If the end stations are connected to different PBXs, a trunk circuit provided by a telecommunications carrier—such as a leased or T-1 line—makes the connection. If both of these switches are in an area served by a common telecommunications provider, then a single trunk, supplied by that provider, would be sufficient. If the voice network was traversing the North American continent, however, several providers would likely be involved—one local provider on each end, and one or more inter-exchange providers connecting those two.
For all of this to work, we need an interface standard, such as the T-1 line standard that specifies the electrical characteristics of the line. The T-1, for example, is a Time Division Multiplexed (TDM) channel that is typically presented to the customer’s premises on four wires—one pair for the transmit circuit, and one pair for the receive circuit. The T-1 operates at 1.544 Mbps and is divided into 24 timeslots, each with a capacity of 64 Kbps. (For those of you following along with your four banger calculator, the extra bandwidth—8 Kbps—is used for synchronization purposes, thus comprising the 24 x 64 Kbps + 8 Kbps or 1.544 Mbps channel capacity).
The two important points of this discussion are simple: You must have a connection between the two endpoints, and there must be a standard interface for that connection.
As we all know, TDM is 1970s-era technology, which is quickly being replaced by systems and networks based on the Session Initiation Protocol, or SIP. The standard for SIP was developed by the Internet Engineering Task Force (IETF), and published as RFC 3261 (see ftp://ftp.rfc-editor.org/in-notes/rfc3261.txt).
Simply publishing a standard, however, does not iron out all of the fine details that are required for successful implementations. Fortunately, an industry group comprising both equipment vendors and next generation carriers started the SIP Forum to address that challenge. The SIP Forum has a very straightforward mission: advancing the adoption of products and services that are based on the Session Initiation Protocol.
The organization goes about this in three ways: organizing interoperability and testing events, publishing technical documents that deal with issues—such as implementation—which fall outside of the IETF or other standards bodies’ scope, and building awareness regarding the benefits of SIP.
One of the most recent technical contributions from the SIP Forum is called SIPconnect, an interface specification to facilitate peering between SIP-enabled IP PBXs and VoIP service provider networks. This work is sponsored by a SIP Forum’s IP PBX and Service Provider Interoperability Task Group, a working group name which clearly describes the challenges before them.
The SIPconnect initiative and interface specification was launched in 2004 by Cbeyond Communications, a firm that claims to be the first service provider to build a pure VoIP local telephone company.
Collaborating with Cbeyond on this undertaking were Avaya, BroadSoft, CentrePoint Technologies, Cisco Systems, and Mitel. The interface specification provides a well-defined approach for direct IP peering, and provides some clear guidelines to the PBX vendors and service providers regarding how these peering relationships should be implemented. Such a consensus approach drives a faster adoption of peering, and should minimize the interoperability challenges that frequently accompany new technologies such as SIP trunking. IP PBX vendors gain a standard interface that addresses quality of service and network security concerns, while the service provider community can develop specific services that are tailored to IP PBX users.
Remember those tin cans and string? The SIPconnect interface standard defines how these two (rather dissimilar) devices interconnect and interact, so that overall, the end-to-end connection works for everyone’s benefit.
Further details on the SIP Forum are available at www.sipforum.org. Our next tutorial will continue our discussion of SIP Trunking, and dig into the details of the SIPconnect specification.
Copyright Acknowledgement: © 2007 DigiNet Corporation ®, All Rights Reserved
Author’s Biography
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.
