A year ago, when Cisco first started pushing the notion that enterprises should not assume that their communications architecture would be heavily centralized in a SIP Trunking future, they pretty much stood alone. They were the only session border controller (SBC) vendor really advocating strongly for a distributed option, and the motivation seemed patently self-serving: Cisco was offering its CUBE SBC as a software application to run on its edge routers. In other words, they were doing what Cisco always does: Telling enterprises to put more functionality into a Cisco router.
A year later, however, other SBC vendors are buying into the distributed vision. At our SIP Trunking Tour stop in Las Vegas this week, representatives of Acme Packet and Sonus both suggested that a distributed architecture could be the way to go, even if adopting such an architecture means the enterprise can't capture all the economies of scale that are available when you centralize call control and carrier access in a single (or mirrored) datacenter.
Jonathan Zarkower of Acme Packet conceded that his company, when it entered the enterprise SBC market in 2004-2005, recommended the centralized model as the most efficient and cost-effective solution. Now, he says, it depends on the individual enterprise's situation.
His comments were echoed by David Sauerhaft of Sonus, who agreed that the choice has to be made on a case by case basis. "I wouldn't get too hung up on it," Sauerhaft said. "Run the numbers and that will lead you to the decision that's right for your business."
For one thing, there seemed to be a realization that not all distributed enterprises are created equal. If you have a lot of very small sites where it's not economical to maintain any call control, it may, in fact, make sense to centralize resources and therefore SIP Trunks. But if you're highly distributed but have remote sites with heavy communications needs, both in terms of capacity and performance, it may make sense to provision SIP trunks to each of these remote locations, rather than backhauling VOIP traffic to a central site and shipping to the PSTN carrier across a consolidated SIP Trunk.
The one carrier representative on our panel, Steve Lingo of XO Communications, pointed out that centralizing resources in a single site or region, for a nationwide or global enterprise, creates potential performance issues as traffic hairpins through the central site, traversing far more miles of network than necessary. "You can't ignore geography's impact on your network," Lingo said.
(Steve has also posted on No Jitter about how centralized deployments may mean having 2 or 3 main locations for SIP Trunks, not just one.)
It's not just the architectural discussion that's becoming more nuanced as SIP Trunking continues its slow but sure rollout. There's also the issue of how hard you press the cost savings issue.
Jim Allen, the consultant and end user who led our morning sessions, pointed out that his company, which has completed about 95% of its SIP trunking rollout, will still be split essentially 50-50 between SIP Trunks and PRIs--the latter being the incumbent technology designated for the scrap heap in the typical hype story for SIP Trunking.
Keeping the PRIs gives Jim Allen's deployment greater diversity and resiliency, which is critical in a rollout in which contact centers figure prominently. Jim explained that he was able to achieve 50% cost reduction even while leaving a significant amount of PRIs in place, and added that he was willing to sacrifice the even greater ROI that he might have captured had he been willing to cut back even further on the PRIs. He also noted that much of the savings he did capture was attributable to the fact that the enterprise was overprovisioned with trunking capacity in its pure-PRI deployment, so much of the savings was more like a "right-sizing" of the WAN bandwidth.
So the notion of completely replacing your PRIs with SIP Trunks may also not be a given, and there are multiple flavors of both centralized and distributed deployment architectures. Seems like the questions around SIP Trunking get less settled as time goes on.
Follow Eric Krapf and No Jitter on Twitter and Google+!
@nojitter
Eric Krapf on Google+
