Cloud-Driven IVR: Connecting on-Premises Solutions to Windows Azure
Technical Case Study
Published: March 2011
The following content may no longer reflect Microsoft’s current position or infrastructure. This content should be viewed as reference documentation only, to inform IT business decisions within your own company or organization.
Microsoft Customer Service and Support (CSS) servers that host Interactive Voice Response (IVR) applications take more than 200,000 calls per day. Microsoft Information Technology (Microsoft IT) used the Windows Azure technology platform connected with on-premises telephony technology to increase business capabilities and reduce cost.
Technical Case Study, 363 KB, Microsoft Word file
Products & Technologies
For Microsoft Customer Service and Support, demand for dynamic, data-driven IVR applications was increasing.
Microsoft IT connected a multiple-application platform to Windows Azure so that lines of businesses can manage and create their own telephony applications without the overhead cost of developing and maintaining code.
Many businesses are discovering the benefits of using cloud-based services. In some cases, however, on-premises technologies are not supported or would be too costly to move directly to the cloud. For example, Windows Azure currently does not support telephony infrastructure. But even in these cases, organizations can take advantage of the cloud. Connecting existing on-premises solutions to the cloud can be a cost-effective way to expand solution capabilities.
For CSS, Microsoft IT maintains 12 business-critical IVR applications that support more than 20 languages. These business-critical applications collect information from Microsoft customers who are calling the CSS toll-free telephone numbers for assistance. They also route calls to the appropriate representatives. These applications range from allowing simple dual tone multi-frequency (DTMF) input to full speech-recognition capabilities.
As Microsoft releases new products and services, CSS business analysts must create or modify existing IVR applications by following a well-established process. Typically, the process—from gathering requirements to deployment—takes 30 to 180 days or more, depending on complexity. The delay between product release and changes to the CSS IVR application has the potential to affect customers who are calling to receive support for new Microsoft products and services.
Currently, most customer-facing IVR applications at Microsoft use managed code written on top of Microsoft® Office Communications Server 2007 Speech Server. Microsoft IT plans to decommission these servers and upgrade to a Microsoft Unified Communications Managed API (UCMA) 3.0–based platform supported by Microsoft Lync™ Server 2010.
Because some of Microsoft IT's IVR infrastructure is hosted in third-party data centers with no access to the Microsoft corporate network, Microsoft IT decided to connect IVR applications to Windows Azure. Windows Azure enables third-party data centers to access IVR application data without needlessly exposing the corporate network to these data centers. Windows Azure also enables Microsoft IT to deploy this solution in geographically dispersed sites so that the data centers have the most optimal connection.
For the connection to Windows Azure, Microsoft IT chose to create a platform that hosts multiple IVR applications. This platform enables business analysts to enter data via a graphical user interface (GUI)–based tool to define call-flow configurations for their specific line of business. The data is dynamically rendered into VoiceXML 2.0—a World Wide Web Consortium (W3C) standard—and made available to authorized IVR servers hosted in data centers across the world.
Microsoft IT had three business requirements for the solution: compatibility, response time, and availability.
The solution needed to be compatible with both Speech Server and UCMA 3.0. Microsoft IT addressed a critical issue of compatibility by standardizing on VoiceXML. The majority of CSS's IVR applications were written against a managed-code application programming interface (API) specific to Speech Server. Taking advantage of the VoiceXML support inherent in both Speech Server and UCMA 3.0 enabled Microsoft IT to build an application platform that works with the existing Speech Server infrastructure while it upgraded and migrated to the UCMA 3.0-based IVR platform.
Microsoft IT established a requirement of a four-second response time, but it had to resolve the potential latency and connectivity issues faced when connecting on-premises IVR servers with an application deployed on Windows Azure. Although the solution could have allowed individual IVR servers to make representational state transfer (REST)–based Hypertext Transfer Protocol (HTTP) requests directly for each caller, it posed the risk that callers would experience significant delays in hearing the appropriate audio files.
To solve this problem, Microsoft IT created a proxy service, which makes security-enhanced requests to a service hosted on Windows Azure. The proxy service caches the formatted response, along with the associated audio and grammar files. This proxy service uses Windows Azure Service Bus to receive notifications when a change has occurred to the application data and/or resource files in the cloud, and to expire those items from its local in-memory cache.
Windows Azure currently offers a service-level agreement (SLA) of 99.9 percent. Microsoft IT had a requirement to provide at least 99.99 percent uptime for Microsoft customer callers. By using a caching model with the proxy service, Microsoft IT can maintain 99.99 percent uptime for incoming callers, and provide 99.9 percent uptime for business analysts to access application data in the cloud. Even scheduled Windows Azure downtime does not affect Microsoft callers.
Windows Azure is built on service-oriented architecture (SOA) principles, which enable an organization to design solutions to extend and reuse standard services. Microsoft IT divided its solution into four main components based on the following services:
- VoiceXML Data Service
- Proxy Service
- Administration Dashboard
Figure 1 shows how these components function in the solution.
Figure 1. Solution architecture
VoiceXML Data Service
The VoiceXML Data Service is a Windows Azure web role that accepts requests for specific application data and returns the appropriate VoiceXML responses. When the service receives a request, the service expects a token to be included as part of the request and validates the token against the Access Control Service (ACS).
If the token is valid, the service queries the application database based on the request parameters. The data set from the data base is converted into VoiceXML and returned as a response to the request.
The Proxy Service is a service that resides within the on-premises network, to broker requests to the VoiceXML Data Service on Windows Azure. At startup, the Proxy Service performs three primary actions: It synchronizes audio and grammar files, registers against Service Bus, and exposes a local HTTP endpoint.
Collectively, resource files like audio and grammar files can be quite large for a single application. To deal with this, the Proxy Service checks which resource files it already has, and compares that to the list of resources stored in its instance of Windows Azure Blob Storage. If any of the resource files are missing, the service will asynchronously download each missing file.
When the local HTTP endpoint receives a request, the Proxy Service checks its in-memory cache for the VoiceXML data. If the proxy does not contain a cached response, it will request a response from the VoiceXML Data Service on Windows Azure.
In accessing the VoiceXML Data Service, the proxy first requests a token from the Windows Azure ACS for a token. When the proxy makes the request to the VoiceXML Data Service, the ACS provisioned token is sent along with the request. The Windows Azure hosted service can accept or deny the request based on the token.
By using Windows Azure Service Bus, the Proxy Service receives notification when application data—such as VoiceXML data, or audio files and grammar files—has changed. It removes those items from its cache and retrieves a new copy.
The Administration Dashboard enables authenticated business users to create and modify call flows, and to conduct basic administration tasks such as viewing reporting metrics or adding and removing users from the system. Microsoft IT developers were able to create this tool by using existing technologies and patterns they were already familiar with, such as the Microsoft Silverlight® browser plug-in, the ADO.NET Entity Framework, and the Model-View-ViewModel (MVVM) pattern.
When a business analyst modifies a call-flow configuration, a message is placed into the Windows Azure Queue Storage and is processed by the Queuing Service to determine whether it should notify the proxy service of the change.
Because Windows Azure supports most modern web technologies, Microsoft IT was able to use its existing on-premises application development tools and skill sets. Microsoft IT developers did not have to invest a lot of time learning something new. And in some of cases, they could deploy existing applications without making any changes to code.
Windows Azure enables Microsoft IT to pay for only what it uses. This presents an estimated 80 percent savings in infrastructure costs in terms of both dollars and time to purchase, install, configure, and maintain new hardware.
Although some applications can be deployed on Windows Azure with no code changes, some best practices for these applications differ from best practices for on-premises applications. For example, in an on-premises application, storing application settings typically occurs via Web.config. Web.config is part of the Windows Azure deployment package, and a change to that file requires a complete redeployment of the application. It is therefore a best practice to move those name-value pair application settings to the Windows Azure configuration file instead. Administrators can then make changes to these settings without deploying a new package.
The other major difference is that because Windows Azure and the Microsoft SQL Azure™ technology platform do not utilize Active Directory® Domain Services, an organization must plan to manage the various keys and connection strings that are needed to maintain and make changes to its Windows Azure and SQL Azure instances.
Windows Azure standard services offered with AppFabric, such as Access Control Service and Service Bus, enable an organization to extend on-premises solutions to the cloud.
By connecting on-premises telephony technology to Windows Azure, Microsoft IT delivered expanded business capabilities and reduced development cost to the business, without increasing hardware footprint in data centers.
For More Information
For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Order Centre at (800) 933-4750. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:
© 2011 Microsoft Corporation. All rights reserved.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, Lync, Silverlight, SQL Azure, and Windows Azure are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.