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.
SIP Transport
Although both UDP and TCP have been a part of the SIP standard since 1999 (see IETF RFCs 2543 [superceded] and 3261 [current]), v1.1 presents a strong preference for TCP/TLS and says that UDP is mainly supported for backwards compatibility. The document suggests that later versions of SIPconnect will remove the requirement to support UDP. This reflects a divergence in point of view with respect to UDP between the enterprise equipment vendors and the service providers.
The main advantages of TCP/TLS are:
* The avoidance of the packet fragmentation issue that emanates from the UDP packet size limit of 1,500 bytes;
* TLS, a secure (i.e. encrypted) SIP transport that is a basic requirement for enterprise network security, runs on TCP.
Service providers typically prefer UDP as a SIP transport because they contend that UDP has wider support; consumes far fewer resources within their network; and is less prone to malicious attacks. Several years ago while at Microsoft I posted a blog with the snappy title "To UDP, or not to UDP, that is the question...", which showed that TCP has universal support among equipment vendors and that UDP is technically inadequate as a SIP transport. Furthermore, the typical service provider SIP Trunk connection point (overwhelmingly a Session Border Controller [SBC], often provided by Acme Packet) supports TCP and TLS as well as UDP, so protocol support is not an issue. Since enterprise vendors typically reuse the same TCP session for the signaling of many calls (i.e. they don't set up and tear down a TCP session for every call) the "TCP overhead" argument turns out to be invalid. The use of an SBC also invalidates the vulnerability argument, as these devices are designed to cope with transport layer attacks (e.g. SYN floods).
SIP transport partisanship aside, v1.1 accommodates the requirements of older equipment while ensuring that business communications privacy can be maintained over the public Internet.
Authentication and Encryption
As stated above, v1.1 allows for encryption of the signaling and the voice channels, using TLS and SRTP respectively. By mandating TLS support, v1.1 is able to leverage the TLS Server Authentication model to ensure that the identity of neither the enterprise nor the service provider can be spoofed for malicious purposes (e.g. toll fraud). Where TLS is not the chosen SIP transport, the (weaker) SIP Digest authentication mechanism (i.e. username/password) is used.
Choice of Codec
Allegiances towards various voice codecs are often justified on objective grounds, such as bandwidth consumption or voice quality attributes. While G.729 often wins on these technical attributes, G.711 was chosen as the default codec for v1.1 primarily because of its ubiquity: G.729 is less widely deployed because of the onerous intellectual property and royalty issues of that codec. Certainly, G.711 uses 2-3x more bandwidth than G.729 and is therefore expensive for the enterprise; consequently, support for G.729 was specified as a "SHOULD".
"Registration Mode" vs. "Static Mode"
An area of significant debate during the v1.1 process was how the service provider would "discover" the IP route to a specific phone number (i.e. determine the IP address). The two options were "Registration Mode" and "Static Mode".
With Registration Mode, the enterprise is required to self-provision its externally visible telephone numbers in the service provider network by periodically sending a SIP REGISTER message containing its public Address of Record (AOR). The AOR is the list of e.164 format phone numbers and public IP addresses of its telephone endpoints.
With Static Mode, the service provider is required to statically provision the telephone numbers and enterprise IP address in its network edge. To accommodate enterprise network edge failover situations, there is also the option of performing a DNS lookup query against a range of addresses which the enterprise is responsible for maintaining.
Registration Mode has many advantages for the service provider, but few for the enterprise. As you can guess, service providers tend to support Registration Mode and enterprise vendors prefer Static Mode. The pros and cons of each are discussed in the v1.1 document, so I won't rehash those here. The final result was that the service provider has to support both modes, whereas the enterprise can choose either mode.
Personally, I never understood the service provider preference for "Registration Mode"; the ostensible argument was that it saves provisioning overhead for the service provider. This argument presumes that the IP address of the telephone endpoint is going to be registered with service providers, thereby eliminating the impact of "Moves/Adds/Changes". However, enterprises will never advertise internal network addresses externally, and the external network address will change only rarely (the main cause being enterprise network edge failover). Furthermore, the provisioning of numbers and routes in a service provider network has to be implemented at every point in the core network--so saving on the provisioning of the network edge seems (to me) to be a non-existent economy, particularly when a DNS lookup is free.
Scope Limitation and Areas for Future Work
There are a number of areas that v1.1 does not cover and many of these are impractical (e.g., the non-existence of video support in the PSTN), or there remain significant gaps in existing standards or regulations (e.g. emergency services):
* Video and other unified communications modalities such as Instant Messaging and Presence;
* Hosted SIP services;
* Emergency services or E911 implementation;
* IPv6 support;
* FAX support;
* Support for service provider hosted voicemail;
* QoS considerations.
Summary
Overall, SIPconnect 1.1 is a brave attempt to define a standard for SIP Trunking and, in my opinion, all of the major areas that would enable the implementation of a SIP Trunk service have been covered. As discussed above, some of the issues were not resolved to the satisfaction of all, and the participation of the incumbent telephony service providers in the process was non-existent. Although those service providers could claim that v1.1 does not represent their point of view, there is significant accommodation of their requirements in the document.
Absent mainstream adoption of this, or any other, SIP Trunk standard, I have already predicted in a paper on the future of communications networks that the service providers will be bypassed altogether by Internet federation as businesses and consumers alike move beyond the era of telephony and into the era of unified communications.
