The consensus out of the SIP Trunking sessions at last week's Enterprise Connect seemed to be that the migration from legacy PRI access lines to SIP Trunks is progressing, but still not as quickly as end users would prefer, given the cost savings that they've been told to expect from the new service. As Zeus summed it up, SIP Trunking remains "long on promise and short on results." In his SIP Trunking tutorial at the show, Sorell Slaymaker estimated that 80% of enterprises are piloting SIP Trunks, yet less than 5% have completed their migration.
The carriers--especially AT&T and Verizon--got their share of the blame for slow-rolling the new service, so as to avoid cannibalizing their existing revenue streams from legacy services. There have also in the past been SIP Trunking skeptics like Marty Parker of UniComm Consulting, who have argued that SIP Trunks don't really save money, and that their benefits in terms of enabling end-to-end IP for communications are attainable via other means such as UC federation.
Last week's Orlando show saw the emergence of yet another voice in the SIP Trunk debate, one that can't be ignored: Cisco. And Cisco is making the case that the architectural model that most people use when designing their SIP Trunking model is not necessarily right for every enterprise.
Much of the savings ascribed to SIP Trunking is tied to an assumption about the enterprise WAN architecture, namely that it will move toward a more centralized model: communications functions will be consolidated in the datacenter, and voice traffic will be backhauled on the company WAN from remote offices to the datacenter, where a single SIP Trunk will carry all of the enterprise's external traffic to the PSTN. In practice, this is generally a mirrored datacenter, so you end up buying two SIP trunks.
Here's how Sorell Slaymaker sums up the ways that SIP Trunking lowers costs:
* Aggregation of Trunks--By combining all voice trunks from many office sites into a few data centers, a business can reduce the number of voice trunks required across the entire enterprise by 30-50%.
* Aggregation of Access--A few Ethernet links are cheaper than many T1s
* On-Net Calling--All inter-company calls go over the WAN. If audio conferencing and/or IVR services are outsourced to a 3rd party, the connection to the 3rd party is through an IP/SIP connection.
* Free Features--Many of the features that were charged separately are now bundled into the overall fixed monthly charge, like D channels
* Tariffs--With SIP trunks, a lot of the traditional tariffs that applied to TDM telephony no longer apply--Intrastate vs. Interstate, local usage, USF
* Competition--Using multiple SIP trunking providers, esp. for outbound calling
* Billing--40% of the phone bill is the phone bill. An extraordinary amount of effort goes towards tracking usage and the appropriate internal charge backs
* Support--In a centralized model, the managing, administration, and support of voice trunks is simpler, easier, and cheaper. Most changes are software based.
So up to now, the classic business case for SIP Trunks has been inseparable from the assumption that enterprises will move from a model where PBXs (legacy TDM as well as IP-PBXs) are distributed around the network, each serving a single site or a relatively small cluster of sites, to one where voice is a datacenter application scaling into the tens or even hundreds of thousands of users served by virtualized communications services deployed on virtualized server instances within the corporate datacenter where all the other mission-critical applications live.
When I met with Jason Rolletson, director of product management for the CUBE SBC product for Cisco, he told me that Cisco is fully supportive of the centralized model, and that CUBE can support such a deployment. But he went on to say that centralization isn't necessarily the right move for every enterprise now; that it may never be the right move for companies that rely on video in the future; and that in any event, the move to centralization is anything but a flash cut.
Next page: Cisco's Reasoning
That last item makes some sense and seems logical as one reason why companies aren't going from pilots to full deployment overnight. For most companies, such a transition would represent a "tremendous rip and replace," Jason argued, and it's hard to disagree, at least if you see the PBX infrastructure aging gracefully. If your enterprise has a multitude of IP-PBXs out there, not yet depreciated, then building a centralized "PBX" in the datacenter would represent a major duplication of investment. You could essentially lobotomize those distributed IP-PBXs and use them only as IP gateways, so you wouldn't necessarily wind up "ripping" them out, but you would be replacing a functionality that otherwise wouldn't need replacing.
The argument that centralization may never be the right architecture is pure Cisco, relying as it does on the belief that video is going to be, in the words of CEO John Chambers, "the new voice." If that does come to pass, Jason Rolletson pointed out, the centralized architecture, which "hairpins" all "calls" to the datacenter and then out, has the potential to create sub-optimal performance, since it introduces delay into the transmission.
In short, the argument is that the pendulum will swing back, and distributed architectures will come back into favor as centralization produces bad video performance.
"You have to think beyond voice," was how Jason Rolletson put it.
As Zeus pointed out in his writeup, the carriers really aren't thinking beyond voice at this stage when it comes to SIP Trunking--though perhaps the fact that the challenge came to them in the form of an audience question indicates that at least some enterprises are advancing into multimedia--or would like to.
Again, Jason Rolletson emphasized that Cisco is perfectly willing to support centralized models if that's where the customer is in their roadmap. But the push for a distributed alternative also plays to a major Cisco strength relative to their main competitor in this space, Acme Packet: Cisco sells CUBE as a software load running on its routers, so it has more flexibility in how it can sell SBCs (which support SIP Trunks) than Acme Packet, which started out in the carrier space and has been strong in larger enterprise deployments. Cisco customers already have the hardware for CUBE in the form of their edge routers at distributed sites, so Cisco can do one of the things it does best: Leverage its incumbent position and sell into a range of customers, from large to small.
Jason Rolletson conceded that, "I don't think Cisco has been sufficiently loud in this market," which is not an admission you hear every day. Still, he claims Cisco is selling "a ton of this stuff," which is not necessarily hard to believe given the very large foot that Cisco has in most enterprises' doors.
Cisco clearly intends to get a bit louder in the SBC market. The question with regard to SIP Trunks is whether the distributed architectural model is compelling enough to motivate enterprises to make the move to SIP Trunks, or whether the cost savings case can only be made in conjunction with the centralized architecture--because you lose the traffic engineering benefits when you don't consolidate on a single SIP Trunk, and because if you have to buy SIP trunks for individual sites, you might wind up needing to manage multiple carriers in multiple geographies. The ultimate question may be whether a distributed SIP Trunk architecture is worth the effort.
