Our Enterprise Connect SIP Trunking Tour made its next-to-last stop in San Francisco on Wednesday, and much of the discussion came down to a couple of specific issues: The challenges of interoperation among multivendor gear; and why SIP Trunking hasn't been more widely adopted.
The interoperation issue is different from an interoperability issue. Interoperation is what enterprises have to deal with because there is no true interoperability, i.e., a universally accepted and complied-with standard allowing for plug-and-play connection among multiple vendors' products. In the absence of this interoperability, enterprises must deal with one-off interoperation--making the different piece-parts of their own system work together to pass SIP traffic.
"We are absolutely still seeing those issues," said David Sauerhaft of Sonus, whose Session Border Controllers (SBC) sit in the middle of a diverse enterprise deployment to rationalize the plethora of one-off interoperations between vendor SIP products.
Interoperation needs to be done on two planes--signaling and media, Sauerhaft explained. Signaling is where the strict SIP translations have to be done; on the media plane, the challenge is translating different products' handling of media inputs like DTMF, so that DTMF tones generated by an endpoint on one vendor's system actually get passed and re-created correctly at the other end, where the recipient may be on a different vendor's system. Another media-translation issue arises when different codecs are used, and the SBC must perform transcoding so that the endpoints can exchange media.
DTMF issues, of course, can be a major stumbling block in an enterprise that uses IVR to interact with customers. David Sauerhaft recounted the case of a pharmacy chain that struggled with its SIP implementation because it underestimated the challenge of passing DTMF tones, with results that affected the bottom line: "These interoperation issues become key as we think about the ROI," he said.
The key is going into your SIP Trunking implementation with a clear idea of exactly the scope of the challenge you are faced with when it comes to interoperation. Our panelists described this as a matrix of interconnections that can grow unwieldy if you're trying to put together too many one-off interoperations--what Steve Lingo of XO Communications called a "big matrix, expensive matrix." You need "really solid implementation plans," he said.
Another question posed by Dave Stein of Stein Technology Group, who led our morning sessions, was: Why isn't SIP Trunking being more widely adopted? The panel generally agreed with Dave's guesstimate that about 80%-90% of enterprises have implemented some SIP Trunking, yet less than 10% had fully rolled out the service.
When Dave asked the panelists why they thought deployments were proceeding so slowly, they generally ascribed it to the very deliberate pace of the overall VOIP migration; IP-PBX rollouts have been slow, especially as the recession delayed upgrade cycles, so this affected the practical ability to roll out SIP trunks. Also, Carl Blume of Oracle (the former Acme Packet division), noted that, "There's a lot of complexity in bringing all this together--it's just going to take time," and he noted that the fact that most enterprises' carrier contracts expire at a staggered rate means you can't just forklift out the old circuits without incurring prohibitively large termination penalties.
John Vickroy of Cisco even argued that, in a historical context, the SIP Trunking migration hasn't been that slow--when you compare it to, for example, the migration away from TDM.
One final discussion was the now-familiar debate over SIP Trunking architecture--whether it should feature a centralized SBC at the datacenter connecting to the carrier over a single SIP trunk over which all the enterprise's traffic is aggregated; or whether multiple SIP trunks at distributed locations should be used. Until recently, Cisco had been alone on the side of distributed architectures, but on this year's tour, some of the other vendors have been hedging a bit. All agreed that a hybrid architecture might be the right approach.
But they were stumped when Steve Raab, a Bay Area consultant, posed this question: If an enterprise starts with a distributed architectures and buys licenses for multiple SBCs, will those licenses be transferrable if the enterprise consolidates to a single, large SBC? David Sauerhaft of Sonus and Carl Blume of Oracle basically punted on the question, and while John Vickroy of Cisco promised that the licenses would be transferable (in the future), Cisco would still charge a fee for making the transfer.
So what we saw confirmed once again in San Francisco is that with SIP Trunks, the devil is in the details--and there are a lot of details.
Follow Eric Krapf and No Jitter on Twitter and Google+!
@nojitter
Eric Krapf on Google+
