As the Session Initiation Protocol evolves, will it escape excessive complexity and live up to its promise?
RELATED CONTENT:
BLOGS:
Alan Percy: SIP Trunking: How Do You Get the Savings Without the Risk?
Sorell Slaymaker: VOIP/SIP Trunk Savings
Sorell Slaymaker: A SIP Gateway for Digital Handsets
Sorell Slaymaker: Evolution vs. Revolution in VoIP/SIP
Matt Brunk: SIP Trunking: Diverse Routing
VOICE CON WEBINARS:
Taking Advantage of SIP Trunking (October 14): On-demand replay
Ensuring High-Quality SIP Trunking: On-demand replay
Overcoming Technical Obstacles to SIP Trunking: On-demand replay
Lessons Learned: Real-World SIP Trunking Deployment: On-demand replay
VOICECON SF PREVIEW:
Fundamentals of SIP (David Bryan, Cogent Force): View SlideCast
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.
In the carrier space, cost benefits drive SIP's adoption. The opportunity is similar with phones in traditional PBX environments, but adoption is much slower. PBX vendors such as Cisco, Avaya, Mitel and now ShoreTel all support SIP endpoints; but with limited functionality. Third party SIP phones are fiercely competitive, with more than 10 models available for less than $100 (compare that to $619 list for the standalone phone for Microsoft's OCS). One might think SIP endpoints are an obvious answer, but these systems create too much feature disparity. Some of the proprietary systems limit SIP devices to single line devices with few features.
PBX phones have been proprietary since the conversion from analog to digital in the 80s. This creates an interesting predicament for the traditional manufacturers. On one hand, proprietary phones offer their customers more features and deeper support. The vendors also enjoy product differentiation, along with increased revenue and profits (phones typically represent 40%-60% of the total installed system price). On the other hand, no vendor can offer every type of end device; historically the vendors solved this with analog devices. Analog devices require ports and dedicated cable infrastructure, so SIP is becoming the new analog. Some vendors position SIP phones as specialty devices such as large conference room equipment, door phones, soft phones, and wireless solutions. But not everyone is happy with SIP being treated as the lowest common denominator.
The newer PBX players are largely SIP based. Users of SIP based phone systems including Asterisk, sipXecs (and branded solutions based on these technologies), and many of the hosted solutions overcome SIPs limitations with (non-SIP) user portals. Ironically, these portals with their larger desktop screens and a full keyboard frequently result in easier access to features. Transferring a call directly to someone's voice mail can be a simple drag and drop instead of an esoteric key combination. The traditional players also offer user portals, but typically as an option.
In a bizarre twist of fate; the SIP savvy Asterisk platform offers a proprietary connection to Skype (Skype for Asterisk) and the proprietary PBXs (ShoreTel and Cisco so far) use Skype's SIP solution. Skype for Asterisk tightly integrates Skype features including buddy-lists, screen names, and presence capabilities to the PBX. Skype for SIP is effectively a SIP trunk from Skype with no integration to the millions of Skype clients around the world. SIP simply cannot deliver comparable functionality.
Most of the proprietary systems use H.323 with customized signaling. ShoreTel uses a customized version of MGCP, a simpler standard that initially competed against SIP for endpoints. Of the larger traditional players, Siemens Enterprise and Aastra both made the switch to SIP as their default for enterprise systems. These manufacturers can sell their phones to a broader market, but also lose sales within their own base's. That's the double edged blade of interoperability, and it's a tough pill to swallow after some 40 years of proprietary systems. One area of differentiation being explored in the various models is the XML display. The browser remains largely untapped in SMB, but enterprises are integrating applications directly to the phone top; this functionality trend is likely just beginning.
SIP truly is an impressive achievement. It promises VoIP interoperability for both trunks and lines, an achievement the industry hasn't seen since analog was created over a 100 years ago. Unfortunately, the standard is very loose and limited. The looseness creates interoperability complexities and its incompleteness keeps the buttons and displays fairly simple.
It isn't clear if the industry will ever see more interoperability. Certainly, SIP could evolve, but other solutions may trump it. Vendors such as Mitel, Avaya, and Google are now extending features to any phone via direct inward dialing (the PSTN API). Or perhaps basic features are sufficient and more advanced features will move to the desktop portal (Digium, Siemens) or to applications accessible from the phone's XML browser. Another twist might be more intelligent phones modeling the iPhone's success. Android-based IP phones have already surfaced. Then there is also concept that phones may not even be needed further, replaced with softphones, USB devices, and cell phones
Dave Michels, Principal at Verge1 Consulting is a guest contributor to NoJitter and regularly blogs about telecommunications at PinDropSoup.com.
