Lessons from Large Scale UC Deployments: The Role of Enterprise SBCs in Hybrid UC Networks
Introduction
When considering a migration to Unified Communications (UC), businesses encounter many problems that they must work through. Since most companies have some amount of legacy voice technology in place, they often want to maximize their current investment, and express great interest in using solutions that meld legacy and UC technology. But creating these kind of hybrid environments to interwork properly, at scale, can be challenging. This brief examines how the prudent implementation of Session Border Controllers in the enterprise (E-SBCs) can be used to ameliorate two common types of problems that exist in hybrid UC environments:
Using multiple SIP trunk service providers. In the case of the insurance company we’ll examine, it elected to move from a de-centralized to centralized architecture, and to use both AT&T and Verizon Business SIP trunks and MPLS services to serve the same data and contact centers in the U.S. The insurance company employs this architecture to achieve a high level of continuity to support business critical applications.
Using multiple telephony/UC suppliers. In the case of a state government, it consolidated a combination of legacy TDM key systems, H.323-based IP-PBXs, Microsoft Unified Messaging servers and Cisco Unified Communications Manager in a manner that promotes seamless, cost-effective VOIP. This hybrid infrastructure is an interim step in its long term UC architecture.
Case in Point: Using Multiple SIP Trunk Service Providers
A Fortune 500 insurer had pursued a data center consolidation plan, followed by a two-part voice infrastructure upgrade plan. The first part of the voice infrastructure plan is the consolidation of the IT and network infrastructure that supports the company’s 22 domestic contact centers. The size of each contact center varies—some support several dozen, others support several hundred agents. In addition, the vendor and vintage of contact center equipment varied by location—but all of it was TDM-based, served by hundreds of PRIs.
Going forward, in addition to centralization, standardization and reliability are equally important objectives. The company had initially favored a Cisco contact center solution, but discovered that Cisco’s SBC (CUBE) could not scale to meet its production requirements to support 16,500 active simultaneous sessions. The insurer implemented a completely redundant solution using Avaya’s Session and Communication Managers, supported by Acme Packet E-SBCs. The E-SBCs interface to AT&T and Verizon SIP Trunks, which connect to each provider’s IP Toll Free services. In the event of an outage or congestion, the toll free service of one provider is configured to overflow to the other. In order to support a high availability architecture, the E-SBCs interface to both service providers’ MPLS services, which supply physically diverse connections between the data centers.
Given the importance of its contact center operations, the insurer elected to undergo a lengthy trial process. Lab tests with all participating vendors and providers uncovered some key challenges that included:
Glare caused by IP Shuffling. About 30% of the calls experienced interworking and timing problems for SIP RE-INVITE messages between Avaya Session Managers and the service providers. By conducting high-volume end-end testing with in-line E-SBCs, the problem, which resulted in dropped calls, was correctly identified and rectified.
Signaling renegotiation for bandwidth optimization. Inbound calls from both service providers’ SIP trunks to the contact center are compressed using G.729 coding (33 Kbs/call) for bandwidth efficiency. However, the IVR interface onsite requires G.711 coding (93 Kbs/call). After the IVR portion of the call is complete, the E-SBC renegotiates the call back to G.729 as part of the transfer to the answering agent, saving the company significant bandwidth on final call treatment. E-SBCs play a vital role in controlling the SIP signaling necessary to ensure seamless codec renegotiation functions.
SIP Security at Scale. Given the high volume of calls the customer wants to support (over 10,000 concurrent calls) another important issue was SIP security. Software-based firewalls and other security appliances cannot sufficiently scale to this performance level. The customer employed E-SBCs with dedicated hardware to detect and respond to security threats.
After resolving these and other issues in a lab environment, the company transitioned to a field trial that currently supports 2,000 concurrent calls. Extensive lab testing helped ensure success with field trials, which have been so successful that the insurer plans to migrate 100% of its inbound traffic from PRIs and onto SIP Trunks before the end of 2011. At that time, 100% of the PRIs that support inbound applications will have been transitioned to SIP.
At this phase of the project, the company’s focus is on infrastructure. The company still operates the same contact centers, but all the important data and voice systems are centralized in the two data centers. Ultimately, the insurer plans to completely transition to a UC platform for all its employees. As it migrates to the new architecture, it will de-commission legacy access, services and equipment and realize additional cost savings.
Case in Point: Using Multiple UC/Telephony Vendors
A state government faced the dual challenges of shrinking revenues and increasing demand for services. State agencies had operated fairly independently-each with its own IT and network infrastructures and staffs. Like many of its peers, the state wants to save money and gain efficiencies by consolidating operations. The Executive Branch, with over 150 agencies, began this process by centralizing its IT infrastructure into two data centers. These are the same sites that house its UC systems. Many PRIs and in-band trunks have already been de-commissioned -- 98% of the calls that originate or terminate between the UC platform and the PSTN are served by SIP trunks. As additional offices migrate to UC, usage (and size) of SIP trunks will grow, and legacy TDM trunks and POTS lines will be terminated.
The Executive Branch elected to standardize on a Cisco Unified Communications Manager platform, complemented by Microsoft Exchange Unified Messaging. Since its transition to UC will occur gradually, these systems must interface with legacy systems that are installed on a de-centralized basis. For instance, like many of its peers, the state still employs ISDN centrex service; many key systems are installed in small/satellite offices. Both of these technologies will ultimately be de-commissioned. But during the interim, these and other types of legacy telephony systems are part of the state’s network, and calls between these sites and sites served by UC must work flawlessly. Two primary UC-legacy voice interoperability challenges the state faced include:
Interworking between sites served by Cisco and Avaya systems. The telephony assets ranged from Cisco UCM platforms with SIP trunking capabilities to older Avaya platforms that could only support H.323 trunking. Neither vendor directly supports seamless SIP/H.323 protocol interworking- a solution was clearly needed to migrate to UC. After performing considerable due diligence, the state selected Acme Packet E-SBCs for this purpose.
Interworking between Avaya and Microsoft UM voicemail platforms. The pace of the migration to UC required voicemail interworking between legacy (H.323-based) Avaya platforms and a Microsoft SIP-based platform. While upgrades to SIP are available from Avaya, the state elected to employ the same E-SBCs for legacy Avaya: Microsoft UM (H.323 trunk : SIP trunk) voicemail interworking. This saved the state significant software license fees and other upgrade costs.
Summary
In addition to SIP demarcation and security issues, E-SBCs can be employed to ameliorate many vendor and service provider variations that are common in today’s UC implementations. As examined above, these problems can be no more than a bump in the road, or severe enough to completely halt a company’s migration to SIP. They can exist between vendors and service providers, between one PBX vendor and another, and between different vintages of the same vendor’s equipment. These problems are not just about session control. They can adversely impact the application, as we’ve seen here when interworking different vendors’ voicemail/unified messaging platforms, or when switching compression algorithms during an active call. Similar types of problems can exist when interfacing different implementations of videoconferencing codecs (see http://www.ucstrategies.com/unified-communications-expert-views/videoconferencing-opportunities-challenges-and-solutions.aspx). Depending on the functionality of the particular vendor, E-SBCs can ameliorate these types of challenges as well. But not all E-SBCs are equally up to meeting the challenges of scale and complexity, so customers should take their time to perform due diligence. And as we’ve seen, thorough pre-service testing with all key suppliers is absolutely essential to successfully move from lab to field trial, and on to production environments.
This paper is sponsored by Acme Packet.