Initially nicknamed "Sexy IP," SIP stands for Session Initiation Protocol--but that isn't important. In English, SIP is an IP phone circuit. As with real circuits, we tend to call them "trunks" or "lines" depending on whether they service a system or a phone. The telecom world utilizes surprisingly few interconnection standards--analog, T1, and PRI being the primary ones. When VoIP emerged in the late 90's, there was a desire and goal to create a new standard for interoperability: SIP (ta-da).

Initially, SIP was promised to be the end-all solution for VoIP; circuits and phones and everything in between. It is growing significantly, but hasn't quite lived up to its promise. Most PBX brands now support SIP to some level, but proprietary phones are still predominant. Attitudes are slowly changing and it appears SIP has a reasonably bright future--but it took more than a protocol. SIP's success requires a bit of a mind shift--at least if you are coming from the PBX world. SIP is an end-to-end (peer-to-peer) protocol. This means two extensions use the PBX for call setup, but then bypass the phone system for the actual conversation. Conceptually this makes sense, but it is a radical concept to telecom traditionalists. It requires distributing call processing intelligence to the endpoints. That's the concept, but SIP does it with a new and relatively limited (signaling) vocabulary.

SIP trunks to the PBX are moving to the mainstream, though vendors and carriers are taking a cautious, measured approach. While vendors and carriers increasingly support SIP, the list of approved partnerships is pretty short. For example, Microsoft OCS severs can directly connect to only three approved SIP carriers (Sprint, Interoute, and Global Crossing). Coming from an analog, T1, or PRI perspective- it is odd to be restricted to "supported" carrier/equipment matches. This is a result of the SIP standard being inexact on various options. The old joke about SIP being an "open" standard, is that it is "open to interpretation". Something as simple as the number of active calls per trunk is unspecified. SIP introduces new variables, complicating interoperability, QoS, and security. Thus the vendors and carriers agree that implementations need to be restricted to tested and approved matches.

SIP trunks are attractive for several reasons, but primarily cost. The PBX equipment is less expensive since SIP trunks don't require dedicated TDM ports. SIP trunks also tend to run about 40-60% less than TDM circuits, especially around long distance charges. Another benefit is SIP support of wideband audio that many IP phones support. SIP trunks are often usage based, so they can be financially attractive in bursty or overflow situations (pay for what is used instead of paying for idle capacity). SIP trunks (even just one) also support DID functionality.

SIP trunks are well on their way to becoming the new T1 despite interoperability issues. Most likely a standard configuration will emerge as the model - Cbeyond's (CLEC) SIPConnect-based service now supports 24 brands and may emerge as a reference model. (SIPConnect is the SIP Forum's specification for PBX-to-carrier interoperability.) Microsoft OCS is driving SIP trunk interest and awareness as well. SIP trunks, distance unaware, may contribute to cloud solutions by either distributing systems among multiple locations, or consolidating equipment into a single location with distributed endpoints. Any type of T1 or Analog connection today (inter and intra site) could be displaced by SIP trunks over a packet network tomorrow.

Despite the current interoperability challenges, SIP trunking is actually the easier part, as carriers don't require too sophisticated signaling, compared with multi-vendor PBX-to-PBX signaling. The more robust QSIG for inter-PBX trunking never became widely supported.

And phone signaling is another whole different story. Phone signaling is much more complex because of the number of features users expect. On proprietary PBX phones, advanced features are activated with coordinated buttons and displays--the two areas where SIP specifications are really lacking.

SIP based phones don't support the feature functionality found on proprietary phones, but that is not to say SIP based phone systems have fewer features. It just means the features are not implemented in the same way. Consider call park; a proprietary phone system may have a "Park" button on the phone. Press it, and the display shows the orbit number. On a SIP phone, call park may be implemented by transferring the call to a "Park" extension. Then an IVR will "say" the orbit number. Call park is not specified in the SIP standard. Hold is specified, but there are multiple ways to do it.

 LOGIN | CREATE ACCOUNT