TC2's David Rohde on Telecom
By David Rohde Posted December 2, 2009
When you go to install a new wide-area network technology that involves the interaction of carrier trunks with your premises equipment, do you:
a) trust statements of compliance by all parties with the technology’s open standards;
b) look to the carriers and equipment vendors involved to certify that each other party’s specific service or gear works with theirs, or
c) do you own interoperability tests?
This question is very much alive when enterprises go to buy “SIP Trunking” services from carriers. These services essentially make VoIP full-featured for corporate on-net and off-net calling, and reduce or eliminate dedicated local and long distance trunks in favor of dynamic allocation of packetized voice streams over data networks such as MPLS real-time classes of service. To do so, SIP Trunking relies on a set of IP standards that tell carrier networks, PBXs and other gear how to interpret call set-up instructions, signaling and other commands.
But like many standards, the Session Initiation Protocol itself and the SIP Trunking methodology that derives from it can be subject to interpretation and options. That can make things dicey when you consider what it’s replacing — TDM voice trunks, often into mission-critical call centers with call-transfer feature functionality, PRIs, national enterprise dialing plans, and the like.
If anything, SIP is particularly prone to this standards-extension challenge. At one of my VoiceCon sessions on SIP trunking earlier this year, one of the panelists said he had done a word search of IETF RFC 3261, the main (though not only) SIP standards document. He found that the word “may” showed up 378 times in the document. So much for a “standard” telling everybody in the industry exactly what to do!
The decisions that each vendor makes around these SIP choices is critical to what the industry labels interoperability but really means the kind of feature transparency that enterprises must have. To bring it home to many corporate telecom managers, there are functions such as “SIP Refer” and “SIP Redirect” defined in the standard. If the implementation of these items doesn’t emulate what call center managers have traditionally known as AT&T’s Transfer Connect, Verizon’s (previously MCI’s) Take Back and Transfer, or Sprint’s Agent Transfer, no amount of theoretical cost savings is going to be worth it for most enterprises.
When you go to investigate SIP Trunking and ask about this kind of interoperability, you’re bound to hear about the SIPconnect certification process established since 2005 by the SIP Forum’s IP PBX and Service Provider Interoperability Task Force. Any vendor’s compliance with SIPconnect 1.0 or the emerging SIPconnect 1.1 guarantees a certain degree of out-of-the-box interoperability.
And certain specialized, CLEC-type carriers have built a business around SIPconnect. They go primarily to smaller businesses and tell them that their locations can probably go straight to SIP Trunking and full-featured (for them) VoIP even with a wide variety of telephone equipment, including many older TDM switches.
But for larger customers, Verizon and AT&T make a point of doing their own SIP interworking tests on IP PBXs and then publicly “certifying” specific key vendors such as Avaya, Cisco and Nortel on their flagship families of IP communications gear. They don’t just rely on SIPconnect, partly because SIPconnect makes certain choices on SIP Trunking options that may not agree with some enterprise advanced features.
That’s why, when you go to Verizon’s page for IP Trunking Services, you’ll see “fact sheets” and “solutions briefs” speaking to relationships they’ve established with Avaya, Nortel and others to bring SIP trunking to the market. These are really references to interoperability tests but speak to the importance attached to knowing that specific gear provides a match to a carrier’s SIP Trunking implementations. (By the way, this will still be as key after Avaya completes its acquisition of Nortel, as these separate platforms remain widely deployed.) Some of these tests apparently took quite some time and a great deal of communication among the vendors away from the standards forums.
Even beyond that, the Verizon and AT&T panelists at my sessions have made the point that large customers can also come to their own labs to do their own tests. In this way, the ramp of SIP Trunking reminds me of the early days of MPLS, including in its original guise as IP-enabled frame relay, when customers felt they had to test older versions of Cisco IOS software releases to see if they would be supported over these new label-switching protocols.
Basically, the larger and more complex your organization, the more legwork is invariably involved with SIP Trunking, despite its roots as an IP standard. At some point the legwork factor will be reduced, especially if the service takes off in the marketplace, although there are plenty of signs that the major carriers would prefer to carefully manage this transition away from their traditional and profitable local trunking services. It’s an arc we’ll be following closely as the SIP Trunking story continues.