In theory, session initiation protocol (SIP) was supposed to make communications harmonious -- all endpoints would speak the same language. But not all organizations are all-SIP just yet, including
Although Avaya recently made SIP the center of its unified communications strategy with its Aura platform, the older systems in some of Delaware's state agencies used an older protocol, H.323, which couldn't inherently communicate with the state's newer, SIP-based Cisco Systems equipment, according to Mark Cabry, lead telecommunications engineer in the state's Department of Technology and Information (DTI).
"If you made a call from our Department of Transportation, that voice system cannot talk directly to the Department of Finance," said Cabry, who deployed Acme Packet's session border controllers in the state's two data centers to achieve voice over IP (VoIP) interoperability as the state consolidated and centralized its SIP trunks to various agencies and offices under one roof.
Linking all the infrastructure through the session border controllers has given the state a more efficient use of bandwidth on its T1 lines, allowing DTI to slash expenses by eliminating extra and unused primary rate interfaces (PRIs). By sharing the resources through a central line, the state is no longer limited by the need to have a separate T1 line for each office.
Because the newer Cisco equipment was SIP-based, it had been easier for DTI's networking team to deploy a SIP trunk between its systems and Verizon's Burstable Enterprise Shared Trunking service, Cabry said. The legacy H.323-based equipment from Avaya proved to be not so do-it-yourself, however.
"We've been trying to bring things in-house more and install more internally," he said. "[But] we were spending more and more contract dollars to get the Avaya stuff to work."
Session border controllers for protocol translation
It was clear the IT department couldn't keep dumping dollars into contracts, Cabry said, but replacing every Avaya device with a Cisco one throughout the 16 agencies that DTI supports would have carried a hefty price tag as well.
A session border controller can perform the protocol translation necessary for those sets of devices to be able to interoperate, according to Michael Leo, director of enterprise solutions marketing at Acme Packet.
"You could take a SIP trunk coming in and you can have it work with an IP PBX that is based on a different protocol," Leo said. "The session border controller acts as a traffic cop."
Over the past two years, Cabry and his team have been gradually tying agencies into the consolidated trunk, including – two weeks ago -- the 200-person Department of Services for Youth, Family and Children. The team is about one-third of the way through the project and is already seeing a return on investment, he said.
"We're getting lower long-distance bills and we're cancelling PRIs," Cabry said. "I think for enterprise customers, it's definitely the fit people are looking for."
Even enterprises that use all SIP-based equipment can still experience hiccups, Leo said.
"Even though it's a standard, there are minor little things that are different in SIP," he said. "If it comes from a service provider with a certain flavor of SIP -- yet the IP PBX is a different flavor of SIP -- [session border controllers] take that protocol and tweak it a little bit so the receiving IP PBX can actually take the packets into the [endpoint]."
While protocol translation and VoIP interoperability were the primary uses that drove Delaware's telecom team to deploy session border controllers, the device is most commonly used for SIP trunking between a service provider and enterprise, Leo said. It can also be used to secure, route and replicate sessions.
"Everyone says, 'Aren't you just a firewall?' You can kind of use that analogy, but [session border controllers] do a lot more than a firewall would do," he said. "Firewalls are not designed for interactive IP communication."
Let us know what you think about the story; email: Jessica Scarpati, News Writer