This chapter describes the major components of the Cisco Customer Voice Portal:
•Typical CVP Deployment
•CVP Solution Components
Typical CVP Deployment
Figure 2-1 illustrates the various components in a typical full-featured CVP deployment. It does not show redundant components.
Figure 2-1 Typical CVP Deployment
CVP Solution Components
The Cisco Customer Voice Portal (CVP) consists of the following components:
•CVP Call Server
•Cisco Ingress and VXML Gateway
•CVP VoiceXML Server
•CVP VoiceXML Studio
•Standalone Distributed Diagnostics and Services Network (SDDSN)
•Cisco Content Services Switch (CSS)
•Cisco PSTN Gateway (PGW) Softswitch
•Third Party Media Server
•Third Party Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server
•IPCC Enterprise and Intelligent Contact Management (ICM)
Depending on the particular deployment model in use, some of the above components might not be required.
Once deployed, CVP provides an integrated self-service, queuing, and switching solution.
The following sections discuss each of these components in more detail. For the most current information on a particular product, refer to the specific product documentation available online at:
Note This design guide focuses mainly on CVP components and deployments. For the most current, in-depth technical information on the other products listed above, refer to the latest versions of the additional design guides available at http://www.cisco.com/go/srnd.
The following sections present an overview of each of these components, and give a general discussion about how each component interacts with the rest of the system.
CVP Call Server
The CVP Call Server is the central component in an ICM-integrated CVP implementation. It is located logically between the gateway and ICM's VRU PG. It is made up of two parts: the CVP Voice Browser and the CVP App Server.
The name "CVP Voice Browser" is historical. As of CVP 3.x and ICM 7.0(0), it is no longer used as a voice browser. Its main purpose is to manage the H.323 signaling between the ingress/egress gateways, VXML gateways, gatekeepers, and CallManager. The CVP App Server is the interface between CVP and ICM. It manages the GED-125 interface with ICM on one side, and on the other side it exchanges VoiceXML instructions with the CVP Voice Browser for call control purposes, and with the VXML gateway for caller treatment purposes. It is also responsible for interpreting the Microapp requests from ICM and converting them into VoiceXML pages which the VXML gateway's voice browser can execute.
In earlier releases of CVP, it was not unusual to physically place the two CVP Call Server processes on different machines. However over time it was learned that there is no real advantage to doing so, and that it created unnecessary troubleshooting difficulties. The best practice now is to always place both processes in the same machine. Throughout this document we do not distinguish between the two processes which run on a CVP Call Server, since it is rarely significant to the discussion. The only exception is when we discuss High Availability Design, where it is important to understand how messages flow between these processes individually.
Cisco Ingress and VXML Gateway
Calls arrive at the gateway or router from one of two sources: the PSTN or the IP network. The gateway is responsible for performing the following functions:
•Converting TDM voice signals to Voice over IP (VoIP), if necessary
•Connecting and reconnecting calls to VoIP terminating destinations
•Executing voice treatment and switching instructions in the form of VoiceXML documents
The gateway interacts with the CVP Call Server in two ways. In deployment models which integrate with ICM (see Chapter 3, "Deployment Models"), the gateway exchanges H.323 call control instructions with the CVP Call Server. When it is performing these call control activities, it is known as an ingress gateway. In all deployment models, the gateway might also be executing VoiceXML operations via its built-in IOS Voice Browser software. A gateway which performs VoiceXML operations is known as a VXML gateway.
As an ingress gateway, the arrival of a new call causes an H.323 call setup operation to occur between the gateway and the CVP Call Server. As a VXML gateway, the arrival of a new call invokes a flash-resident VoiceXML application and begins making requests to either the CVP VoiceXML Server or the CVP Call Server for VoiceXML pages to execute, depending on the deployment model in use.
Supported gateways include the Cisco 2800 Series, 3700 Series, 3800 Series, 5350XM, 5400 HPX, and the 5400 XM. The AS5850 ERSC and the Cisco Catalyst 6500 Communication Media Module (CMM) is also supported as an ingress/egress gateway only. For the most current list of supported gateways, refer to the latest version of the CVP 3.0 Bill of Materials (BOM), available at
The gatekeeper is a network element used by the gateway for call transfers. It is an optional component in certain deployments; however, in practice most installations incorporate a gatekeeper for dial plan configuration and bandwidth management.
When the gateway receives instructions from the CVP Call Server to transfer a call, it first matches the destination number with its dial peers. If the matched dial peer specifies gatekeeper lookup (that is, session-target ras), the gateway will query the gatekeeper with the transfer destination label. The gatekeeper, in turn, replies with an IP address to which the gateway will transfer the call.
As of CVP 3.1 SR1, two gatekeeper failover mechanisms are supported: Hot Standby Router Protocol (HSRP), and Alternate Gatekeepers.
For more information on H.323 gatekeepers, refer to the Cisco gatekeeper product documentation available online at Cisco.com.
CVP VoiceXML Server
The CVP VoiceXML Server delivers external VoiceXML documents to the gateway. Customers write voice applications using the CVP Studio, described below, and deploy them to the CVP VoiceXML Server.
As calls invoke external VoiceXML, the CVP VoiceXML Server builds VoiceXML pages dynamically according to the contents of the deployed application. The CVP VoiceXML Server interacts only with the gateway, but the gateway requests the VoiceXML document from the CVP VoiceXML Server upon command from the CVP Call Server.
In a CVP Standalone Self Service model configuration, in which the gateway and CVP VoiceXML Server are deployed (without requiring CVP Call Server for IP switching and/or IPCC), the gateway requests VoiceXML from the CVP VoiceXML Server as soon as it receives an appropriately designated new call.
Multiple CVP VoiceXML Servers might be used in a given deployment for scalability. In such cases, configure them all identically, and use a Cisco Content Services Switch (CSS) to balance the load across them.
CVP VoiceXML Studio
The CVP VoiceXML Studio is an Integrated Development Editor that is based on the open-source Eclipse framework. It provides a graphical user interface for designing complex IVR scripts, as well as a palate containing a rich set of standard scripting elements. The palate can be expanded to include reusable custom elements which the customer or partner can write, or which might be obtained off-the-shelf from third party vendors. Such extensions are often used to provide direct integration with back-end systems in the corporate infrastructure.
CVP VoiceXML Studio is a software product that can run on any Windows XP or 2000 machine. However, since the license is associated with the IP address of the machine it is running on, customers typically designate one or more data center servers for that purpose.
Standalone Distributed Diagnostics and Services Network (SDDSN)
The Standalone Distributed Diagnostics and Services Network (SDDSN) is a component that provides alarm reporting for CVP through the following mechanisms:
•CiscoWorks2000 Syslog, which receives log messages and permits queries on the logs
•Microsoft Windows Remote Access Service (RAS) and Hosted IPCC or Intelligent Contact Management (ICM) Event Management System (Cisco Remote Monitoring Suite), traditionally named Cisco Phone Home
SDDSN must reside on a separate server from any CVP or ICM component.
For the most current information on the hardware requirements for the SDDSN, refer to the latest version of the CVP 3.1 Bill of Materials (BOM), available at
Cisco Content Services Switch (CSS)
An optional Content Services Switch (CSS) provides a high-end failover solution. For example, you can use a pair of Cisco 11503 Content Services Switches to provide high availability and load balancing. The gateway requests VoiceXML documents, prerecorded prompts, grammar files, and ASR/TTS treatment from back-end servers. In the CVP failover solution with the CSS, the gateway is the client while CVP application servers, CVP VoiceXML servers, ASR/TTS servers, and HTTP media servers are the back-end servers, all of which are configured as services in the CSS.
While CSS is an optional component, it is important to understand the tradeoffs involved in deciding whether or not to use it. This is discussed in the section on CVP High Availability Design (see Chapter 5, "Designing CVP for High Availability")
Cisco PSTN Gateway (PGW) Softswitch
The Cisco PGW Softswitch is a flexible multiprotocol Media Gateway Controller (MGC) that provides a bridge between the legacy public switched telephone network (PSTN) and IP networks. It supports either a simple Signaling System 7 (SS7) interconnection or intelligent call control and routing functions.
The Cisco PGW Softswitch provides a consistent, unified interconnection that can handle dial-up services, MGCP, Session Initiation Protocol (SIP), and H.323, as well as future standards. The PGW enables service providers to deploy and operate multiple network solutions while maintaining a stable connection to the PSTN.
Third Party Media Server
The media server is an optional network component which can provide prerecorded audio files, external VoiceXML documents, or external ASR grammars to the gateway. Because some of these files can be stored in local flash memory on the gateways, the media server can be an optional component. However, in practice, most installations use a centralized media server to simplify distribution of prerecorded customer prompt updates. Media server functionality can also include a caching engine. The gateways themselves, however, can also do prompt caching when configured for caching. Typical media servers used are Microsoft IIS and Apache, both of which are HTTP-based.
For the most current information on media servers, refer to the latest version of the CVP 3.1 Bill of Materials (BOM), available at
Third Party Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server
Prompts to the caller can utilize prerecorded voice prompts or can be generated with TTS via a voice synthesizing engine (the TTS server). In response to the prompt, the caller can be asked to enter DTMF input or voice input. When the caller provides voice input, the speech recognition engine tries to match that input to a set of acceptable responses.
VoiceXML and the World Wide Web Consortium (W3C) provide a rich feature set to support the ASR grammars. The simplest to implement and support is inline grammars, by which the set of acceptable customer responses is passed to the gateway. Another form is external grammars, by which the ICM passes a pointer to an external grammar source. The CVP VoiceXML Server adds this pointer to the VoiceXML document that it sends to the gateway, which then loads the grammar and uses it to check ASR input from the caller. In this case, the customer is responsible for creating the grammar file. A third type of grammar is the built-in grammar. For a complete explanation of grammar formats, consult the W3C website at
The text for TTS is passed directly from the CVP VoiceXML Server to the gateway. This action is referred to as inline TTS in this document.
The actual speech recognition and speech synthesis are performed by a separate server that interfaces directly to the VXML gateway via the Media Resource Control Protocol (MRCP). Currently, ScanSoft, Nuance, and IBM are the supported ASR/TTS engines. These ASR/TTS engines also support (with limitations) voice recognition and synthesis for multiple languages. For the latest information on supported languages and limitations of these ASR/TTS engines, refer to the following websites:
Note that these are third party products, which the customer or partner must purchase directly with the vendor. The customer also receives technical support directly from the vendor. That does not, however, mean that the vendor's latest software version can be used. CVP is carefully tested with specific versions of each vendor's product, and Cisco TAC will not support CVP customers who use different ASR/TTS versions than those which have been tested with Cisco CVP. It is important to check the CVP 3.1 Bill of Materials (BOM), available at
IPCC Enterprise and Intelligent Contact Management (ICM)
IPCC Enterprise or Intelligent Contact Management (ICM) is a required component when advanced call control (IP switching, transfers to agents, and so forth) is required in CVP. The Hosted versions of these products might also be used for this purpose. ICM provides call-center agent management capabilities and call scripting capabilities. Variable storage capability and database access through the IPCC or ICM application gateways are also powerful tools. A CVP application can take advantage of these capabilities because CVP applications can be called from within a IPCC or ICM script in a non-standalone CVP deployment model.
The CVP Call Server maintains a GED-125 Service Control Interface connection to the IPCC or ICM. GED-125 is a "third-party control" protocol in which a single socket connection is used to control many telephone calls. From the IPCC or ICM's point of view, the CVP Call Server is a voice response unit (VRU) connected to the IPCC or ICM, just as all other GED-125 VRUs are connected. CVP is simply a VRU peripheral to the IPCC or ICM.
Cisco CallManager is an optional component in the CVP solution. Its use in the solution depends on the type of call center being deployed. Pure TDM-based call centers using ACDs, for example, typically do not use Cisco CallManager (except when migrating to IPCC), nor do strictly self-service applications using the CVP Standalone Self Service deployment model.
Cisco CallManager generally is used as part of the Cisco IPCC solution, in which call center agents are part of an IP solution using Cisco IP phones, or when migrating from TDM ACDs.
Only specific versions of Cisco CallManager are compatible with CVP solutions. It is important to check the CVP 3.1 Bill of Materials (BOM), available at