Finally, a SIP Trunking Standard that Makes Sense
With the ratification of v1.1, it can no longer be said that there is no standard for SIP Trunking. Whether v1.1 is widely acknowledged or adopted by the industry remains to be seen.
Regular readers of No Jitter are very familiar with the issues around SIP Trunking, not least of which is the lack of any meaningful or implementable standard. However, the SIP Forum has recently ratified its SIPConnect 1.1 Technical Recommendation for SIP Trunking; a significant event that has been a long time in coming: the work started on v1.1 in early 2008. To set the stage for an evaluation of v1.1, first let me (briefly) recap on the issues and history of SIP Trunking and related standards.
The Long Road to a SIP Trunk Standard
The concept of SIP Trunking originated 7-8 years ago as a mechanism for overcoming the limitations of the existing PBX to Service Provider connection technology--the PRI trunk--specifically:
* The 23/30 channel limit;
* The fixed (64kps) bandwidth per channel;
* Being tied into telephony toll rate plans for even inter-branch calls.
The use of SIP/RTP and the Internet to gain access to sources of PSTN origination and termination overcomes all of these issues, and many see "SIP Trunks" as an attractive alternative to PRI Trunks, particularly for enterprises that have deployed unified communications (UC) systems. However, the ambiguity within SIP standards caused varying implementations of SIP Trunk interfaces to be offered by service providers, thus slowing the adoption of the technology. The SIP Forum started its SIPconnect project in 2005, but conflicting interests within the participating consortium delayed the first release of the Technical Recommendation until January 2008. According to SIP Forum Chairman (then Technical Working Group Chair), Rich Shockey, SIPconnect 1.0 was a document that fell short of its original goals. In February 2008 Jonathan Rosenberg, one of the inventors of SIP, attempted to define SIP Trunking as an IETF "Best Current Practice", but this never got past "internet draft" status.
Despite these challenges, the potential of SIP Trunk technology has caused many new service providers to emerge to offer Internet-based alternatives to PRI lines. These firms offered disruptive pricing that made it difficult for incumbent service providers to contemplate adoption of SIP Trunks, since they would have to cannibalize their PRI revenues. The conflicts and confusion that emanated from this situation have significantly slowed the adoption of SIP Trunk services: particularly for enterprises using non-SIP-based PBXs which additionally require a PBX-SIP gateway. Nevertheless, as SIP-based unified communications systems have matured from lab trials to enterprise deployments, the interest in and demand for native SIP/RTP connections to the PSTN has grown rapidly.
The SIPconnect v1.1 Process
Undeterred by the SIPconnect 1.0 experience, the SIP Forum, then lead by Eric Burger, to its credit launched the SIPconnect 1.1 project almost immediately after v1.0 was ratified in early 2008. As stated above, the increasing interest in a SIP Trunk standard provided extra impetus for communications equipment vendors and service providers to agree on an implementable standard. At the time, I had just launched the Microsoft SIP Trunking program within the Unified Communications Group and, to everyone's amazement, Microsoft was an early supporter of the SIPconnect 1.1 initiative. Several firms, including Microsoft, contributed their own SIP Trunk specifications to the SIP Forum as a working basis for v1.1, and the document submitted by CableLabs (the R&D consortium of cable network providers) was selected as the best starting point.
The work on v1.1 got off to a brisk start, but as the team got ever deeper into the nitty gritty details of an implementable and meaningful standard, the progress slowed. In the interest of maintaining reader attention and to protect the innocent, I will gloss over those details and move on to the final result.
The key weakness of SIPconnect 1.1 as a SIP Trunk standard is that, apart from CableLabs and Skype, the telephony service providers are conspicuous by their absence in the list of contributors. This could be because they disagreed with the direction, or because they didn't see a SIP Trunk standard as being within their interests. One incumbent service provider participated for the first half of the exercise, but later withdrew. Consequently, service providers may be dismissive of this document as a valid standard; but, as always, declining to participate in a public process is a risky tactic that can undermine one's point of view.