CCVP BK C7053373 00 CVP-SRND
CCVP BK C7053373 00 CVP-SRND
CCVP BK C7053373 00 CVP-SRND
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version
of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http://
www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1110R)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
iii
Contents
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
iv
Contents
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
v
Contents
Server group 53
Server group heartbeat settings 54
Static routes validation 54
Design considerations 55
Diagnostics 55
Unified CVP IVR service 55
Configuration 55
Call disposition 56
VoiceXML gateway 56
Configuration 56
Centralized VoiceXML gateways 57
SIP VoiceXML gateways 57
Distributed VoiceXML gateways 57
SIP VoiceXML gateways 57
Distributed VoiceXML gateways 58
SIP VoiceXML gateways 58
Call disposition 59
High availability hardware configuration on voice gateways 59
Media server 60
Unified CVP microapplication configuration 60
Unified CVP microapplication call dispositions 60
Cisco Unified Call Studio scripting configuration 61
Unified CVP VXML server 61
Configuration 61
Standalone self-service deployments 61
Deployments using ICM 61
Call disposition 62
Automatic Speech Recognition and Text-to-Speech server 62
Configuration 62
Standalone self-service deployments 62
Deployments using ICM 62
Call disposition 63
Cisco Unified Communications Manager 63
Configuration 64
Call disposition 64
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
vi
Contents
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
vii
Contents
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
viii
Contents
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
ix
Contents
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
x
Contents
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
xi
Contents
167
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
xii
Preface
This document provides design considerations and guidelines for deploying enterprise network solutions
that include the Cisco Unified Customer Voice Portal (CVP).
This document builds upon ideas and concepts presented in the latest version of the Cisco Unified Contact
Center Enterprise (Unified CCE) Solution Reference Network Design (SRND), which is available online at
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html
Audience
This design guide is intended for the system architects, designers, engineers, and Cisco channel partners who
want to apply best design practices for the Cisco Unified Customer Voice Portal (CVP).
This document assumes that you are already familiar with basic contact center terms and concepts and with
the information presented in the Cisco Unified CCE SRND. To review those terms and concepts, see the
documentation at the preceding URL.
Revision history
This document may be updated at any time without notice. You can obtain the latest version of this document
online at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_implementation_design_guides_list.html
Visit this Cisco.com website periodically and check for documentation updates by comparing the revision
date (on the front title page) of your copy with the revision date of the online document.
The following table lists the revision history for this document.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
xiii
Preface
Licensing information
February 27, 2008 Initial release of this document for Cisco Unified CVP 7.0.
April 22, 2009 Content was updated for Cisco Unified Communications System Release 7.1.
January 28, 2009 The name “VoiceXML server” was changed to “Unified CVP VXML Server”
throughout this document.
The name “VoiceXML Studio” was changed to “Cisco Unified Call Studio”
throughout this document.
Some content was updated in the chapters on Gateway options, on page 103 and
Call transfer options, on page 135.
April 20, 2010 Initial release of this document for Cisco Unified CVP 8.0.
February 22, 2011 Content was updated to indicate Unified CVP support of ASR 1000 Series and
the limitations thereof.
March 7, 2011 Added ISR support in CVP to 8.5.1 Cisco Unified Customer Voice Portal Design
Guide.
July 6, 2012 Added content on Video in Queue feature and several other topics for 9.0 Cisco
Unified Customer Voice Portal Design Guide.
Updated content related to features not supported for Unified CVP 9.0(1) such
as Content Service Switch (CSS), Cisco Unified Presence Server (CUPS),
Gatekeeper, H.323, protocol, IBM WebSphere, Microsoft Windows Server 2003,
Informix 10.x and Cisco Security Agent
Licensing information
The licensing information for Cisco Unified CVP has been consolidated and moved into the Cisco Customer
Contact Solutions Ordering Guide. The Ordering Guide provides a single, frequently updated source for all
the Unified CVP licensing information. Cisco employees and Partners with a valid login account can access
the Ordering Guide at:
http://www.cisco.com/web/partners/downloads/partner/WWChannels/technology/ipc/downloads/CCBU_
ordering_guide.pdf
If you need licensing information for Unified CVP but you cannot access the Ordering Guide, contact your
local Cisco Systems Engineer (SE) or Partner.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
xiv
Preface
Documentation, support, and security guidelines
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
xv
Preface
Documentation, support, and security guidelines
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
xvi
CHAPTER 1
Unified CVP architecture
Over the past two decades, many customers have invested in TDM-based interactive voice response (IVR)
applications to automate simple customer transactions such as checking account or 401K account inquires.
In addition, many TDM-based IVR platforms were based on proprietary development environments and
hardware platforms, which typically meant restricting the customer's integration options with automatic
speech recognition (ASR) and text-to-speech (TTS) solutions. Over the past few years there has been a
dramatic shift to using VoiceXML (VXML) standards-based technology to support the next generation of
IVR applications.
Because the implementation of Unified CVP is based on VXML, the discussion of Unified CVP begins with
the following overview of VXML as it relates to Unified CVP.
The chapter covers the following major topics:
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
1
Unified CVP architecture
VoiceXML
VoiceXML
Voice eXtensible Markup Language, or VoiceXML , is a markup language similar to HTML, that is used for
developing IVR services and leverages the power of web development and content delivery. VoiceXML was
designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of speech or
dual-tone multifrequency (DTMF) key input, and recording of spoken input. It is a common language for
content providers, tool providers, and platform providers, and it promotes service portability across
implementation platforms.
VoiceXML separates service logic from user interaction and presentation logic in VoiceXML voice web
pages. It also shields application authors from low-level, platform-specific IVR and call control details.
VoiceXML is easy to use for simple interactions, yet it provides language features to support complex IVR
dialogs.
VoiceXML programs are rendered (or executed) by a VoiceXML browser, much like an HTML program is
rendered using an internet browser (such as Internet Explorer). A Cisco Voice Gateway (or router) can provide
the VoiceXML browser function. For small deployments, the Ingress Voice Gateway and VoiceXML Gateway
are typically deployed in the same router. The Cisco IOS VoiceXML Gateway provides both gateway and
VoiceXML browser functions.
In the most simple call processing scenario, a new call arrives and the voice gateway dial peer matches the
call to an available VoiceXML gateway port. The VoiceXML gateway port represents a Voice over IP (VoIP)
endpoint and can be logically thought of as a voice response unit (VRU) port. Upon arrival of the new call,
the VoiceXML gateway (that is, the VRU) sends an HTTP request to a Cisco Unified CVP VXML Server
for instruction. The URL contained in the HTTP request correlates to a specific VoiceXML doc.
In response to the HTTP request, the Unified CVP VXML Server sends the requested, dynamically generated
VoiceXML doc to the VoiceXML gateway (that is, the voice browser) to be rendered. A typical VoiceXML
doc is short and prompt the caller for some input, then includes the results in a new HTTP request that redirects
the caller to another URL and VoiceXML doc. Because a typical call requires numerous prompts and caller
inputs, there are numerous VoiceXML documents that need to be rendered and a large number of possible
paths through these VoiceXML documents.
To logically link the many different VoiceXML documents that may need to be rendered and to greatly simplify
the task of creating VoiceXML documents, a graphical scripting tool is often used to allow the IVR service
developer to easily develop complete IVR services with conditional logic and customer relationship management
(CRM) database integration. Cisco Unified Call Studio is one such scripting tool. The Cisco Unified CVP
VXML Server is capable of executing scripts developed with Cisco Unified Call Studio, and both were
designed to work with Cisco Unified CVP Server, Cisco Voice Gateways, Cisco VoiceXML Gateways, Cisco
Unified Communications Manager, Cisco Unified Contact Center, and Cisco's VoIP-enabled LAN/WAN.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
2
Unified CVP architecture
Cisco Unified Customer Voice Portal
Create your solution using a reliable, redundant, and scalable platform, which enables works with service
providers and large enterprise networks.
• Call switching and routing support
Route and transfer calls between voice gateways and IP endpoints. Voice gateways provide natural
integration of TDM ACDs and PBXs with the PSTN.
After completing the routing or transfer of a call, Unified CVP maintains SIP call control to provide
switching services similar to take-back-and-transfer (TNT) between IP endpoints via the Cisco Unified
Intelligent Contact Management Enterprise (Unified ICME) interface.
Supports call routing services for SIP (RFC 3261) protocol.
• IP-based IVR services
◦In addition to switching and transfer, Unified CVP provides classic prompt-and-collect functions,
such as Press 1 for Sales.
◦Provides sophisticated audio and video self-service applications with CRM database integration
as well as ASR and TTS integrated via Media Resource Control Protocol (MRCP). Examples
include banking and brokerage account handling, and airline reservations.
◦Park calls for personalized prompts or hold music while waiting for a call center agent to become
available. Calls can be prioritized based on their CRM profiles.
◦Take back a transferred call for further IVR treatment or transfer.
• VoiceXML services
Provides a platform for developing powerful, speech-driven interactive applications accessible from any
phone. The VoiceXML platform includes:
◦The Cisco Unified CVP VXML Server, a J2EE- and J2SE-compliant application server that
dynamically drives the caller experience.
◦The Cisco Unified Call Studio, a drag-and-drop graphical user interface (GUI) for the rapid creation
of advanced voice applications.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
3
Unified CVP architecture
Unified CVP product and solution components
◦Use with the Public Switch Telephone Network (PSTN). Calls can be moved onto an IP-based
network for Unified CVP treatment and then moved back out to a PSTN for further call routing
to a call center.
◦Integration with Cisco Unified Contact Center
Unified CVP integrates with Cisco Unified Contact Center via a VRU Peripheral Gateway (PG).
This integration enables Unified CCE to control Unified CVP VoIP switching and IVR services.
It also enables Unified CCE to control the agent selection application and to initiate the Real-Time
Transport Protocol (RTP) stream transfer from the VoiceXML gateway to the selected agent.
Unified CVP integration with Unified CCE requires that the traditional Unified CM PG be used
for Unified CCE integration with Cisco Unified CM.
Unified CCE can be integrated with Unified CVP via the Cisco Unified Intelligent Contact Manager
(ICM) System PG and the parent-child deployment model. This integration method provides callers
with some simple menus and prompts by the parent Unified ICM and Unified CVP, and it
intelligently routes the calls using skill groups to the best Cisco Unified Contact Center Express
or Enterprise child. Queuing control and agent selection are handled by the child contact center
solution. In this model, it is also easy for a TDM automatic call distributor (ACD) to play the role
of a child. All call transfers between Unified CVP and children retains call data, and the ICM
provides enterprise-wide browser-based consolidated reporting.
Unified CVP integration is not directly supported with the Unified CCE System PG (which is also
used by System Unified CCE). The Unified CCE System PG supports only the Cisco Unified IP
IVR. Unified CVP works only with System PG children via the parent-child deployment model.
Unified CVP can also provide IVR services for Unified CCE outbound IVR campaigns and post-call
customer surveys.
The following components of the Unified CVP solution are not part of the Unified CVP product but are still
required for a complete solution:
• Cisco Ingress Voice Gateway, on page 8
• Cisco VoiceXML Gateway, on page 9
• Cisco Egress Gateway, on page 9
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
4
Unified CVP architecture
Product components
The following sections discuss each of these components in more detail. Depending on the particular deployment
model you choose, some of the above components might not be required.
Product components
The following topics describe the Cisco Unified Customer Voice Portal (CVP) product components.
Note Call Server, VXML Server, and Media Server are combined as one component known as CVP Server.
Installing CVP Server installs all three components. In the earlier versions, Call Server, VXML Server,
and Media Server could be installed on different machines. The option to install Call Server, VXML
Server, and Media Server separately is not available.
Call Server
The Call Server component provides the following independent services, which all run on the same
Windows 2008 R2 server:
• SIP service
This service communicates with the Unified CVP solution components such as the SIP Proxy Server,
Ingress Gateway, Unified CM SIP trunks, and SIP phones.
The SIP service implements a Back-to-Back User Agent (B2BUA). This B2BUA accepts SIP invites
from ingress voice gateways and typically directs those new calls to an available VoiceXML gateway
port. After completing call setup, the Unified CVP B2BUA acts as an active intermediary for any
subsequent call control. While the Unified CVP SIP signaling is routed through this service, this service
does not touch the RTP traffic.
Integrated into this B2BUA is the ability to interact with the Cisco Unified ICM via the ICM Service.
This integration provides the ability for the SIP Service to query the Unified ICM for routing instruction
and service control. This integration also allows Unified ICM to initiate subsequent call control to do
things such as requesting that a caller be transferred from queue to an agent or transferred from one
agent to another agent.
• ICM service
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
5
Unified CVP architecture
Product components
This service is responsible for all communication between Unified CVP components and Unified ICM.
It sends and receives messages on behalf of the SIP Service and the IVR Service.
• IVR service
This service creates the VoiceXML pages that implement the Unified CVP Microapplications based on
Run VRU Script instructions received from Unified ICM. The IVR Service functions as the VRU leg
(in Unified ICM Enterprise parlance), and calls must be transferred to it from the SIP Service in order
to execute Microapplications. The VoiceXML pages created by this module are sent to the VoiceXML
gateway to be executed.
VXML Server
The VXML Server executes advanced IVR applications by exchanging VoiceXML pages with the VoiceXML
gateway's built-in voice browser. Like almost all other Unified CVP product components, it runs within a
Java 2 Enterprise Edition (J2EE) application server environment such as Tomcat and many customers add
their own custom-built or off-the-shelf J2EE components to interact with back-end hosts and services. The
VXML Server applications are written using Cisco Unified Call Studio and are deployed to the VXML Server
for execution. The applications are invoked on an as-needed basis by a special Microapplication which must
be executed from within the Unified ICME routing script.
The VXML Server can also be deployed in a standalone configuration that does not include any Unified ICME
components. this configuration model, applications are invoked as a direct result of calls arriving in the
VoiceXML gateway, and a single post-application transfer is allowed.
The VXML Server can execute on Windows 2008 R2 servers. For hardware requirements and details, see
Hardware and System Software Specification for Cisco Unified CVP (formerly called the Bill of Materials),
available at:http://www.cisco.com/en/US/products/sw/custcosw/ps1006/prod_technical_reference_list.html
For more information on the VXML Server, and its latest added features, seeUser Guide for Cisco Unified
CVP VXML Server and Cisco Unified Call Studio.
Media Server
The Media Server component is a simple Web Server, such as Microsoft IIS or Apache, which can provide
prerecorded audio files, external VoiceXML documents, or external ASR grammars to the gateway. Some of
these files can be stored in local flash memory on the gateways. 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.
Note The Media Server component in Unified CVP is installed by default, along with Unified CVP Call Server
and Unified CVP VXML Server.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
6
Unified CVP architecture
Product components
As with ASR/TTS Servers, Media Servers may be deployed simplex, as a redundant pair, or with ACE in a
farm. Note that the VoiceXML Gateway caches .wav files it retrieves from the Media Server. In most
deployments, the Media Server encounters extremely low traffic from Unified CVP.
For the most current information on Media Servers, See the latest version of Hardware and System Software
Specification for Cisco Unified CVP (formerly called the Bill of Materials), available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/prod_technical_reference_list.html
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
7
Unified CVP architecture
Additional solution-related components
and it offers shortcuts into the administration and configuration interfaces of other Unified CVP solution
components. The Operations Console is a required component in all Unified CVP deployments.
The Operations Console must be run on a separate physical machine from other Unified CVP devices.
The Operations Console is, in effect, a dashboard from which an entire Unified CVP deployment can be
managed.
The Operations Console must itself be configured with a map of the deployed solution network. It can then
collect and maintain configuration information from each deployed component. Both the network map and
the configuration information are stored locally on the server, where it can be backed up by off-the-shelf
backup tools. A web-based user interface, the Operations Console, provides the ability to both display and
modify the network map and the stored configuration data and to distribute such modifications to the affected
solution components.
The Operations Console can display two views of configuration parameters for managed components. The
runtime view shows the status of all configuration parameters as the managed components use them. The
configured or offline view shows the status of all configuration parameters that are stored in the Operations
Server database and are deployed to the device when a Save and Deploy option is executed.
The Operations Console Server is not a redundant component. As such, you cannot duplicate the Operations
Console Server within a deployment. Backups the configuration database regularly, or whenever changes are
made.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
8
Unified CVP architecture
Additional solution-related components
Video endpoints
When using the Unified CVP Basic Video Service, the following video endpoints are supported:
• Cisco Unified Video Advantage
• Cisco TelePresence
• Video in Queue (VIQ)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
9
Unified CVP architecture
Additional solution-related components
combines with Unified ICME to form Cisco Unified Contact Center Enterprise (Unified CCE). Unified CVP
interacts with Unified CM primarily as a means for sending PSTN-originated calls to Unified CCE agents.
SIP gateway calls are routed to the available Unified CM SIP.
The following common scenarios require calls to Unified CVP to originate from Unified CM endpoints:
• A typical office worker (not an agent) on an IP phone dials an internal help desk number.
• An agent initiates a consultative transfer that gets routed to a Unified CVP queue point.
• A Cisco Unified Outbound Dialer port transfers a live call to a Unified CVP port for an IVR campaign.
A single Unified CM can originate and receive calls from SIP protocol. PSTN calls that arrived on MGCP
voice gateways registered with Unified CM can only be routed or transferred to Unified CVP via SIP (and
not going through CUBE).
Unified CM is an optional component in the Unified 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
Unified CM (except when migrating to Cisco Unified CCE), nor do strictly self-service applications using
the Unified CVP Standalone self-service deployment model. The Unified CM generally is used as part of the
Cisco Unified CCE 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 Unified CM are compatible with Unified CVP solutions. Unified CVP is supported
with SIP only if Cisco Unified CM 5.0 or later release is used. For full details on version compatibility, see
the latest version of the Hardware and System Software Specification for Cisco Unified CVP (formerly called
the Bill of Materials), available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/prod_technical_reference_list.html
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
10
Unified CVP architecture
Additional solution-related components
The SIP Proxy can be configured with multiple static routes in order to do load balancing and failover with
outbound calls. The static routes can point to an IP address or a regular DNS.
DNS SRV is also supported, but is not qualified for use on the CUSP Server. It is qualified for the devices
that need to reach the CUSP Server, such as Unified CVP, the Ingress Gateway, and Unified CM.
Unified CVP can also be deployed without a SIP Proxy Server depending on the design and complexity of
the solution. In such cases, some of the same functions can be provided by the Unified CVP Server SIP service.
The benefits of using a SIP Proxy Server include:
• Priority and weight routing can be used with the routes for load balancing and failover.
• If a SIP Proxy Server is already used in your SIP network, Unified CVP can be an additional SIP
endpoint—it fits incrementally into the existing SIP network.
If a SIP Proxy Server is not used, then Ingress Gateways and Unified CMs need to point directly to Unified
CVP. In such a deployment:
• Load balancing is done using DNS SRV lookups from Gateway to DNS Server—SIP calls can be
balanced using this mechanism.
• Load balancing of calls outbound from Unified CVP (outbound call leg) can be done using DNS SRV
lookups.
• Failover of SIP rejections (code 503 only) can also be performed if SRV records are configured with
ordered priorities.
DNS server
This optional component may be installed anywhere in the network. Its purpose in general is to resolve
hostnames to IP addresses. The Unified CVP, can make both Type A record lookups and SRV Type record
lookups. If the DNS server is slow to respond, is unavailable or is across the WAN, so it affects the performance.
The DNS Server comes into play during SIP interactions in the following situations:
• When a call arrives at an Ingress Gateway, the dial peer can use DNS to alternate calls between the two
SIP Proxy Servers. The SIP Proxy Servers can also use DNS to distribute incoming calls among multiple
SIP Services. If SIP Proxy Servers are not being used, then the Ingress Gateway can use DNS directly
to distribute inbound calls among multiple SIP Services.
• When the SIP Service is instructed by Unified CCE to transfer the call to the VRU leg, it can use DNS
to alternate such requests between two SIP Proxy Servers. If SIP Proxy Servers are not being used, the
SIP Service can use DNS directly to distribute VRU legs among multiple VoiceXML Gateways.
• When transferring a call to an agent using a SIP Proxy Server, the SIP Proxy cannot use DNS SRV for
outbound calls; it must be configured with multiple static routes in order to do load balancing and failover.
The static routes can point to an IP address or a regular DNS A host record. If SIP Proxy Servers are
not being used, then the SIP Service can use DNS to locate the target agent's IP address.
The use of the DNS Server for SIP routing is entirely optional in Unified CVP. It is not required to have a
dedicated DNS Server, but the existing DNS server needs to handle the additional load of Unified CVP. For
every call destined for Unified CVP that comes into the network, there will be approximately 3 to 4 DNS
lookups. You can determine the number of DNS queries per second by determining the number of calls per
second for the solution, and multiplying that number by 4.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
11
Unified CVP architecture
Additional solution-related components
DNS lookups are needed for DNS SRV queries, not necessarily for A record queries, which could also be
configured locally in the system "etc host" file. Unified CVP Server Groups can alternately be used to avoid
DNS SRV lookups.
See the ACE product documentation and ACE Release notes for more licensing information.
Note There are two features for the VXML Server that assist with load balancing:
• Limiting Load Balancer Involvement
• Enhanced HTTP Probes for Load Balancers
See the configuration options ip_redirect and license_depletion_probe_error in the User Guide for Unified
CVP VXML Server and Cisco Unified Call Studio, available at: http://www.cisco.com/en/US/products/sw/
custcosw/ps1006/products_user_guide_list.html
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
12
Unified CVP architecture
Call flows
Micro-Apps or the Unified CVP VXML Server (VXML Server). MRCP v2 can be used on the VoiceXML
Gateway only with applications that are based on the Unified CVP VXML Server.
For capacity and redundancy reasons, a ACE is usually used to mediate between a VoiceXML Gateway and
a farm of ASR/TTS servers. If ACE is not used, then a VoiceXML Gateway can support a maximum of two
ASR/TTS Servers.
Cisco does not sell or support any ASR/TTS software or servers. Cisco does, however, tests Unified CVP
with Nuance products. A certification process is currently being developed to allow additional vendors to
qualify their products against Unified CVP VoiceXML, and the World Wide Web Consortium (W3C) provides
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,
where Unified ICM passes a pointer to an external grammar source. The Unified CVP VXML Server adds
this pointer to the VoiceXML document that it sends to the VoiceXML 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:
http://www.w3.org/TR/speech-grammar/
The text for TTS is passed directly from the Unified CVP VXML 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 VoiceXML gateway via Media Resource Control Protocol (MRCP). Currently, Nuance is the only
tested ASR/TTS engine. The ASR/TTS engine also supports(with limitations) voice recognition and synthesis
for multiple languages.
For the latest information on Nuance, See http://www.nuance.com
Nuance is a third-party product, which the customer or partner must purchase directly from 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. Unified CVP is carefully tested with specific versions of each
vendor's product, and Cisco Technical Assistance Center (TAC) will not support Unified CVP customers who
use different ASR/TTS versions than those which have been tested. For additional details on supported ASR
and TTS products, See the Hardware and System Software Specification for Cisco Unified CVP (formerly
called the Bill of Materials), available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/prod_technical_reference_list.html
Network monitor
An SNMP management station can be used to monitor the solution deployment status.
Call flows
This section describes the Unified CVP call flows for SIP.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
13
Unified CVP architecture
Typical SIP Unified CVP call flow
The call flow consists of an incoming call requiring initial self-service, followed by queue treatment, and
finally delivery to a Unified ICME agent. The following diagram presents a general SIP-based solution. A
detailed description of the call flow follows the diagram.
During the VRU exchanges, the VoiceXML Gateway interacts with an ASR/TTS Server to play text as speech
or recognize speech as data. It also interacts and with a Media Server (not shown in the diagram, but connected
to the VoiceXML Gateway) to fetch audio files and prompts. These two devices, as well as the Unified CVP
VXML Server, can be located behind a ACE , which offers sophisticated failover and redundancy capability.
(ACEs are optional, though recommended, and are not displayed in the diagram.)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
14
Unified CVP architecture
Design process
During this entire process, the SIP Service, the IVR Service, and the VXML Server send a stream of reporting
events to the Reporting Server (also not shown in the diagram, but connected to the Unified CVP Call Server),
which processes and stores the information in a database for later reporting. All these devices use SNMP
(Simple Network Management Protocol) to support a monitoring console. Cisco Unified Operations Manager
can also be configured to process and forward SNMP events to higher-level monitoring stations such as HP
OpenView.
All components in the solution can be managed by the Unified CVP Operations Console Server. The Operations
Console is not shown in the diagram, but is connected to all the components that it manages. The Operations
Console uses a variety of means to pull together the configuration, management, and monitoring of the entire
solution into a single station, which can be accessed via a standard web browser.
The Unified CVP VXML Server applications are designed and built using Call Studio is used offline tool and
not shown in the diagram.
Design process
When designing a Unified CVP deployment consider the following high-level steps:
1 Choose a call flow model for your functional deployment.
2 Determine where the Unified CVP components are going to be deployed (in the data center or at a branch).
3 Choose the amount of availability and resiliency that is justifiable or required.
4 Size the deployment to provide the justifiable or required grade of service for the initial deployment and
near-term growth.
Note SIP is the only supported call control signaling protocol. Support for H.323 is discontinued.
• Comprehensive — Provides IVR services, queue treatment, and IP switching services. The previously
described typical call flows use this functional deployment model.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
15
Unified CVP architecture
Unified CVP algorithm for routing
• VRU Only — Provides IVR services, queuing treatment, and switching for SS7/IN PSTN endpoints.
This model relies upon the PSTN to transfer calls between call termination endpoints.
This model is useful if you want to:
◦Use Unified CVP to provide Unified ICME with VRU services—including integrated self-service
applications and/or initial prompt and collect.
◦Avoiding using an Unified CVP for switching calls.
◦Use an optional Unified CVP VXML Server.
◦Prompt or collect data using optional ASR/TTS services
For more details and design considerations for each of these functional deployment models, see the chapter
on Functional deployment models, on page 21.
Note The following algorithm only covers calls using the SIP subsystem, which includes audio only and basic
video SIP calls.
The algorithm for creating the destination SIP URI host portion for outbound calls, given the ICM label is as
follows.
1 At the start of the algorithm, the ICM label is provided. It may already have the Location siteID inserted
by the ICM subsystem, or SigDigits may be prepended if used. For network VRU labels, the ICM subsystem
passes in the entire prefix + correlation ID as the label.
2 If SendtoOriginator is matched for the Unified CCE label, the IP or hostname of the caller (ingress gateway)
is used by the Unified CVP algorithm, which returns the SIP URI.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
16
Unified CVP architecture
Distributed network options
The setting for SendtoOriginator only applies to callers who are on IOS gateways (the SIP UserAgent
header is checked), because non-IOS gateways do not have the CVP "bootstrap" service used by the Cisco
VXML gateway.
3 If use outbound proxy is set, then use the host of the proxy - return SIP URI.
4 If local static route is found for the label - return the SIP URI.
Note • To avoid complex Dialed Number strings, do not use the Sigdigits feature if Locations CAC siteIDs
are used.
• An Outbound Proxy FQDN can be specified as a Server Group FQDN (local SRV FQDN). A local
static route destination can also be configured as a Server Group FQDN.
• Ringtone DN (91919191), Recording Server (93939393), and Error message services (92929292)
follow the same algorithm outlined above.
• SendToOriginator can work in conjunction with a REFER label.
• A REFER label can work with the SigDigits setting.
It is also possible to use a combination of these distributed options. For more details and design considerations
for each of these distributed network options, see the chapter on Distributed deployments, on page 33.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
17
Unified CVP architecture
CUBE deployment with SIP trunks
Note ASR 1000 platform is supported for CUBE with CVP Solution, according to the Hardware and System
Software Specification for Cisco Unified Customer Voice Portal. For ASR limitations, see the Cisco
Unified Customer Voice Portal Design Guide.
CUBE on ISR gateways is supported. Also, survivability service is supported on the CUBE gateway.
Design considerations
Please observe the following restrictions when deploying CUBE with SIP Trunks:
• Before 15.2(1)T IOS release, a dial-peer was required to pass the Refer-to header URI through CUBE.
Starting from 15.2(1)T release onwards refer-to-passing command can be used without the need for a
dial-peer.
• CUBE must be configured in media pass through mode in the Unified CVP deployment. Media flow
around mode cannot be used because it is not supported or validated. Only media pass through mode,
the default mode on the dial-peer, is supported for CUBE.
• CUBE does not currently support passing the Refer-To header URI designation from CVP when a
REFER call flow is initiated. It rewrites the destination address based on the dial peer configuration.
Therefore the dial plan must be configured on CVP and CUBE. The note below explains the behavior.
• REFER passthrough cannot be used in conjunction with Survivability. The script does not let REFER
messages be relayed to a SIP service provider regardless of other CUBE configuration.
• REFER consume cannot be used in conjunction with Survivability and Router Requery. Survivability
always accepts the REFER, even if the transfer does not complete. Unified CCE deems the transfer
successful and does not attempt to requery.
• Survivability cannot be used when service provider Alternate Destination Routing (ADR) is used because
the script does not let error messages (ring-no-answer or busy) reach the service provider. Manipulation
in the script does not let error messages (ring-no-answer or busy) reach the service provider. Manipulation
in the Remote-Party-ID header is required instead.
• If GTD is present on the incoming call or if Unified CCE sets a value for the UUI variable, Unified CVP
will send a BYE immediately after outpulsing digits in a DTMF transfer. If a delay is required between
the digits then comma should be used at the end of the label.
• If GTD is not present on the incoming call, Unified CCE does not set a value for the UUI variable and
the service provider does not disconnect a call after receiving digits in a DTMF transfer. Unified CVP
will send a BYE request after the SIP.ExternalTransferWait timer expires. Previous versions of Unified
CVP did not disconnect the call.
• Survivability is required when Courtesy Callback is used.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
18
Unified CVP architecture
High availability options
It is also possible to use a combination of these high availability options to be utilized. For more details and
design considerations for each of these high-availability network options, see the chapter on Unified CVP
design for high availability, on page 41.
Note Unified CVP VXML Server is coresident with Unified CVP Call Server.
Scalability
After choosing the functional model and the distributed and high-availability deployment options, Unified
CVP solution designers must then size their solution and select appropriate hardware. To make Unified CVP
deployments larger, Unified CVP supports multiple gateways, Unified CVP Servers, and Unified CVP
VXML Servers.
To load-balance HTTP requests efficiently to multiple Unified CVP Servers, Unified CVP VXML Servers,
and media stores, you can use the Application Content Engine (ACE), see the Application Control Engine,
on page 12.
For more details on choosing appropriate hardware for your deployment, see the chapter about Sizing, on
page 163.
Virtualization
Unified CVP may be installed and run on Virtual Machines (VMs) provided by VMware software. Running
in a virtual environment has the potential for reducing the number of hardware boxes needed to run a Unified
CVP deployment, to facilitate the deployment's administration, and to leverage your ESX (tm) infrastructure.
The following Unified CVP deployments are supported using VMware VMs:
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
19
Unified CVP architecture
Quality of Service
• All SIP call flows, deployments, and features that could be installed on a physical server
• Mixed environments of physical and virtual servers
Note Deployments assume that you do not oversubscribe or overcommit the CPU and memory resources beyond
what is available on the host.
For specific information about virtualization with Unified CVP, see the http://www.cisco.com/go/uc-virtualized.
Quality of Service
Quality of Service (QOS) is the measure of transmission quality and service availability of a network. Unified
CVP implements Layer 3 QoS defaults on all relevant network path. The Unified CVP provides a management
interface via the Unified CVP Operations Console Server to modify QoS settings at each end of specifically
designated data paths.
Note For instructions on configuring QoS for Unified CVP, see the Operations Console online help.
For QoS design information, see the Enterprise QoS in the Solution Reference Network Design Guide.
Licensing information
For Unified CVP licensing information refer to the Cisco Customer Contact Solutions Ordering Guide. This
guide is a frequently updated source for all Unified CVP licensing information.
Cisco employees and partners with a valid login account can access the ordering guide at:
http://www.cisco.com/web/partners/downloads/partner/WWChannels/technology/ipc/downloads/CCBU_
ordering_guide.pdf
If you need licensing information for Unified CVP but you cannot access the Ordering Guide, contact your
local Cisco Systems Engineer (SE) or Partner.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
20
CHAPTER 2
Functional deployment models
For each deployment model, this chapter provides a short discussion of the typical customer requirements,
a list of required and optional components, and a step-by-step call flow.
The functional deployment models presented in this chapter assume all components are located in a single
site, and no discussion of failover is covered. For information on Distributed deployment scenarios where
components are separated across a WAN link, see the Distributed deployments, on page 33. For
High-availability deployment options, see the Unified CVP design for high availability, on page 41.
This chapter covers the following functional deployment models for Unified CVP:
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
21
Functional deployment models
Protocol-level call flow
Callers can also access Unified CVP from VoIP endpoints. Figure 1: Functional Deployment Model for a
Unified CVP VXML Server (Standalone), on page 22 illustrates this model.
Figure 1: Functional Deployment Model for a Unified CVP VXML Server (Standalone)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
22
Functional deployment models
Transfers and subsequent call control
or it streams media from a text-to-speech (TTS) server. Caller input can be captured either by DTMF
detection on the Ingress Gateway or via DTMF/speech recognition on an ASR server.
6 As defined in the VoiceXML document, the VoiceXML gateway submits an HTTP request containing
the results of the caller input to the Unified CVP VXML Server. The Unified CVP VXML Server again
runs the application specified in the HTTP URL and returns a dynamically generated VoiceXML document
to the VoiceXML gateway. The dialog continues by repeating steps 5 and 6.
7 The IVR dialog ends when either the caller hangs up, the application releases, or the application initiates
a transfer.
The VoiceXML transfers are invoked using the transfer element from Cisco Unified Call Studio. Release
Trunk Transfers are invoked by providing specially formatted return values in subdialog_return element.
Agent transfers from agent phones are not supported in standalone deployments. Agent transfers from an
agent's IP phone must be controlled by a Unified CCE supported with Unified CVP comprehensive deployments.
In the case of a VoiceXML Bridged Transfer, the outcome of the transferred call leg (transfer failed, transfer
call leg released, and so forth) is submitted back to the Unified CVP VXML Server. The VoiceXML session
is then resumed, and further iterations of IVR call treatment and transfers can be performed. During the period
of time that the call is transferred, a Unified CVP VXML Server port license is utilized with a bridged transfer.
In the case of a VoiceXML 2.0 Blind Transfer, the call remains connected through the ingress voice gateway,
but Unified CVP does not have any method to provide any subsequent call control.
In the case of a Release Trunk Transfer, the ingress voice gateway port is released and no subsequent call
control is possible.
For more details on transfers, see the chapter on Call transfer options, on page 135.
Call director
This functional deployment model provides organizations with a mechanism to route and transfer calls across
a VoIP network. The most common usage scenario for this model is for organizations with multiple TDM
ACD and TDM IVR locations that are integrated with Unified ICM via an ACD or IVR PG. The organization
wants to use the Unified ICM to route and transfer calls intelligently across these locations without having to
utilize PSTN pre-routing or release trunk transfer services. In this functional deployment model, Unified CVP
and Unified ICM can also pass call data between these ACD and IVR locations. In this deployment model,
Unified ICM can also provide beginning-to-end reporting for all calls. Although customers can have a
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
23
Functional deployment models
SIP protocol-level call flow
Unified CVP Reporting Server in this deployment model, it is optional because there is very little call
information stored in the Unified CVP reporting database.
This functional deployment model is often the initial step in the migration from a TDM-based contact center
to a VoIP-based contact center. When the organization is ready to implement CVP-based IVR services and
Unified CCE, the organization can migrate their Unified CVP deployment to the comprehensive functional
deployment model.
Callers can access Unified CVP via either local, long distance, or toll-free numbers terminating at Unified
CVP ingress voice gateways. Callers can also access Unified CVP from VoIP endpoints.
This model requires the following components:
• Ingress voice gateway
• Egress voice gateway
• Unified CVP Server
• Unified CVP Operations Console Server
• Cisco Unified ICM Enterprise
• SIP Proxy Server (for SIP deployments)
VoIP-based Transfer
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
24
Functional deployment models
Transfers and subsequent call control
1 Regardless of whether the call was initially routed to a TDM IVR or ACD location, the caller can request
to be transferred to another location. When this occurs, the TDM IVR or ACD sends a post-route request
with call data (with its PG) to Unified ICM.
2 When Unified ICM receives this post-route request, it runs a routing script based upon the transfer dialed
number and other criteria. The Unified ICM routing script selects a new target for the call and then signals
to the Unified CVP Server SIP Service to release the call leg to the originally selected termination and to
extend the call to a new termination.
3 When the call arrives at the new termination, the termination equipment sends a request to its PG for
routing instructions. This step resolves a translation route that was allocated for this call to this new
termination location, and it allows any call data from the previous location (IVR port or agent) to be passed
to the new termination. Calls can continue to be transferred between locations using this same VoIP-based
transfer call flow.
Comprehensive
This functional deployment model provides organizations with a mechanism to route and transfer calls across
a VoIP network, to offer IVR services, and to queue calls before being routed to a selected agent. The most
common usage scenario for this functional deployment model is for organizations wanting a pure IP-based
contact center. Callers are provided IVR services initially and then, upon request, are provided queue treatment
and are transferred to a selected Unified CCE agent. Upon request, callers can also be transferred between
Unified CCE agents. In this functional deployment model, Unified CVP and Unified ICM can also pass call
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
25
Functional deployment models
Comprehensive
data between these endpoints and provide reporting for all calls. Figure 2: Comprehensive Functional
Deployment Model, on page 26 illustrates this model.
This functional deployment model provides all the capabilities of the Standalone Unified CVP VXML Server
and Call Director functional deployment models, plus the ability to route and queue calls to Unified CCE
agents.
Callers can access Unified CVP via either local, long distance, or toll-free numbers terminating at the Unified
CVP ingress voice gateways. Callers can also access Unified CVP from VoIP endpoints.
Comprehensive deployments can utilize SIP.
This model requires the following components:
• Ingress voice gateway
• VoiceXML gateway (Can be co-resident with the ingress gateway)
• Unified CVP Server
• Unified CVP Operations Console Server
• Cisco Unified ICM Enterprise
• SIP Proxy Server (for SIP deployments)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
26
Functional deployment models
SIP protocol-level call flow
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
27
Functional deployment models
Transfers and subsequent call control
2 The VoiceXML gateway sends an HTTP new call request to the IVR Service, which forwards that request
to Unified ICM in order to allow the routing script to be re-entered at the exit of the Send to VRU node.
The Unified ICM sends Run VRU Script messages to the IVR Service to allow queue treatment to be
provided to the caller while waiting for a second agent.
3 When a second Unified CCE agent becomes available, Unified ICM requests the Unified CVP Server IVR
Service to transfer the call to the selected agent.
4 The IVR Service requests the SIP Service to transfer the caller to the dialed number of the selected agent.
The SIP Service sends a SIP invite message to the SIP Proxy Server, which finds the Unified CM SIP
Trunk IP address associated with the second agent DN, and then forwards the SIP Invite message to
Unified CM.
5 Unified CM accepts the incoming SIP trunk call and routes it to the second agent.
Note Due to a limitation in earlier versions of Cisco IOS, Cisco recommended configuring an MTP because it
was required for call flows in which the first agent consulted and was queued and then completed the
transfer before connecting to a second agent. This limitation no longer applies, and MTP configuration is
not required on SIP trunks if you are running the latest versions of Cisco IOS. Consult the Cisco
Unified Customer Voice Portal Release Notes for details about this limitation. Also note that there are
certain situations where MTP usage can still be allocated dynamically (for example, when there is a SIP
DTMF capability mismatch).
VRU only
This functional deployment model provides self-service applications and queueing treatment for organizations
that are utilizing advanced PSTN switching services that are controlled using a Cisco Unified ICM PSTN
Network Interface Controller (NIC). Two Unified ICM PSTN NICs allow subsequent call control of calls in
the PSTN. They are the SS7 NIC and the Carrier Routing Service Protocol (CRSP) NIC. These NICs go
beyond allowing Unified ICM to pre-route calls intelligently to Unified ICM peripherals (such as ACDs and
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
28
Functional deployment models
VRU only
IVRs); they also allow Unified ICM to invoke mid-call transfers in the PSTN. Figure 3: Functional Deployment
Model for VRU Only, on page 29 illustrates this model.
A typical call in this model would be pre-routed by Unified ICM to a Unified CVP Ingress Voice Gateway
for call treatment and queueing. When an agent becomes available, Unified ICM instructs the PSTN to transfer
the call to that agent. The agents can be Cisco Unified Contact Center Enterprise agents, Cisco Unified Contact
Center Express agents, or traditional ACD agents. If necessary, Unified ICM can request the PSTN (using
the NIC) to transfer the call again and again, just as Unified ICM can request Unified CVP to transfer the call
again and again. In this functional deployment model, the Unified CVP Ingress Voice Gateway is just a Unified
ICM-managed PSTN termination point that is capable of providing VRU services using a VoiceXML gateway,
the Unified CVP Server IVR Service, the Unified CVP Server ICM Service, and Unified ICM. In this functional
deployment model, the Unified CVP Server SIP Service is not used for call control. All call control and
switching is controlled by Unified ICM and the PSTN. In this functional deployment model, Unified ICM
can pass call data between these termination points (for a screen pop or other intelligent treatment) and provide
reporting for all calls.
This model requires the following components:
• Ingress voice gateway
• VoiceXML gateway (Can be co-resident with the ingress gateway)
• Unified CVP Server running IVR Service and ICM Service
• Unified CVP Operations Console Server
• Cisco Unified ICM Enterprise and NIC (SS7 or CRSP)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
29
Functional deployment models
Protocol-level call flow
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
30
Functional deployment models
Basic Video
1 If the caller requests to be transferred to a second agent, then the first agent initiates a transfer from their
agent desktop application (Unified CCE or TDM). This action generates a route request from the PG to
the Unified ICM central controller.
2 Unified ICM executes a routing script. If the caller needs to be placed back into queue on Unified CVP
or to another ACD location (TDM or IP), then Unified ICM sends a connect message to the PSTN using
the PSTN NIC to have the call transferred. If the caller needs to be transferred to an agent on the same
Unified CM peripheral, then Unified ICM instructs Unified CM (using the Unified CM PG) to transfer
the call.
Basic Video
The Basic Video service is simply an extension of the existing Comprehensive deployment model, but it
allows for a video caller to interact with a video agent. IVR and queuing are audio-only.
The following video endpoints are supported when using the Unified CVP Basic Video:
• Cisco Unified Video Advantage
• Cisco TelePresence
Because the Basic Video is simply an extension of the SIP-based Comprehensive deployment model, the
required components and SIP protocol-level call flow details are identical.
Video in Queue
Video in Queue (VIQ) is an optional Basic Video feature in Unified CVP. It allows the caller to interact
through high-definition video prompt or navigate a video menu using DTMF keys.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
31
Functional deployment models
Video in Queue
The following figure display the topology and call flow for Basic Video.
Figure 4: Basic in Queue
The Unified CVP Studio VideoConnect element allows the specific video prompt to be played for video
endpoints. It also allows the DTMF input during video prompt playback to be collected and integrated with
the Unified Call Studio or Unified CCE scripting environment.
See the Configuration Guide for Cisco Unified Customer Voice Portal for specific CUBE/ VXML gateway
configuration information for VideoConnect.
See the Element Specifications for Cisco Unified CVP VXML Server and Cisco Unified Call Studio for using
the VideoConnect element.
See sections Incoming Call Configuration and Media File Management of MediaSense User Guide to use
media files.
Note When configuring the Video in queue for CVP, it is required to set the MediaSense Incoming Call
Configuration > Action to "Play Once".
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
32
CHAPTER 3
Distributed deployments
In a distributed deployment, the ingress gateways are geographically separated from the Unified CVP Call
Server. This chapter discusses how these types of deployments are designed as well as how to handle call
survivability and call admission control.
The chapter covers the following major topics:
Distributed gateways
Unified CVP can use several different types of gateways depending on the deployment model. This section
discusses each type of gateway and how a distributed deployment can affect them.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
33
Distributed deployments
Ingress or VoiceXML gateway at branch
VoiceXML and voice gateway functions reside at the same branch location but on separate devices, special
attention has to be paid to the dial plan to ensure that the VRU leg is sent to the local VoiceXML resource
because the Unified CVP Call Server settransferlabel mechanism applies only to co-resident VoiceXML
and voice gateway configurations.
When the ingress gateway and VoiceXML gateway at a branch do not reside on the same gateway, there are
two ways to ensure that the calls are handled within the branch and not sent across the WAN to a different
VoiceXML gateway:
• Configure Unified ICM with multiple customers, one per location.
This option relies on the Unified ICM configuration to differentiate between calls based on the Dialed
Number. The Dialed Number is associated with a customer representing the branch site. When a
NetworkVRU is needed, the NetworkVRU associated with the customer in Unified ICM is selected and
the caller is sent to that NetworkVRU. This allows you to have multiple NetworkVRUs, each with a
unique label. The disadvantage of this method is that each NetworkVRU requires its own VRU scripts
in Unified ICM. The Unified ICM configuration becomes a significant amount of work when you make
a change to each Network VRU script.
• Configure Unified CVP using the SigDigits feature.
The SigDigits feature in Unified CVP allows you to use the dial plan on the SIP Proxy to route calls to
the correct site. When the call arrives at an ingress gateway, the gateway prepends digits before sending
the call to Unified CVP. Those prepended digits are unique to that site for a dial-plan.
When the call arrives at Unified CVP, Unified CVP strips the prepended digits and stores them in
memory, resulting in the original DID on which the call arrived. Unified CVP then notifies Unified ICM
of the call arrival using the original DID and matches a Dialed Number in Unified ICM.
When Unified ICM returns a label to Unified CVP in order to transfer the call to a VoiceXML gateway
for IVR treatment or to transfer the call to an agent phone, Unified CVP prepends the digits that it stored
in memory before initiating the transfer. The dial plan in the SIP Proxy must be configured with the
prepended digits in such a way to ensure that calls with a certain prepended digit string are sent to specific
VoiceXML gateways or egress gateways.
It is important to remember that when the Voice XML gateway receives the call, the CVP bootstrap
service is configured to strip the digits again, so that when the IVR leg of the call is set up, the original
DN is used on the incoming Voiced XML request. Note that digits can be prepended to translation route
DNs, and that the egress or receiving component (such as Unified CM) may need to strip digits to see
the original DN.
The term SigDigits is used to describe this feature because the command in Unified CVP to turn on the
feature and specify how many significant digits should be stripped is it is called Prepend Digits for SIP
in the Operations Console.
This method is preferred because it involves the least amount of Unified ICM configuration overhead;
a single NetworkVRU and single set of VRU scripts and Unified ICM routing scripts is all that is needed.
This allows all of the Unified CVP servers and VoiceXML gateways to function as a single network-wide
virtual IVR from the perspective of Unified ICM.
The SigDigits feature can also be used to solve multi-cluster call admission control problems. (See Call
admission control considerations, on page 37, for more information.)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
34
Distributed deployments
Co-located Unified CVP VXML servers and gateways
Disadvantages of co-location:
• Extra Unified CVP VXML Servers are required when using replicated branch offices.
• There is additional overhead when deploying applications to multiple Unified CVP VXML Servers.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
35
Distributed deployments
Multicast Music-on-Hold (MOH)
Use the latter method when survivable remote site telephony (SRST) is configured on the gateway. This
method enables the deployment to use MOH locally and avoid MOH streaming over the WAN link.
Design considerations
The following considerations apply when using Multicast MOH:
• Do not set
modem passthrough nse codec g711ulaw
globally, or on a dial peer on the ingress or egress gateway. This setting may cause Unified CM to stop
the MOH after a timeout period of 10-12 seconds.
• Do not set media inactivity on the ingress gateway, because multicast MOH does not send RTP or RTCP,
so the call may get disconnected due to media inactivity configuration. The setting media inactivity
criteria does not support multicast traffic.
• SIP-based Multicast MOH is not supported on the 5400 platform since ccm-manager-based MOH
subsystems are not supported on 5400 platform. This limitation also includes the ability of a TDM caller
to hear multicast packets broadcasted from the Unified CM MOH server.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
36
Distributed deployments
Call admission control considerations
Telephony (SRST). For further details on SRST, see the latest version of the Cisco Unified Communications
SRND Based on Cisco Unified Communications Manager, available at:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
For Unified CVP calls, survivability is handled by a combination of services from a TCL script (survivability.tcl)
and SRST functions. The survivability TCL script is used to monitor the SIP connection for all calls that
ingress through the remote gateway. If a signaling failure occurs, the TCL script takes control of the call and
redirects it to a configurable destination. The destination choices for the TCL script are configured as parameters
in the Cisco IOS Gateway configuration.
Alternative destinations for this transfer could be another IP destination (including the SRST call agent at the
remote site), *8 TNT, or hookflash. With transfers to the SRST call agent at the remote site, the most common
target is an SRST alias or a Basic ACD hunt group. For further information about these SRST functions, see
the Cisco Unified Communications SRND based on Cisco Unified Communications Manager.
Voice Mail and Recording Servers do not send Real-Time Control Protocol (RTCP) packets in reverse direction
toward the caller (TDM Voice Gateway), and this could falsely trigger the media-inactivity timer of the
survivability script. It is important to apply the survivability.tcl script carefully to the dial-peers because a
call might drop if it goes to the voice mail or to a recording element. One method is to use a separate dial-peer
for voice mail or recording calls, and do not associate the Unified CVP survivability script for those dial-peers.
Another method is to disable the media-inactivity on the survivability script associated with the voice mail
or recording dial-peers.
For further information on configuration and application of these transfer methods, see the latest version of
Configuration Guide for Cisco Unified Customer Voice Portal, available at http://www.cisco.com/en/US/
products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html.
Also refer to CUBE deployment with SIP trunks, on page 18.
Note To take advantage of alternate routing upon signaling failures, you must use the survivability service on
all gateways pointing to Unified CVP. Always use this service, unless you have a specific implementation
that prevents using it.
Router requery is not supported when using SIP REFER with Unified CVP Comprehensive Call Flow
when the survivability service is handling the REFER message from Unified CVP. Router requery with
REFER can be supported in other call flows when IOS is handling the REFER without the survivability
service, or else Unified CM is handling the REFER. For third-party SIP trunks, the support of router
requery with REFER is dependent on their implementation and support for SIP REFER.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
37
Distributed deployments
Unified CM Call admission control
There are two call admission control mechanisms that can be used in a Unified CVP environment: Unified CM
Locations, and Unified CM RSVP Agent. In a single-site deployment, call admission control is not necessary.
The Unified CM performs call admission by assigning devices to certain locations and keeping track of how
many calls are active between these locations. Because Unified CM knows how many calls are active and
what codec is in use for each call, it is able to calculate how much bandwidth is in use and to limit the number
of calls allowed.
A thorough conceptual understanding of call admission control mechanisms is important. These mechanisms
are explained in the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager,
available at:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
RSVP
RSVP is a protocol used for call admission control, and it is used by the routers in the network to reserve
bandwidth for calls. RSVP is not qualified for call control signaling via the Unified CVP Call Server in SIP.
The recommended solution for CAC is to employ Locations configuration on Unified CVP and in Unified
CM.
For more information on RSVP, see the latest version of the Cisco Unified Communications SRND Based on
Cisco Unified Communications Manager, available at:
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
38
Distributed deployments
Unified CM Call admission control
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
39
Distributed deployments
Unified CM Call admission control
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
40
CHAPTER 4
Unified CVP design for high availability
This chapter describes guidelines and best practices for designing a high-availability Unified CVP system.
This chapter covers the following topics:
• Overview, page 41
• Layer 2 switch, page 43
• Originating gateway, page 43
• SIP proxy, page 45
• Unified CVP SIP service, page 50
• Server group, page 53
• Unified CVP IVR service, page 55
• VoiceXML gateway, page 56
• Media server, page 60
• Unified CVP VXML server, page 61
• Automatic Speech Recognition and Text-to-Speech server, page 62
• Cisco Unified Communications Manager, page 63
• Intelligent Contact Management, page 64
Overview
A high-availability design provides the highest level of failure protection. Your solution may vary depending
upon business needs such as:
• Tolerance for call failure
• Budget
• Topological considerations
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
41
Unified CVP design for high availability
Overview
Unified CVP can be deployed in many configurations that use numerous hardware and software components.
Each solution must be designed in such a way that a failure impacts the fewest resources in the call center.
The type and number of resources impacted depends on how stringent the business requirements are and
which design characteristics you choose for the various Unified CVP components. A good Unified CVP
design is tolerant of most failures but sometimes not all failures can be made transparent to the caller.
Unified CVP is a sophisticated solution designed for mission-critical call centers. The success of any Unified
CVP deployment requires a team with experience in data and voice internet working, system administration,
and Unified CVP application configuration.
Before implementing Unified CVP, use careful planning to avoid costly upgrades or maintenance later in the
deployment cycle. Always design for the worst failure scenario, with future scalability in mind for all Unified
CVP sites.
In summary, plan ahead and follow all the design guidelines and recommendations presented in this guide
and in the latest version of the Cisco Unified Communications Solution Reference Network Design (SRND)
Based on Cisco Unified Communications Manager, available at:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
For assistance in planning and designing your Unified CVP solution, consult your Cisco or certified Partner
Systems Engineer (SE).
A Note About the Unified CVP Call Server Component
The other chapters of this document treat the Unified CVP Call Server as a single component because those
chapters have no need to examine it in any more depth than that. When discussing Unified CVP high availability
however, it is important to understand that there are actually several parts to this component:
• SIP Service — Responsible for processing incoming and outgoing calls via SIP.
• ICM Service — Responsible for the interface to ICM. The ICM Service communicates with the VRU
PG using GED-125 to provide ICM with IVR control. The ICM Service was part of the Application
Server in previous releases of Unified CVP, but now it is a separate component.
• IVR Service — Responsible for the conversion of Unified CVP Microapplications to VoiceXML pages,
and vice versa. The IVR Service was known as the Application Server in previous Unified CVP versions.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
42
Unified CVP design for high availability
Layer 2 switch
Layer 2 switch
The following illustration shows a high-level layout for a fault-tolerant Unified CVP system. Each component
in the Unified CVP site is duplicated for redundancy. The quantity of each of these components varies based
on the expected busy hour call attempts (BHCA) for a particular deployment.
Figure 5: Redundant Unified CVP System
In this illustration, two switches provide the first level of network redundancy for the Unified CVP Servers:
• If one switch fails, only a subset of the components becomes inaccessible. The components connected
to the remaining switch can still be accessed for call processing.
• If a ACE is used, its redundant partner must reside on the same VLAN in order to send keep-alive
messages to each other via Virtual Router Redundancy Protocol (VRRP), a protocol similar to Hot
Standby Router Protocol (HSRP). If one of the switches fails, the other ACE is still functional.
For more information on data center network design, See the Data Center documentation available at
http://www.cisco.com/go/designzone
Note NIC teaming is not currently supported in the Unified CVP solution.
Cisco recommends that the NIC card and ethernet switch be set to 100 MB full duplex for 10/100 links,
or set to auto-negotiate for gigabit links.
Originating gateway
The function of the originating gateway in a Unified CVP solution is to accept calls from the PSTN and direct
them to Unified CVP for call routing and IVR treatment.
This section covers the following topics:
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
43
Unified CVP design for high availability
Configuration
• Configuration, on page 44
• Call disposition, on page 44
Configuration
For the most current information on how to provide redundancy and reliability for originating gateways and
T1/E1 lines, see the latest version of the Cisco Unified Customer Voice Portal Design Guide , available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html
In addition, consider the following issues when designing gateways for high availability in a Unified CVP
solution:
• When used in ICM-integrated models, the originating gateway communicates with Unified CVP using
SIP. Unlike MGCP, and SIP do not have redundancy features built into the protocol. Instead, SIP relies
on the gateways and call processing components for redundancy. The following configurations allow
call signaling to operate independent of the physical interfaces. In this way, if one interface fails, the
other interface can handle the traffic.
◦With dial-peer level bind , it is possible to setup different bind based on each dial-peers. The
dial-peer bind eliminates the need to have single interface reachable from all subnets. It helps in
segregating the traffic from different networks (example, SIP trunk from SP side and SIP trunk
towards CUCM/CVP). The dial-peer level binding is illustrated in the following configuration
example:
Using voice-class sip bind
dial-peer voice 1 voip
voice-class sip bind control source-interface GigabitEthernet0/0
◦For other gateways, global binding should be used. Each gateway interface should be connected
to a different physical switch to provide redundancy in the event that one switch or interface fails.
Each interface on the gateway is configured with an IP address on a different subnet. The IP Routers
for the network is configured with redundant routes to the Loopback address through the use of
static routes or a routing protocol. If a routing protocol is used to review the number of routes
being exchanged with the gateway, and consider using filters to limit the routing updates so that
the gateway is only advertising the loopback address and not receiving routes. It is best to bind the
SIP signaling to the virtual loopback interface, as illustrated in the following configuration example:
SIP
voice service voip
sip
bind control source-interface Loopback0
bind media source-interface Loopback0
Call disposition
If the originating gateway fails, the following conditions apply to call disposition:
• Calls in progress are dropped. There is nothing that can be done to preserve these calls because the PSTN
switch has lost the D-channel to all T1/E1 trunks on this gateway.
• New calls are directed by the PSTN carrier to a T1/E1 at an alternate gateway, provided the PSTN switch
has its trunks and dial plan configured to do so.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
44
Unified CVP design for high availability
SIP proxy
SIP proxy
The SIP proxy server provides dial plan resolution on behalf of SIP endpoints, allowing dial plan information
to be configured in a central place instead of statically on each SIP device. A SIP proxy server is not required
in a Unified CVP solution, but it is used in most solutions because of the benefits of centralized configuration
and maintenance. Multiple SIP proxy servers can be deployed in the network to provide load balancing,
redundancy, and regional SIP call routing services. In a Unified CVP solution, the choices for SIP call routing
are:
• SIP proxy server
◦Advantages:
Weighted load balancing and redundancy.
Centralized dial-plan configuration.
SIP proxy may already exist or be used for other applications for dial-plan resolution or intercluster
call routing.
◦Disadvantages:
Additional server or hardware required for SIP proxy if not already deployed.
• Static routes using Server Groups (DNS SRV records) on a DNS Server
◦Advantages:
Weighted load balancing and redundancy.
◦Disadvantages:
Unable to use of an existing server depends on the location of the DNS server..
The ability to share or delegate DNS server administration rights may be limited in some
organizations.
Dial-plan configuration needs to be configured on each device individually (Unified CM, Unified
CVP, and gateways).
DNS SRV lookup is performed for each and every call by Unified CVP. If the DNS server is slow
to respond, is unavailable, is across the WAN, so the performance is affected.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
45
Unified CVP design for high availability
Cisco Unified SIP Proxy (CUSP) support
Note The options for static routes using SRV with a DNS Server, or using Server Groups, can introduce some
unexpected, long delays during failover and load balancing with UDP transport on the Unified CVP Call
Server when the primary destination is shut down or is off the network. With UDP, when a hostname has
multiple elements with different priorities in the Server Group (srv.xml), the Unified CVP does two
attempts for each element, with 500 msec between each attempt. If the first element does not answer, it
tries the next element one second later. This delay occurs is on every call during failure, depending on
load balancing, and is in accordance with section 17.1.1.1 of RFC 3261 regarding the T1 timer. If server
group heartbeats are turned on, then the delay may only be incurred once, or not at all, depending on the
status of the element. This apply to TCP as well.
Each device in the Unified CVP solution can use the above methods for determining where to send a call.
The Unified CVP Call Server interface to the SIP network is through the Unified CVP SIP Service, which is
discussed in the section on Unified CVP SIP service, on page 50.
Note For information on CUSP version numbers, see Hardware and System Software
Specification for Cisco Unified Customer Voice Portal at http://www.cisco.com/en/US/
products/sw/custcosw/ps1006/prod_technical_reference_list.html.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
46
Unified CVP design for high availability
Cisco Unified SIP Proxy (CUSP) support
Example of option A
In this example, ISR1 is on the east coast and ISR2 is on the west coast. The TDM gateways will use the
closest ISR, and only cross the WAN when needing to failover to the secondary priority blades.
The SRV records look like this:
east-coast.proxy.atmycompany.com
blade 10.10.10.10 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 2 weight 10 (this blade is in ISR2 on west coast)
west-coast.proxy.atmycompany.com
blade 10.10.10.20 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.10 priority 2 weight 10 (this blade is in ISR1 on east coast)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
47
Unified CVP design for high availability
Cisco Unified SIP Proxy (CUSP) support
Example of option B
With this example ISR1 is on the east coast and ISR2 is on the west coast. The TDM gateways will use the
closest ISR, and only cross the WAN when needing to failover to the secondary priority blades. The SRV
records look like this:
east-coast.proxy.atmycompany.com
blade 10.10.10.10 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.30 priority 2 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.40 priority 2 weight 10 (this blade is in ISR2 on west coast)
west-coast.proxy.atmycompany.com
blade 10.10.10.30 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.40 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.10 priority 2 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 2 weight 10 (this blade is in ISR1 on east coast)
When a consult with CVP queuing occurs, an additional 4 SIP transactions will be incurred for the session,
effectively doubling the number of calls.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
48
Unified CVP design for high availability
Configuration
Configuration
The following sections discuss configuration of the SIP Proxy Server and Cisco IOS Gateways using SIP. It
is not meant to be an exhaustive list of configuration options but only highlights certain configuration concepts.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
49
Unified CVP design for high availability
Unified CVP SIP service
redundancy without a SIP Proxy Server. The following example shows a Cisco IOS gateway configuration
with multiple dial-peers so that the calls are load-balanced across three Unified CVP Call Servers.
dial-peer voice 1001 voip
session target ipv4:10.4.33.131
preference 1
...
dial-peer voice 1002 voip
session target ipv4:10.4.33.132
preference 1
...
dial-peer voice 1003 voip
session target ipv4:10.4.33.133
preference 1
...
DNS SRV records allow an administrator to configure redundancy and load balancing with finer granularity
than with DNS round-robin redundancy and load balancing. A DNS SRV record allows you to define which
hosts should be used for a particular service (the service in this case is SIP), and it allows you to define the
load-balancing characteristics among those hosts. In the following example, the redundancy provided by the
three dial-peers configured above is replaced with a single dial-peer using a DNS SRV record. Note that a
DNS server is required in order to do the DNS lookups.
ip name-server 10.4.33.200
dial-peer voice 1000 voip
session target dns:cvp.cisco.com
With Cisco IOS gateways, it is possible to define DNS SRV records statically, similar to static host records.
This capability allows you to simplify dial-peer configuration while also providing DNS SRV load balancing
and redundancy. The downside of this method is that, if the SRV record needs to be changed, it must be
changed on each gateway instead of on a centralized DNS server. The following example shows the
configuration of static SRV records for SIP services handled by cvp.cisco.com, and the SIP SRV records for
cvp.cisco.com are configured to load-balance across three servers.
ip host cvp4cc2.cisco.com 10.4.33.132
ip host cvp4cc3.cisco.com 10.4.33.133
ip host cvp4cc1.cisco.com 10.4.33.131
(SRV records for SIP/TCP)
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com
(SRV records for SIP/UDP)
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.com
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
50
Unified CVP design for high availability
Configuration
Configuration
If only a single SIP Proxy server is needed for outbound call routing from the Call Server, choose the SIP
Proxy configuration when configuring the SIP Service. In the Unified CVP Operations Console Server,
configure the following:
• Add a SIP Proxy Server and specify the IP address of the server.
Under the Call Server SIP Service settings, configure the following:
• Enable Outbound Proxy = True
• Use DNS SRV type query = False
• Outbound Proxy Host = SIP Proxy Server configured above
When using multiple SIP Proxy servers for outbound redundancy from the Call Server, configure the SIP
Proxy with a DNS name and configure DNS SRV records in order to reach the SIP Proxy Servers. The DNS
SRV records can exist on an external DNS Server, or they can be configured in a local DNS SRV record on
each CVP server. In the OAMP Console, configure the following:
• Add a SIP proxy server and specify DNS name of the server.
To configure the Local DNS SRV record on each server, under the SIP service configuration, check Resolve
SRV records locally.
To use a Server group for redundant proxy servers:
1 Select resolve SRV records locally and type in the name of the server group for the outbound proxy
domain name.
2 Under System > Server Groups, create a new server group with two proxy servers that have priority 1
and 2.
3 Deploy the server group configuration to the Call Server.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
51
Unified CVP design for high availability
Call disposition
The configuration discussed in this section protects against all of these situations. However, if one of the
following two scenarios occurs, recovery is not possible:
• Someone stops the process with calls in progress. This situation occurs, when a system administrator
forgets to do a Call Server graceful shutdown. In this case the CVP Call Server will terminate all active
calls to release the licenses.
• The Call Server exceeds the recommended call rate. Although there is a limit for the absolute number
of calls allowed in the Call Server, there is no limit for the call rate. In general, exceeding the
recommended calls per second (cps) for an extended period of time can cause erratic and unpredictable
call behavior on certain components. You must ensure the components of the Unified CVP solution is
sized correctly and balance the call load according to the weight and sizing of each call processing
component. See the Sizing, on page 163 for call server call rate details.
For call survivability, configure the originating gateways as described in the latest version of the Configuration
Guide for Cisco Unified Customer Voice Portal (CVP), available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_
list.html
The survivability.tcl script also contains some directions and useful information.
In the event of most downstream failures (including a Call Server failure), the call is default-routed by the
originating gateway. Note that survivability is not applicable in the Unified CVP Standalone and NIC-routing
models because there is no Unified CVP SIP service in those models.
There is also a mechanism for detection of calls that have been cleared without Unified CVP’s knowledge:
• Unified CVP checks every 2 minutes for inbound calls that have a duration older than a configured time
(the default is 120 minutes).
• For those calls, Unified CVP sends an UPDATE message. If the message receives a rejection or is
undeliverable, then the call is cleared and the license released.
The CVP SIP service can also add the Session expires header on calls so that endpoints such as the originating
gateway may perform session refreshing on their own. RFC 4028 (Session Timers in the Session Initiation
Protocol) contains more details on the usage of Session expires with SIP calls.
Call disposition
Calls are handled as indicated for the following scenarios:
• Calls in progress
If the Unified CVP SIP Service fails after the caller has been transferred (transfers include transfer to
an IP phone, VoiceXML gateway, or other egress gateway), then the call continues normally until a
subsequent transfer activity (if applicable) is required from the Unified CVP SIP Service. If the caller
and is awaiting further activity, there is a period of 9 to 18 seconds of silence before the caller is
default-routed by survivability to an alternate location.
If the call has not yet been transferred, the caller hears 9 to 18 seconds of silence before being
default-routed by survivability to an alternate location. (Survivability does not apply in NIC-routing
models.)
• New calls
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
52
Unified CVP design for high availability
Server group
New calls are directed by the Unified SIP Proxy to an alternate Unified CVP Call Server. If no Call
Servers are available, the call is default-routed to an alternate location by survivability. (Survivability
does not apply in NIC-routing models.)
Server group
A Server group is a dynamic routing feature that enables the originating endpoint to know status of the
destination address before attempting to send the SIP INVITE. Whether the destination is unreachable over
the network, or is out of service at the application layer, the originating SIP user agent has knowledge of the
status through a heartbeat mechanism.
The Server group features adds a heartbeat mechanism with endpoints for SIP. This feature allows faster
failover on call control by eliminating delays due to failed endpoints.
Note • Server groups are not automatically created. Server groups are not created by the upgrade. You
must explicitly configure Server groups for their deployment, and turn the feature on after upgrading,
in order to take advantage of the feature.
• Upgrade for customers who already use Local SRV. Customers who already have an srv.xml file
configured with local SRV must run the import command mentioned below in order to put their
configuration into the Unified CVP Operations Console Server database. Do this before saving and
deploying any new server groups to avoid overwriting your previous configuration.
The Unified CVP SIP Subsystem builds on the local SRV configuration XML available with the release.
A Server group consists of one or more destination addresses (endpoints), and is identified by a Server group
domain name. This domain name is also known as the SRV cluster domain name, or FQDN. The SRV
mechanism is used, but the DNS server resolution of the record is not performed. Server groups remains the
same as local SRV implementation (srv.xml), but the Server groups feature adds the extra heartbeat mechanism
on top of it, as an option.
Note • Server groups in Unified CVP and SIP proxy servers work the same way.
• Only endpoints defined in a Server group may have heartbeats sent to them.
• With record-routes on proxy set to off, any mid-dialog SIP message such as REFER or REINVITES
would bypass the elements defined in server group. These messages would be directly delivered to
the other end point in the dialog.
In the previous releases, you used the srv.xml configuration file to configure SRV records locally, to avoid
the overhead of DNS SRV querying. However, the method of configuration was manual, and could not be
pushed from the Unified CVP Operations Console Server (Operations Console). Also, there was no validation
on the min and max values for fields.
Unified CVP adds this configuration into the Operations Console SIP subsystem using the Server groups
concept. The Server group term just refers to the local SRV configuration. When you turn on Server groups
with Heartbeat, you get the dynamic routing capability for Unified CVP to monitor the status of endpoints.
This feature only covers outbound calls from Unified CVP. To cover the inbound calls to Unified CVP, the
SIP proxy server can send similar heartbeats to Unified CVP, which can respond with status responses.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
53
Unified CVP design for high availability
Server group heartbeat settings
Note • Heartbeat Behavior Settings for Server groups. To turn off pinging when the element is up, set
the Up Endpoint Heartbeat Interval to zero (reactive pinging). To turn off pinging when the
element is down, set the Down Endpoint Heartbeat Interval to zero (proactive pinging). To ping
when the element is either up or down, set the heartbeat intervals to greater than zero (adaptive
pinging).
• Heartbeat Response Handling. Any endpoint that CVP may route calls to should respond to
OPTIONS with some response, either a 200 OK or some other response. Any response to a heartbeat
indicates the other side is alive and reachable. A 200 OK is usually returned, but CUSP Server may
return a 483 Too Many Hops response, since the max-forwards header is set to zero in an OPTIONS
message. Sometimes the endpoints may not allow OPTIONS or PING, and may return 405 Method
Not Allowed.
By default, Server group heartbeats are monitored using a UDP socket connection. The transport type can be
changed to TCP from the Operations Console Server Groups window.
Whenever an element has an unreachable or overloaded status, that element is marked as down completely,
that is for both UDP and TCP transports. When the element is up again, transports are routed for both UDP
and TCP.
Duplicate Server Group Elements is not monitored because the primary element is already monitored..
Note See the Configuration Guide for Cisco Unified Customer Voice Portal for typical configurations for the
Server groups feature. The Document is available at: http://www.cisco.com/en/US/products/sw/custcosw/
ps1006/products_installation_and_configuration_guides_list.html.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
54
Unified CVP design for high availability
Design considerations
If the host is in the local SRV Server groups configuration as an SRV name, then the host is not checked,
because it resolves to a local SRV name. IP addresses pass the validation.
Design considerations
Observe the following design considerations when implementing Server Groups:
• When you use the Local SRV configuration, you cannot use with the DNS SRV configuration. However,
elements may be declared as A record host names instead of IP addresses, and resolved through a DNS
server lookup or in the Operating System host file.
• In the CUSP Proxy CLI, define the SRV cluster name (such as proxy-servers.cisco.com) in the service
parameters section of the proxy configuration. Otherwise a 404 not found rejection may result.
Diagnostics
The Unified CVP log file has traces which show endpoint status events. See the Unified CVP System CLI
instructions in the Configuration Guide for Cisco Unified Customer Voice Portal, available at: http://
www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_
list.html.
Configuration
No additional configuration is needed in order to tell the SIP Service which IVR Service to use. By default,
the SIP Service use the IVR Service that resides on the same server. It is also no longer necessary to configure
the VoiceXML gateway with the IP address of the Call Server’s IVR Service. When SIP is used, the SIP
Service inserts the URL of the Call Servers IVR Service into a header in the SIP INVITE message when the
call is sent to the VoiceXML gateway. The VoiceXML gateway extracts this information from the SIP INVITE
and uses to determines which Call Server to use. The VoiceXML gateway examines the source IP address of
the incoming call from the Call Server. This IP address is used as the address for the Call Servers IVR service.
The following example illustrates the VoiceXML bootstrap service that is invoked when a call is received:
service bootstrap flash:bootstrap.tcl
paramspace english index 0
paramspace english language en
paramspace english location flash
paramspace english prefix en
With Unified CVP 4.0 and later releases you have to configure the IP address of the Call Server. The
bootstrap.tcl learns the IP address of the source Call Server and uses it as its call server. There is no need for
or backup Call Server configuration because receiving a call from the Call Server means that the server is
operational.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
55
Unified CVP design for high availability
Call disposition
The following files in flash memory on the gateway are also involved with high availability: handoff.tcl,
survivability.tcl, recovery.vxml, and several .wav files. Use Trivial File Transfer Protocol (TFTP) to load the
proper files into flash. Configuration information for each file can be found within the file itself. For information,
see the latest version of the Configuration Guide for Cisco Unified Customer Voice Portal (CVP), available
at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_
list.html
Call disposition
If the Unified CVP IVR Service fails, the following conditions apply to the call disposition:
• Calls in progress are default-routed to an alternate location on the originating gateway. (Survivability
does not apply in NIC-routing models.)
• New calls are directed to an in-service Unified CVP IVR Service.
VoiceXML gateway
The VoiceXML gateway parses and renders VoiceXML documents obtained from the Unified CVP Call
Server (from its IVR Service), the Unified CVP VXML Servers, or some other external VoiceXML source.
Rendering a VoiceXML document consists of retrieving and playing prerecorded audio files, collecting and
processing user input, or connecting to an ASR/TTS server for voice recognition and dynamic text-to-speech
conversion.
For a discussion of using mixed codecs in CVP deployments, see Mixed G.729 and G.711 codec support, on
page 110. For a discussion of the benefits and drawbacks of each codec, refer to Voice traffic, on page 120.
Note VXML GW must not have load balanced path, as this route on VXML GW will cause a call HTTP Client
Error. If the VXML GW has load balancing route to CVP Call Server, it may use a different source address
to send HTTP message to CVP Call Server, which would cause CVP to return a 500 Server Error address
to send HTTP message to CVP Call Server, which would cause CVP to return a 500 Server Error message.
In VXML GW, it is not possible to bind any specific interface for the HTTP Client side. So, if VXML
GW sends NEW_CALL using one interface and CALL_RESULT using another interface, CVP will return
a 500 Server Error.
Configuration
High availability configuration for VoiceXML gateways is controlled by the SIP proxy for SIP, or the Unified
CVP Call Server (Call Server). Whether the VoiceXML gateways are distributed or centralized also influences
how high availability is achieved.
In the event that a Call Server is unable to connect to a VoiceXML gateway, an error is returned to the ICM
script. In the ICM script, the Send to VRU node is separate from the first Run External script node in order
to catch the VoiceXML gateway connection error. If an END script node is used off the X-path of the Send
to VRU node, the call is default-routed by survivability on the originating gateway. (Survivability does not
apply in VRU-only models.) A Queue to Skill group node, but that method is effective only if there is an
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
56
Unified CVP design for high availability
Configuration
agent available. Otherwise, ICM tries to queue the caller, and that attempt fails because the Call Server is
once again unable to connect to a VoiceXML gateway. An END node could then also be used off the X-path
of the Queue to Skill Group node to default-route the call.
Note There are two features for the VXML Server that assist with load balancing:
• Limiting Load Balancer Involvement
• Enhanced HTTP Probes for Load Balancers
See the configuration options ip_redirect and license_depletion_probe_error in the User Guide for Unified
CVP VXML Server and Cisco Unified Call Studio, available at: http://www.cisco.com/en/US/products/sw/
custcosw/ps1006/products_user_guide_list.html.
Note Other wildcard characters can be used. See the topic Valid Formats for Dialed Numbers in the Ops
Console online help for complete wildcard format and precedence information.
In the case of both SIP proxy or Unified CVP static routes, the next-hop address of the route can be either the
IP address of the gateway or a DNS SRV record. If you are using an IP address, you must create multiple
static routes, one for each VoiceXML gateway. In the case of DNS SRV, only one route for each Network
VRU label is needed, and the SRV record provides for load-balancing and redundancy.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
57
Unified CVP design for high availability
Configuration
Note You can use other wildcard characters. See the topic Valid Formats for Dialed Numbers in the Operations
Console online help for complete wildcard format and precedence information.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
58
Unified CVP design for high availability
Call disposition
Configure the Unified CVP bootstrap.tcl application with the sigdigits parameter, telling it how many digits
to strip off of the incoming DNIS string:
application
service bootstrap flash:bootstrap.tcl
param sigdigits 4
...
Cisco Unified CM configuration (if used):
Configure Unified CM to strip the prepended digits, either by using the Significant Digits configuration on
the SIP Trunk configuration page or by using translation patterns.
SIP Proxy configuration:
Define static routes on the SIP Proxy, with the prepended digit present, to be sent to the appropriate VoiceXML
gateway. Because transfers to agents on a Unified CM cluster have prepended digit, the static routes for agent
phones must also contain the prepended digits.
Summary of call routing:
1 A call arrives at Unified CVP with a DNIS number of 33338002324444.
2 Unified CVP removes four digits (3333) from the beginning of the DNIS string, leaving 8002324444.
3 The number 8002324444 is passed to ICM for call routing.
4 When it is time to transfer, ICM returns the label 5551000102. Unified CVP prepends 3333, giving
33335551000102.
5 The SIP Service then resolves the address using the SIP Proxy or local static routes, and it sends the call
to the VoiceXML gateway.
6 The VoiceXML gateway bootstrap.tcl removes 3333, leaving 5551000102 for the destination address.
Call disposition
If the VoiceXML gateway fails, the following conditions apply to the call disposition:
• Calls in progress are default-routed to an alternate location by survivability on the ingress gateway.
(Survivability does not apply in NIC-routing models.)
• New calls find an alternate VoiceXML gateway.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
59
Unified CVP design for high availability
Media server
Media server
Audio files are stored locally in flash memory on the VoiceXML gateway or on an HTTP/TFTP file server.
Audio files stored locally are highly available. However, HTTP/TFTP file servers provide the advantage of
centralized administration of audio files.
Note You cannot install media server separately. The media server must be co-located with the Call Server and
Unified CVP VXML Server.
The backup server is invoked only if the primary server is not accessible, and this is not a load-balancing
mechanism. Each new call attempts to connect to the primary server. If failover occurs, the backup server is
used for the duration of the call; the next new call will attempt to connect to the primary server.
Note that Media server is not a fixed name, and it needs to match whatever name was assigned to the
media_server ECC variable in the ICM script.
The VoiceXML gateway also uses the following VoiceXML gateway configuration parameters to locate a
server when using a ACE:
ip host mediaserver <ip-address-of-ACE-VIP-for-media-server>
ip host mediaserver-backup <ip-address-of-ACE-VIP-for-media-server>
Because the ACE almost always locates a Media Server on the first request, a backup server is rarely invoked.
However, you can configure the backup server when using a ACE for deployments where there are multiple
data centers with a ACE in each.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
60
Unified CVP design for high availability
Cisco Unified Call Studio scripting configuration
• Calls in progress should recover automatically. The high-availability configuration techniques described
above make the failure transparent to the caller. If the media request does fail, use scripting techniques
to work around the error (for example, retry the request, transfer to an agent or label, or use TTS).
• New calls are directed transparently to the backup media server, and service is not affected.
• If the Media server is located across the WAN from the VoiceXML gateway and the WAN connection
fails, the gateway continues to use prompts from gateway cache until the requested prompt expires, at
which time the gateway attempts to reacquires the media and the call fails if survivability is not enabled.
If survivability is enabled, the calls are default-routed.
Configuration
The Unified CVP VXML Server high-availability configuration and behavior is different for standalone
deployments and deployments that are integrated with ICM, described in the following sections.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
61
Unified CVP design for high availability
Call disposition
Call disposition
If the Unified CVP VXML Server fails, the following conditions apply to the call disposition:
• Calls in progress in a Standalone deployment are disconnected. Calls in progress in an ICM-integrated
deployment can be recovered using scripting techniques to work around the error as shown in the script
above (for example, retry the request, transfer to an agent or label, or force an error with an END script
node to invoke survivability on the originating gateway).
• New calls are directed transparently to an alternate Unified CVP VXML Server.
Note Without an ACE device, callers might experience a delay at the beginning of the call
and have to wait for the system while it tries to connect to the primary Unified CVP
VXML Server.
Note Since MRCPv2 uses SIP to communicate with ASR/ TTS servers, use a SIP Proxy or gateway dial peers
to load balance the MRCPv2 traffic.
Configuration
The ASR/TTS high-availability configuration and behavior are different for Standalone and ICM-integrated
deployments, as described in the following sections.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
62
Unified CVP design for high availability
Call disposition
server is not accessible and if this is not a load-balancing mechanism. Each new call attempts to connect to
the primary server. If failover occurs, the backup server is used for the duration of the call; the next new call
will attempt to connect to the primary server.
The hostnames (such as asr-en-us) are fixed and cannot be modified. The only portion that may be modified
is the locale. In the following example, there is a set of primary and backup English ASR/TTS servers and a
set of Spanish servers. Configure the ACE, if used, according to the instructions in the latest version of the
Configuration Guide for Cisco Unified Customer Voice Portal (CVP), available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_
list.html
When an ACE is used, the IP addresses mentioned the following example would be the virtual IP address for
the ASR/TTS service.
ip host asr-en-us <ip-address-of-primary-English-ASR-server>
ip host asr-en-us-backup <ip-address-of-secondary-English-ASR-server>
ip host tts-en-us <ip-address-of-primary-English-TTS-server>
ip host tts-en-us-backup <ip-address-of-secondary-English-TTS-server>
ip host asr-es-es <ip-address-of-primary-Spanish-ASR-server>
ip host asr-es-es-backup <ip-address-of-secondary-Spanish-ASR-server>
ip host tts-es-es <ip-address-of-primary-Spanish-TTS-server>
ip host tts-es-es-backup <ip-address-of-secondary-Spanish-TTS-server>
For a discussion of using mixed codecs in CVP deployments, see Mixed G.729 and G.711 codec support, on
page 110. For a discussion of the benefits and drawbacks of each codec, see the Voice traffic, on page 120.
Note The ASR speech license is not released until the caller is transferred to the agent.
Call disposition
If the ASR/TTS MRCP server fails, the following conditions apply to the call disposition:
• Calls in progress in Standalone deployments are disconnected. Calls in progress in ICM-integrated
deployments can be recovered using scripting techniques to work around the error. For example, retry
the request, transfer to an agent or label, switch to prerecorded prompts and DTMF-only input for the
remainder of the call, an error with an END script node to invoke survivability on the originating gateway.
• New calls in ICM-integrated deployments are directed transparently to an alternate ASR/TTS server if
backup ASR/TTS server is configured on the gateway.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
63
Unified CVP design for high availability
Configuration
Configuration
For information on providing Unified CM for high availability, see the latest version of the Cisco Unified
Contact Center Enterprise Solution Reference Network Design (SRND) available at: http://www.cisco.com/
en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html.
Call disposition
If the Unified CM process fails on the server that is either hosting the call or hosting the phone, the following
conditions apply to the call disposition:
• Calls in progress are preserved. Skinny Client Control Protocol (SCCP) phones have the ability to
preserve calls even when they detect the loss of their Unified CM. The caller-and-agent conversation
continues until either the caller or agent goes on-hook. The Unified CVP Call Server recognizes that
Unified CM has failed, assumes the call should be preserved, and maintains the signaling channel to the
originating gateway. In this way, the originating gateway has no knowledge that Unified CM has failed.
Note that additional activities in the call (such as hold, transfer, or conference) are not possible. Once
the parties go on-hook, the phone is assigned to another Unified CM server. When the agent goes on-hook,
Real-Time Control Protocol (RTCP) packets cease transmitting to the originating gateway, which causes
the gateway to disconnect the caller 9 to 18 seconds after the agent goes on-hook. If survivability has
been configured on the gateway and the caller is waiting for some additional activity (the agent might
think the caller is being blind-transferred to another destination), the caller is default-routed to an alternate
location.
• New calls are directed to an alternate Unified CM server in the cluster.
Configuration
For the most current information on configuring ICM for high availability, refer to the latest version of the
Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND), available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html
Call disposition
There are many components in Cisco ICM, and call disposition varies depending on the component that fails.
Although there are a few exceptions, the following conditions apply to the call disposition:
• If the primary router fails, calls in progress are unaffected. However, if the time for the VRU PG to
realign to the other router is higher that the IVR service timeout ( 5 seconds default), calls in progress
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
64
Unified CVP design for high availability
Call disposition
are default-routed by survivability on the originating gateway. If both the Side A and Side B routers fail,
calls in progress are default-routed by survivability on the originating gateway.
• If the Logger fails, calls in progress are unaffected.
• If the primary router fails, calls in progress are unaffected. If both the Side A and Side B routers fail,
calls in progress are default-routed by survivability on the originating gateway.
• New calls are directed to the backup ICM component.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
65
Unified CVP design for high availability
Call disposition
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
66
CHAPTER 5
Cisco Unified ICM interactions
This chapter discusses Cisco Unified Intelligent Contact Management (ICM) from the perspective of its
relationship with Unified CVP. In some cases, the choice of deployment model has implications for Unified
ICM; and in other cases, certain choices about the Unified ICM configuration carry implications for the
Unified CVP deployment.
This chapter covers the following major topics:
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
67
Cisco Unified ICM interactions
Unified ICM network VRUs
In this document, the terms voice response unit (VRU) and interactive voice response (IVR) are used
interchangeably.
Note The deployed VRU can be located in the network (Network VRU) or at the customer premises. In the
latter scenario, a Network Applications Manager (NAM) is deployed in the network and a Customer ICM
(CICM) at the customer premises. The corresponding Correlation ID or Translation Route ID is used,
depending on the location of the VRU.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
68
Cisco Unified ICM interactions
Unified CVP Type 10 VRU
In Unified CVP implementations without the ICM Customers feature (that is, in Unified CVP implementations
with a single Network VRU), a single Type 10 Network VRU should be defined, and all Unified ICM VRU
scripts should be associated with it. It requires one label for the Unified CVP Switch leg routing client, transfers
the call to the Unified CVP VRU leg. If calls are transferred to Unified CVP from Unified CM, it also needs
another label for the Unified CM routing client, and this label should be different from the label used for the
CVP Routing Client. This label transfers the call to the Unified CVP Switch leg. The Unified ICM Router
sends this label to Unified CM with a Correlation ID concatenated to it. Unified CM must be configured to
handle these arbitrary extra digits.
Configure the Unified CVP Switch leg peripheral to point to the same Type 10 Network VRU. Also, associate
all incoming dialed numbers for calls that are to be transferred to Unified CVP with a Customer Instance that
points to the same Type 10 Network VRU.
For calls that originate at a Call Routing Interface VRU or at a TDM ACD, a TranslationRouteToVRU node
to transfer the call to Unified CVP’s Switch leg peripheral. For all other calls, use either a SendToVRU node,
a node that contains automatic SendToVRU behavior (such as the queuing nodes), or a RunExternalScript.
Note Type 5 and Type 2 VRU types are not supported any more. Instead of these VRU types, use Type 10
VRU.
Note Use Type 10 VRU for all new implementations of Unified CVP using Unified ICM 7.1 or greater, except
as VRU Only (Model #4a, described below).
When the VRU functions as an IVR with the Correlation ID mechanism, Unified ICM uses Type 3 and Type 7
to designate sub-behaviors of the VRU with the PG in the Correlation ID scheme. Both Type 3 and Type 7
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
69
Cisco Unified ICM interactions
Unified CVP Type 8 VRU (Translation Route ID Mechanism)
VRUs can be reached with the Correlation ID mechanism, and a PG is needed to control the VRU. However,
the difference between these two types is in how they release the VRU leg and how they connect the call to
the final destination.
In Type 3, the switch that delivers the call to the VRU can take the call from the VRU and connect it to a
destination (or agent).
In Type 7, the switch cannot take the call away from the VRU. When the IVR treatment is complete, Unified
ICM must disconnect or release the VRU leg before the final connect message can be sent to the Switch leg
to instruct the switch to connect the call to the destination.
When used as an Intelligent Peripheral IVR, Unified CVP supports only Type 7 because it gets a positive
indication from Unified ICM when its VRU leg is no longer needed (as opposed to waiting for the VoiceXML
gateway to inform it that the call has been pulled away). Type 3 has been deprecated.
As stated previously, there are two legs of the call: the Switch leg and the VRU leg. Different Unified CVP
hardware can be used for each leg. A service node along with a Unified CVP for VRU leg with PG acting as
VRU Type 7 can be used to complete the IVR application (self service, queuing, and so forth).
For configuration examples of the Unified CVP application with VRU Type 7, see the latest version of the
Configuration Guide for Cisco Unified Customer Voice Portal (CVP), available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_
list.html.
Note Type 10 VRU must be used for all new implementations of Unified CVP using Unified ICM 7.1 or greater,
except as VRU Only (Model #4a, described below).
When the VRU functions as an IVR with the Translation Route ID mechanism, Unified ICM uses Type 8 or
Type 10 to designate sub-behaviors of the VRU via the PG in the translation route scheme. Both Type 8 and
Type 10 VRUs can be reached via the Translation Route mechanism, and PG is needed to control the VRU.
However, they differ in how they connect the call to the final destination.
In Type 8, the switch that delivers the call to the VRU can take the call from the VRU and connect it to a
destination/agent.
For cases when the switch does not have the ability to take the call away from the VRU to deliver it to an
agent, use Type 10. In that case, when the IVR treatment is complete, Unified ICM sends the final connect
message to the VRU (rather than to the original switch) to connect the call to the destination. The VRU
effectively assumes control of the switching responsibilities when it receives the call. This process is known
as a handoff.
Similarly to the Correlation ID case, there are two legs of the call: the Switch leg and the VRU leg. Unified
CVP can be used for either the Switch leg or the VRU leg. For example, when a Network Interface Controller
(NIC), NAM, or CICM is involved, Unified CVP should be configured as Type 8 or Type 10 in the VRU leg.
For configuration examples of the Unified CVP application with VRU Type 8 or Type 10, see the latest version
of the Configuration Guide for Cisco Unified Customer Voice Portal (CVP), available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_
list.html
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
70
Cisco Unified ICM interactions
Network VRU types and Unified CVP deployment models
In Unified ICM, a Network VRU is a configuration database entity. It is accessed using the Network VRU
Explorer. A Network VRU entry contains the following pieces of information:
• Type — A number from 7, 8, and 10, which corresponds to one of the types described previously.
• Labels — A list of labels that you use in Unified ICM to transfer a call to the particular Network VRU.
These labels are relevant only for Network VRUs of Type 7 or 10 (that is, those VRU types that use the
Correlation ID mechanism to transfer calls). Each label consists of two parts:
◦A digit string, which becomes a DNIS that can be understood by a SIP Proxy Server or a static
route table (when SIP is used), or by gateway dial peers.
◦A routing client, or switch leg peripheral. Each peripheral device acts as a Switch leg must have
its own label, though the digit strings are the same in all cases.
Network VRU configuration entries have no value until they are associated with active calls. There are three
places in Unified ICM where this association is made:
• Under the Advanced tab for a given peripheral in the PG Explorer tool
• In the Customer Instance configuration in the Unified ICM Instance Explorer tool
• In every VRU Script configuration in the VRU Script List tool
Depending on the protocol-level call flow, personifying Unified ICM Enterprise looks at either the peripheral
or the Customer Instance to determine how to transfer a call to a VRU. The Unified ICM Enterprise examines
the Network VRU associated with the Switch leg peripheral when the call first arrives on a Switch leg, and
the Network VRU that is associated with the VRU leg peripheral when the call is being transferred to the
VRU using the Translation Route mechanism. It examines the Network VRU that is associated with the
Customer Instance when the call is being transferred to the VRU using the Correlation ID mechanism.
Unified ICM Enterprise also examines the Network VRU that is associated with the VRU Script every time
it encounters a RunExternalScript node in its routing script. If Unified ICM does not believe the call is currently
connected to the designated Network VRU, the VRU Script not executed.
Unified ICM Enterprise Release 7.1 introduced Network VRU Type 10, which simplifies the configuration
of Network VRUs for Unified CVP. For most call flow models, a single Type 10 Network VRU can take the
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
71
Cisco Unified ICM interactions
Model #1: Standalone self-service
place of the Type 2, 3, 7, or 8 Network VRUs that were associated with the Customer Instance and/or the
switch and VRU leg peripherals. The only major call flow model that still requires Type 7 or 8 is VRU Only
(Model #4a, described below).
Note that while the previously recommended VRU types still work as before for existing deployments, new
installations should use Type 10. Existing deployments should switch to Type 10 on upgrade.
Note Type10 is available in Unified ICM 7.1 and later, and new implementations must use this configuration.
Associate all incoming dialed numbers with a Customer Instance that is associated with a Type 10 Network
VRU. All the VRU Scripts that are executed by this call must be associated with the same Type 10 Network
VRU. Although it is not always necessary, the best practice is for the Unified ICM routing script to execute
a SendToVRU node prior to the first RunExternalScript node.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
72
Cisco Unified ICM interactions
Model #4: VRU only
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
73
Cisco Unified ICM interactions
Hosted implementations
nodes should appear after the Queue node. In that way, an unnecessary delivery and removal from Unified
CVP can be avoided if the requested agent is already available.
Note Two different VRU transfer nodes are required. The first one transfers the call away from the NIC with
a handoff, and it establishes Unified CVP as a Switch leg device for this call. Physically the call is delivered
to an ingress gateway. The second transfer delivers the call to the VoiceXML gateway and establishes
Unified CVP as the call's VRU device as well.
Hosted implementations
This section covers the following topics:
• Overview, on page 74
• Unified CVP in hosted environments, on page 75
• Hosted environment Unified CVP placement and call routing, on page 75
• Network VRU type in a hosted environment, on page 77
Overview
Hosted implementations incorporate a two-level hierarchy of Unified ICM systems. The Network Application
Manager (NAM) sits at the top level, and one or more Customer ICMs (CICMs) sit below it. Both the NAM
and CICM are really complete ICMs, with a communication link between them known as Intelligent Network
Call Routing Protocol (INCRP). Each CICM acts in an isolated fashion; it is not aware of the other CICMs,
nor is it aware that the NAM is itself another ICM. It has no connection to the other CICMs, but its connection
to the NAM is through the INCRP NIC.
Traditionally, customers implement Hosted setups because they are service providers. They want to provide
ICM contact center services to multiple customers of their own. Each customer is hosted on its own CICM,
and the NAM is responsible for routing calls, which are delivered to the service provider, to the appropriate
customer's CICM. The individual customers run their own contact centers with their own ACDs connected
to PGs at their own premises. The PGs, in turn, are connected to their assigned CICMs at the service provider.
Thus, the service provider owns and hosts the NAM and all the CICMs, but all the ACDs are owned and
hosted by the individual customers. The PGs for those ACDs are owned by the service provider but are located
at the customer's premises, next to the ACDs. The service provider itself does not necessarily operate any
ACDs of its own, but it could; those PGs could be connected to a CICM that is assigned to the service provider,
or they could actually be connected to the NAM itself.
In terms of ICM scripting, all incoming calls initially invoke an appropriate NAM routing script that has the
primary responsibility of identifying the appropriate target customer. The script then delegates control to a
routing script that is running on that customer's CICM. The CICM-based routing script can then select the
appropriate ACD to which to deliver the call, and it can return the necessary translation route label to the
NAM. The NAM can then instruct its routing client to deliver the call to the designated target ACD. If the
CICM routing script determines that no ACD can currently take the call or that it cannot yet identify which
ACD should take the call, it can ask the NAM to place the call into queue at a Service Control VRU. The
CICM routing script can then issue Network VRU Script requests via the NAM to that VRU until a routing
decision is made.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
74
Cisco Unified ICM interactions
Unified CVP in hosted environments
In practice, however, the NAM and CICM architecture is flexible enough to enable a number of other
possibilities. Many hosted customers use this topology simply as a way to get more calls or more PGs through
their ICM setup. Others use CICMs, not for customer contact centers, but for outsourcers. In such cases, the
NAM handles perhaps the same number of calls as the CICM, and the CICM machines themselves might be
located quite far away from the NAM. Also, the NAM and CICM architecture was designed at a time when
all contact centers ran on TDM-based ACDs. The addition of VoIP routing and ACDs based on Unified CM
(that is, Unified CCE) with direct agent routing made matters considerably more complicated.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
75
Cisco Unified ICM interactions
Hosted environment Unified CVP placement and call routing
◦If Translation Route transfers are used, then the TranslationRouteToVRU node, together with all
RunExternalScript nodes, must be in the NAM routing script. The implication here is that the call
is queued (or treated with prompt-and-collect) before the particular CICM is selected. This
configuration does not make much sense for queuing, but it could be useful for service providers
who want to offer initial prompt-and-collect before delegating control to the CICM.
• If Unified CVP is placed at the CICM and a NIC handles the Switch leg while Unified CVP handles the
VRU leg, only the Translation Route transfer method can be used. The TranslationRouteToVRU node,
together with all RunExternalScript nodes, must be in the CICM routing script.
Adding calls initiated by Unified CM or an ACD brings additional constraints. Both of these devices are
considered ACDs from the ICM perspective, and they most likely are connected at the CICM level. Assuming
these are new calls (as opposed to continuations of existing calls), the route request comes from the ACD and
the resulting label is returned to the ACD. Neither Unified CM nor any ACD is capable of transmitting a
Correlation ID upon transfer; you can only use the Translation Route transfer method. This limitation further
implies that the transfer destination (for example, Unified CVP) must also be connected at the CICM level,
not the NAM level.
If the calls are not new but continuations of existing calls, then they are attempts to transfer an existing inbound
caller from one agent to another agent. The customers might want these transfers to be either blind network
transfers (that is, the first agent drops off and the caller is delivered to a second agent or queued for a second
agent) or warm consultative transfers (that is, the caller goes on hold while the first agent speaks to a second
agent or waits in queue for a second agent when the first agent hangs up, the caller talks to the second agent).
The following guidelines apply to such transfers:
• Blind network transfers
If the original call was introduced to the NAM via a NIC or Unified CVP Switch leg, the transfer label
is passed from the CICM to the NAM to the original Switch leg device. There are two sub-cases of blind
network transfers:
◦If the Switch leg device is Unified CVP or a NIC that can handle Correlation ID, the Correlation
ID transfer mechanism can be used. The SendToVRU node and all RunExternalScript nodes must
be incorporated in the CICM routing script. The Unified CVP VRU leg can be connected to the
NAM. This combination of blind transfer with Correlation ID transfer is ideal for Unified CVP
and as much as possible.
◦If the Switch leg device is a NIC that cannot handle Correlation ID, then the Translation Route
transfer method must be used, which further implies that the Unified CVP VRU leg device must
be connected to the CICM.
Note In this case, the customer might have to deploy additional dedicated Unified CVP Call
Servers at the CICM level because the NAM-level Unified CVP Call Servers cannot be
used.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
76
Cisco Unified ICM interactions
Network VRU type in a hosted environment
In the one supported case where Unified CVP owns the initial Switch leg and the transfer is among
Unified CCE agents, the Translation Route transfer method must be used because Unified CM cannot
handle Correlation ID transfers. The Unified CVP VRU leg device must be connected to the CICM.
Note In this case, the customer might have to deploy additional dedicated Unified CVP Call Servers at the
CICM level because the NAM-level Unified CVP Call Servers cannot be used.
A Unified CM or ACD user issues a Route Request for one of the following reasons:
• To be connected to another agent in a particular skill group
• To reach a self-service application
• To blind-transfer a previously received call to one of the above entities
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
77
Cisco Unified ICM interactions
Cisco Unified Communications Manager and ACD call deployment models and sizing implications
In addition, a Unified CM user issues a Route Request for one of the following reasons:
• To deliver a successful outbound call from the Unified ICM Outbound dialer to a self-service application
based on Unified CVP
• To warm-transfer a call that the user had previously received to either a particular skill group or a
self-service application
Each of the above calls invokes an Unified ICM routing script. The script searches for an available destination
agent or service and if an appropriate destination is found, it sends the corresponding label either back to the
ACD or, if blind-transferring an existing call, to the original caller's Switch leg device. If it needs to queue
the call or if the ultimate destination is intended to be a self-service application rather than an agent or service,
the script sends a VRU translation route label either back to the ACD or, if blind-transferring an existing call,
to the original caller's Switch leg device.
If the above sequence results in transferring the call to Unified CVP's VRU leg device, there is a second
transfer to deliver it to a VoiceXML gateway. To ensure that these events take place, the following Unified
ICM configuration elements are required:
• For new calls from the ACD or warm transfers of existing calls:
◦The Unified CVP peripheral must be configured to be associated with a Type 10 Network VRU.
◦The dialed number that the ACD dialed must be associated with a Customer Instance that is
associated with a Type 10 Network VRU.
◦When an ACD is not configured Unified CM, the routing script that was invoked by the ACD
dialed number must contain a TranslationRouteToVRU node to get the call to Unified CVP's
Switch leg, followed by a SendToVRU node to get the call to the VoiceXML gateway and Unified
CVP's VRU leg.
◦The routing script that was invoked by Unified CM should uses a SendToVRU node to send the
call to Unified CVP using the Correlation ID. The Type10 VRU performs an automatic second
transfer to the VoiceXML gateway VRU leg.
◦All the VRU scripts that are executed by that routing script must be associated with the Type 10
Network VRU.
When Unified ICM chooses an agent or ACD destination label for a call, it tries to find one that lists a routing
client that can accept that label. For calls originated by an ACD or Unified CM which are not blind transfers
of existing calls, the only possible routing client is the ACD or Unified CM. Once the call has been transferred
to Unified CVP, because of the handoff operation, the only possible routing client is the Unified CVP Switch
leg. But in the case of blind transfers of existing calls, two routing clients are possible: (1) the Unified CVP
Call Server switch leg that delivered the original call, or (2) the ACD or Unified CM. For calls that originate
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
78
Cisco Unified ICM interactions
Third-party VRUs
through Unified CVP, you can prioritize Unified CVP labels above ACD or Unified CM labels by checking
the Network Transfer Preferred box in the Unified ICM Setup screen for the Unified CVP peripheral.
When using Unified CVP to do network transfers, an agent blind-transfers the caller to a new destination with
the Network Transfer Preferred option. In this scenario, the agent uses CTI Agent Desktop (and not the phone
itself) to invoke the transfers. In addition to the CTI Agent Desktop, the Agent uses the Unified ICM Dialed
Number Plan. If configured with the same DN as the CTI Route Point, the Unified ICM Dialed Number Plan
causes Unified ICM to intercept the transfer and run the Unified ICM routing script without sending the
transfer commands to Unified CM through JTAPI. When the Unified ICM script returns a label, that label is
used for the Network routing client (Unified CVP), and the caller is sent directly to the new destination. This
configuration avoids a timing problem that can occur if an agent uses Unified CM CTI Route Points to initiate
a network transfer.
Third-party VRUs
A third-party TDM VRU can be used in any of the following ways:
• As the initial routing client (using the GED-125 Call Routing Interface)
• As a traditional VRU (using the GED-125 Call Routing Interface)
• As a Service Control VRU (using the GED-125 Service Control Interface)
In the first and second cases, the VRU acts exactly like an ACD, as described in the section on Cisco Unified
Communications Manager and ACD call deployment models and sizing implications, on page 77. Like an
ACD, the VRU can be a destination for calls that arrive from another source. Calls can even be translation-routed
to such devices in order to carry call context information. (This operation is known as a traditional translation
route, not a TranslationRouteToVRU.) Also like an ACD, the VRU can issue its own Route Requests and
invoke routing scripts to transfer the call to subsequent destinations or even to Unified CVP for self-service
operations. Such transfers almost always use the Translation Route transfer mechanism.
In the third case, the VRU takes the place of either Unified CVP's Switch leg or Unified CVP's VRU leg, or
it can even take the place of Unified CVP entirely. Such deployments are beyond the scope of this document.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
79
Cisco Unified ICM interactions
Trunk Utilization routing and reporting
The following logic is used in Unified CVP to parse and pass the PSTN trunk group info to Unified ICM:
• For TrunkGroupID, look for tgrp: in the x-route-tag field
• If tgrp: found TrunkGroupID = <value after tgrp:> + <data between ISDN and :DS1 tags>
Using the above example: TrunkGroupID = 2811-b-000<space>0/0/0:15 0/0/0
• Else TrunkGroupID = <IP addr of originating device in Via header> + <data between ISDN and
:DS1 tags>
Using the above example: TrunkGroupID = 192.168.1.79<space>0/0/0:15 0/0/0
Trunk Utilization Routing could also be used to update trunk group status in the Unified CCE router. A PSTN
call (through the ICM script) can query the router with a pre-route from an SS7 NIC to see the most available
ingress gateway to use for the post route to Unified CVP.
Note DS0 is the data line that provides utilization information about the number of trunks free on a gateway.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
80
Cisco Unified ICM interactions
Gateway trunk utilization with server group pinging combination
Deployment considerations
Configuration and Deployment Considerations
• For Proxy Server Deployment with CUSP:
Configure TDM originating gateways for Rai-targets to provide status in OPTIONS message to primary
and secondary Unified CVP Call Servers, for reporting purposes only. The data is only used for reporting,
not routing, so the data only needs to be sent to Call Servers that have reporting enabled.
Configure primary and secondary CUSP proxy servers with Server Groups pinging to Unified CVP,
VXML gateways, and CUCM elements.
Configure Unified CVP with Server Group pinging to both primary and secondary CUSP proxies for
outbound calls.
• For Non Proxy Deployment:
Configure TDM originating gateways for RAI-targets to provide status in OPTIONS message to primary
and secondary Call Servers. Unified CVP can handle the messages for both reporting and routing
purposes. If used for routing, then the gateway must be in a server group by itself on Unified CVP.
Configure Unified CVP with Server Groups pinging to Unified CVP, VXML gateways and CUCM
elements for outbound calls.
Configure VXML gateways for Rai-targets to provide status in the OPTIONS message to primary and
secondary Call Servers.
• See the IOS documentation for recommendations on the high and low watermark settings.
• Configure the Unified CVP Call Servers to send the same hostname in the contact header of OPTIONS
requests to the gateways. This enables a single Rai-target to be configured to all Call Servers. This is
important since the limit is only five targets. The parameter to set is called Options Header Override.
Limitations:
• RAI is not currently supported on Proxy Servers.
CUSP servers do not currently handle the RAI header of OPTIONS messages, so they will not mark the
status of elements with that information. If VXML gateways are down, Unified CVP may send the call
using the proxy, because the proxy does not handle incoming RAI headers in OPTIONS. It is possible
to use a local static route scheme on Unified CVP to send all calls to the proxy except the Voice XML
gateways calls, in order to create a server group for Voice XML gateways and take advantage of RAI
updates for routing.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
81
Cisco Unified ICM interactions
Enhanced User-to-User information
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
82
Cisco Unified ICM interactions
Using UUI
Note The modified UUI from Unified ICM is passed using the user.microapp.uui ECC variable, or the
Call.UsertoUserInfo variable.
Modified GTD is set in the outbound INVITE mime body from CVP SIP B2BUA, which includes IP originated
callers as well as TDM callers. If a DTMF label for outpulse transfer is received on a connected call, then the
BYE will be sent with the GTD only if UUI is passed by Unified ICM. The BYE is sent immediately after
the SIP INFO with DTMF.
Using UUI
Extract the UUI in your Unified ICM Script by looking at the Call ECC variable user.microapp.uui and the
Call.UserToUserInfo variable, such as in the IF node. By using the SET node on either one of these variables,
the variable can be set on the outbound direction of the call.
Setting Call.UserToUserInfo takes precedence over using the ECC variable.
Note Unified CVP sends a BYE message on the DTMF label only if UUI is received from Unified ICM.
If a BYE message is received, then the GTD from the received BYE is used to send it on the other leg.
Configure the ingress gateway with signaling forward unconditional, as in the following example, so that
GTD with UUI/UUS are forwarded on the VoIP side.
Example:
voice service voip
signaling forward unconditional
Design considerations
The UUI data transfer feature cannot be used with Hookflash or TBCT transfers.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
83
Cisco Unified ICM interactions
Custom SIP Headers
Note Not all headers have a compact format. For example, P-Headers or private headers (for example
P-Asserted-Identity) may not have a compact form and hence the full header name shall be passed to ICM.
Note Please see the table in the RFC3261 that defines the compact header abbreviations.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
84
Cisco Unified ICM interactions
Passing Information in SIP Headers to Unified ICM
Note The SIP header modification feature is a powerful tool which can tweak SIP headers as needed. Exercise
caution when applying SIP Profiles and ensure that the profile does not create interop issues, rather than
solving them. Unified CVP provides the flexibility to add, modify, or remove outgoing SIP header in the
INVITE message only. You can deploy Unified CVP in many scenarios to facilitate inter-operability with
third-party devices.
Outgoing SIP header feature do not allow you to remove or add Mandatory SIP headers. Only the modify
option is available for basic mandatory headers; such as To, From, Via, CSeq, Call-Id and Max-Forwards.
There is no checking for the modifications in the ICM script editor, it is actually enforced by the java SIP
stack layer by throwing a DsSipParserException.
Typically, with Unified ICM, if the field is greater than 255 chars then it is truncated. In the SIP subsystem,
if there is a problem updating or adding a header with the string given from the Unified ICM script, then you
either see an WARN type message in the Unified CVP log, if there is an DsSipParserException, or else sends
the INVITE unexpected results on the receiver end.
This feature is applicable only for outgoing SIP INVITES (only the initial INVITE, not reinvites). Changes
to the INVITE are applied just before it is sent out. There is no restriction on the changes that can be applied.
The header length (including header name) after modification should not exceed 255.
Example Notes
"Call-Info~add~<sip:x@y>;parm1=value1" Adds a Call-Info header with the proper call
info syntax as per RFC3261.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
85
Cisco Unified ICM interactions
Courtesy Callback
Example Notes
"Via~add~SIP/2.0/UDP viaHost" Adds a Via header to the message.
Troubleshooting information for Unified CVP can be found on the Unified CVP Doc-Wiki Troubleshooting
page: http://docwiki-dev.cisco.com/wiki/Troubleshooting_Tips_for_Unified_Customer_Voice_Portal.
Courtesy Callback
Courtesy Callback reduces the time callers have to wait on hold or in a queue. The feature enables your system
to offer callers, who meet your criteria, the option to be called back by the system instead of waiting on the
phone for an agent. The caller who has been queued by Unified CVP can hang up and subsequently be called
back when an agent is close to becoming available (preemptive callback). This feature is provided as a courtesy
to the caller so that the caller does not have to wait on the phone for an agent.
Preemptive callback does not change the time a customer must wait to be connected to an agent, but rather
enables the caller to hang up and not be required to remain in queue listening to music. Callers who have
remained in queue or have undergone the callback treatment will appear the same to agents answering the
call.
Note Scheduling a callback to occur at a specified time is not part of this feature.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
86
Cisco Unified ICM interactions
Typical Use Scenario
The following illustration shows the components needed for the Courtesy Callback feature.
Figure 6: Courtesy Callback components
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
87
Cisco Unified ICM interactions
Determine callback time
4 If the caller chooses not to use the callback feature, queuing continues as normal.
Otherwise, the call continues as indicated in the remaining steps.
5 If the caller chooses to receive a callback, the system prompts the caller to record their name and to key
in their phone number.
6 The system writes a database record to log the callback information.
Note If the database is not accessible, then the caller is not offered a callback and they are placed in queue.
7 The caller is disconnected from the TDM side of the call. However, the IP side of the call in Unified CVP
and Unified ICMis still active. This keeps the call in the same queue position. No queue music is played,
so Voice XML gateway resources used during this time are less than if the caller had actually been in
queue.
8 When an agent in the service/skill category the caller is waiting for is close to being available (as determined
by your callback scripts), then the system calls the person back. The recorded name is announced when
the callback is made to insure the correct person accepts the call.
9 The system asks the caller, through an IVR session, to confirm that they are the person who was waiting
for the call and that they are ready for the callback.
If the system cannot reach the callback number provided by the caller (for example, the line is busy, RNA,
network problems, etc.) or if the caller do not confirm they are the caller, then the call is not sent to an
agent. The agent is always guaranteed that someone is there waiting when they take the call. The system
assumes that the caller is already on the line by the time the agent gets the call.
This feature is called preemptive callback as the system assumes that the caller is already on the line by
the time the agent gets the call and that the caller has to wait minimal time in queue before speaking to an
agent.
10 The system presents the call context on the agent screen-pop, as normal.
In the event that the caller cannot be reached after a configurable maximum number and frequency of retries,
the callback is aborted and the database status is updated appropriately. You can run reports to determine if
any manual callbacks are necessary based on your business rules.
See the Configuration Guide for Cisco Unified Customer Voice Portal at http://www.cisco.com/en/US/products/
sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html that explains a call flow
description of the function of the scripts providing the Courtesy Callback feature.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
88
Cisco Unified ICM interactions
Overview
• Callback in Queue Time: the interval between when the caller is reconnected, waiting for an agent and
when the call leaves the queue
• Service Level Agreement (SLA): average of Callback in Queue Time. Here, it is understood that average
means that roughly 50 percent of calls are within the service level and 50 percent are outside the service
level.
• Average Dequeue Time: the average number of seconds it takes for a call to leave the queue.
• Remaining Time: the number of seconds left to count down to call back the caller.
Overview
The average Callback in Queue Time after a callback is designed to be within an agreed service level. However,
Courtesy Callback is also designed so that callers are not called back too early or too late, as both scenarios
are undesirable. On the one hand, if callers are called back too early then they are more likely to have to wait
in the queue for a longer period of time, while, if the callback is made too late, there is a greater chance that
call center agents could be idle and waiting for calls.
When the dynamics of a call center change, such as when more or fewer agents are available, or when the
average handle time changes, it in turn causes the remaining time to change. Therefore, with Courtesy Callback,
the Average Dequeue Time is calculated based on various factors such as calls in queue, average handle time,
and agents in ready and talking states.
The Average Dequeue Time is updated when a call enters the queue and when it leaves the queue. This
information is used for calculations for reducing the Callback in Queue Time and minimizing instances of
call center agents waiting for calls
Note The Dequeue Time plays a significant role in the optimal behavior of the Courtesy Callback feature. The
average Dequeue Time is calculated based on factors such as call volume, agent availability and the average
handle time for a particular skill group. The Estimated Wait Time (EWT) is an approximation, and its
accuracy is driven by the uniform average handling time and agent availability for a particular skill group.
If these factors are not uniform, it may lead to a difference in the estimated wait time announced to the
customer and the actual callback time. Therefore, the Courtesy Callback feature needs a careful design
consideration.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
89
Cisco Unified ICM interactions
Example scripts and audio files
2 The remaining time for all Courtesy Callback calls in the queue is updated using the formula: R(p) = p*D
- F - C, where:
• p = 1, ..., N
• R(p) is the remaining time for the pth queue position Courtesy Callback call, and
• C, the post-callback time, is the sum of the time it takes to retrieve the Courtesy Callback caller back
on the phone and the SLA time.
Sample audio files that accompany the sample studio scripts are installed to the
<CVP_HOME>\OPSConsoleServer\CCBDownloads\CCBAudioFiles.zip and also as part of the Media Files
installation option.
• If CCBAudioFiles.zip is used, the contents must be unzipped onto the your media server.
CCBAudioFiles.zip has Courtesy Callback specific application media files under en-us\app and media
files for Say It Smart under en-us\sys. If you already have media files for Say It Smart on your media
server, then only the media files under en-us\app are needed.
The sample scripts are configured to use the default location of "http://<server>:<port>/en-us/app". The default
location of the sample audio files must be changed in the sample scripts to accommodate your needs (i.e.
substitute the media server IP address and port in <server> and <port>).
The following example scripts are provided:
• BillingQueue
This script is responsible for playing queue music to callers that either choose to not have a callback
occur or must reenter the queue for a short period after receiving a callback.
You may customize this script to suit your business needs.
• CallbackEngine
This script keeps the VoIP leg of a callback alive between when a caller elects to have a callback and
when a caller receives the callback.
Do not customize this script.
• Callback Entry
This script handles the initial IVR when a caller enters the system and when the caller is provided with
the opportunity to receive a callback.
You may customize this script to suit your business needs.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
90
Cisco Unified ICM interactions
Callback criteria
• CallbackQueue
This script handles the keepalive mechanism of a call while a caller is in queue and listening to the music
played within the BillingQueue script.
Do not customize this script.
• CallbackWait
This script handles the IVR portion of a call when a customer is called back.
You may customize this script to suit your business needs.
Callback criteria
Examples of callback criteria you can establish include:
• Number of minutes a customer is expected to be waiting in queue exceeds some maximum number of
minutes (based on your average call handling time per customer)
Note The included sample scripts use this method for determining callback eligibility.
• Assigned status of a customer (gold customers may be offered the opportunity to be called back instead
of remaining on the line)
• The service a customer has requested (sales calls, or system upgrades, etc. may be established as callback
criteria)
Note In Courtesy Callback, outbound calls cannot be made using any other egress gateway.
• Calls that allow Callbacks must be queued using a Unified CVP VXML Server.
• The Unified CVP Reporting Server must be installed and licensed.
• Answering machine detection is not available for this feature. During the callback, the best that can be
done is to prompt the caller with a brief IVR session and acknowledge with DTMF that they are ready
to take the call.
• Calls that are transferred to agents using DTMF *8, TBCT, or hookflash cannot use the Courtesy Callback
feature.
• Callbacks are a best-effort mechanism. After a limited number of attempts to reach a caller during a
callback, the callback is terminated and marked as failed.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
91
Cisco Unified ICM interactions
Post call survey Customer response options
• Customers must configure the allowed/blocked numbers that Callback is allowed to place calls through
the Operations Management Console.
• Media inactivity detection feature on the VXML Gateway can impact waiting callback calls. For more
information, see the Configuration Guide for Cisco Unified Customer Voice Portal (CVP).
For reporting purposes, the post call survey call has the same Call-ID and call context as the original inbound
call.
Typical uses
The caller is typically asked whether they would like to participate in a survey during the call. In some cases,
the system configuration based on dialed number(s) determines if the post call survey gets invoked at the end
of conversation with agent(s). When the customer completes the conversation with an agent, the customer is
automatically redirected to a survey. The post call survey gets triggered by the hang-up event from the last
agent.
A customer can use the keypad on a touch tone phone and/or voice with ASR/TTS to respond to questions
asked during the survey. From the Unified CCE point of view, the post call survey call is just like another
regular call. During the post call survey, the call context information is retrieved from the original customer
call.
Design Considerations
Observe the following conditions when designing the Post Call Survey feature:
• A Post Call Survey is triggered by the hang-up event from the last agent. When the agent hangs up, the
call routing script launches a survey script.
• The mapping of a dialed number pattern to a Post Call Survey number enables the Post Call Survey
feature for the call.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
92
Cisco Unified ICM interactions
Design Considerations
• The value of the expanded call variable user.microapp.isPostCallSurvey controls whether the call is
transferred to the Post Call Survey number.
◦If user.microapp.isPostCallSurvey is set to y (the implied default), the call is transferred to the
mapped post call survey number.
◦If user.microapp.isPostCallSurvey is set to n, the call ends.
◦To route all calls in the dialed number pattern to the survey, your script does not have to set the
user.microapp.isPostCallSurvey variable. The variable is set to y by default.
◦To test for conditions and dynamically route calls to the survey based on the results of the test,
your script must explicitly set user.microapp.isPostCallSurvey to y and n as appropriate.
• REFER call flows are not supported with Post Call Survey. (The two features conflict: REFER call flows
remove Unified CVP from the call; Post Call Survey needs Unified CVP because the agent has already
disconnected.)
• For Unified CCE reporting purposes, when a survey is initiated, the call context of the customer call
that was just transferred to the agent is replicated into the call context of the Post Call Survey call.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
93
Cisco Unified ICM interactions
Design Considerations
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
94
CHAPTER 6
Calls originated by Cisco Unified
Communications Manager
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
95
Calls originated by Cisco Unified Communications Manager
Customer call flows
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
96
Calls originated by Cisco Unified Communications Manager
Protocol call flows
Note Model #4, VRU Only with NIC Controlled Routing, is not discussed here because there is no NIC involved
with calls originated by Unified CM.
Note The script must not execute a Transfer node, unless it is to a TDM destination. Transfers to an IP destination
will result in an IP-to-IP call, which is supported, but requires that you add ip-ip-gw commands (CUBE
commands) to the gateway configuration for the transfer operation to another VoIP destination to succeed.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
97
Calls originated by Cisco Unified Communications Manager
Model #2: Call director
This model assumes that the call is truly originating from Unified CM. This model excludes calls that originally
arrived through a Unified CVP ingress gateway and were transferred to Unified CM, and are now transferred
again. Such situations are rare because Unified CM can usually handle those transfers itself. There are
exceptions, however, such as when the target is an ACD other than Unified CM, but those situations are not
covered here.
This model requires that the following items be configured:
• Unified CM route point that invokes a Unified ICM script
• Unified CVP configured as a Type 2 NetworkVRU
• VRU translation routes to Unified CVP
• Translation route Dialed Number Identification Service (DNIS) numbers configured in the Unified CVP
Call Server
• Unified CM configured with a SIP trunk
• Unified CM route patterns for Translation Route DNIS
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
98
Calls originated by Cisco Unified Communications Manager
Model #3a: Comprehensive using ICM micro-apps
If the target device later issues another route request to Unified ICM, the call flow is again exactly as described
above. The call must again be transferred with Correlation ID via SendToVRU to the Unified CVP Call Server
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
99
Calls originated by Cisco Unified Communications Manager
Model #3b: Comprehensive using Unified CVP VXML server
and VoiceXML gateway to create the VRU leg. Microapplications might be executed, and eventually the new
target label is delivered to the Unified CVP Switch leg, which transfers the call to that target.
Deployment implications
This section presents guidelines for the following aspects of incorporating calls originated by Unified CM
into the deployment:
• Unified ICM configuration, on page 100
• Hosted implementations, on page 101
• Cisco Unified Communications Manager configuration, on page 101
• Sizing, on page 101
Note This call flow and all others in this document assume Cisco Unified ICM 7.0(0) or later.
• For additional configuration requirements, see Protocol call flows, on page 97.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
100
Calls originated by Cisco Unified Communications Manager
Hosted implementations
Hosted implementations
Translation routes sent by one ICM router must be received by a peripheral that is connected to the same ICM
router. Therefore, you can translation-route a call from a Unified CM at the CICM level into Unified CVP
only if Unified CVP is also located at the CICM level. In Hosted environments, this means you must provision
Unified CVP Call Servers (Call Servers) at the CICM level even if you already have other Call Servers at the
NAM level.
For more details on this subject, see the chapter on Cisco Unified ICM interactions, on page 67.
Sizing
Most customer implementations are not primarily designed for calls originated by Unified CM. The main
driver is usually incoming customer calls, although calls originated by Unified CM are frequently a component,
particularly in the case of warm transfers. Remember to consider those calls when sizing equipment.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
101
Calls originated by Cisco Unified Communications Manager
KPML support
Gateways
Calls originated by Unified CM do not use ingress gateways at all. Calls are delivered directly from Unified CM
to the Unified CVP Call Server. They do, however, use VoiceXML gateways whenever a VRU leg is in use.
Therefore, for the purposes of sizing VoiceXML gateways, consider each Unified CM call that is either in
queue or conducting self-service activities.
KPML support
KPML is an out-of-band DTMF method that passes key press information through SIP signaling instead of
through the RTP stream.
Typical Unified CVP Comprehensive call flows use the inband RFC2833 DTMF configuration on endpoints.
However, there are some endpoints that do not support inband RFC2833 and the CTI Ports used in UCCE
Mobile Agent deployments.
For these endpoints, when the destination behind the SIP Trunk is set with RFC2833, Cisco Unified CM
allocates an MTP resource because the line side and the trunk side require a translation of the inband packets
to the out-of-band signaling messages for DTMF.
To avoid MTP allocation, the destination of the SIP Trunk needs to be configured using the SIP KPML DTMF
method (that is, the No Preference setting). Also, the VoiceXML bootstrap dial peer requires SIP and KPML
settings.
The Unified CVP SIP subsystem can pass through Subscribe and Notify events related to KPML DTMF digits
(out-of-band DTMF).
Design considerations
The following limitation applies when using the KPML feature:
1 ASR or TTS is not supported with KPML.
Configure the SIP Trunk should be configured for DTMF No Preference if KPML is set on the gateway. If
the SIP Trunk points to the Unified CVP directly, Configure the DTMF Preference to No Preference, because
the Unified CVP B2BUA is in the middle of the call, and the SDP attributes are passed through as though
they came directly from the VoiceXML gateway.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
102
CHAPTER 7
Gateway options
Cisco offers a large range of voice gateway models to cover a large range of requirements. Many, but not
all, of these gateways have been qualified for use with Unified CVP. For the list of currently supported
gateway models, always check the latest version of the Hardware and System Software Specification for
Cisco Unified CVP (formerly called the Bill of Materials), available at the following location:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/prod_technical_reference_list.html.
Gateways are used in Unified CVP for conversion of TDM to IP and for executing VoiceXML instructions.
The following sections help you determine which gateways to incorporate into your design:
Note The Cisco Unified CVP provides the flexibility to add, modify, remove or deploy Unified CVP in many
scenarios to facilitate interoperability with third-party devices. Not all SIP service providers support
advanced features such as REFER, 302 Redirect Messages, DTMF-based take-back-and-transfer, or data
transport (UUI, GTD, NSS, etc). Please verify before planning on deploying these capabilities. Refer to
the interoperability note available at the following location for information on the interoperability support
for SBC when deployed in place of Cisco CUBE. http://www.cisco.com/en/US/solutions/ns340/ns414/
ns728/voice_portal.html
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
103
Gateway options
New or changed chapter information
PSTN gateway
In this type of deployment, the voice gateway is used as the PSTN voice gateway. The voice gateway is
responsible for converting TDM speech to IP and for recognizing DTMF digits and converting them to
RFC2833 events.
Note Unified CVP does not support passing SIP-Notify DTMF events.
In a centralized Unified CVP deployment, you can separate the VoiceXML functionality from the ingress
gateway to provide a separate PSTN ingress layer. The separate PSTN layer and VoiceXML farm enables the
deployment to support a large number of VoiceXML sessions and PSTN interfaces. For example, the Cisco
AS5400XM can accept a DS3 connection, providing support for up to 648 DSOs. However, a gateway that
is handling that many ingress calls cannot also support as many VoiceXML sessions. In such cases, the
VoiceXML sessions should be off-loaded to a separate farm of VoiceXML-only gateways.
Note Any TDM interface can be used as long as it is supported by the Cisco IOS gateway and by the Cisco IOS
version compatible with CVP.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
104
Gateway options
VoiceXML and PSTN Gateway with DTMF or ASR/TTS
for Survivable Remote Site Telephony (SRST). The Cisco 2800 Series and 3800 Series and the newer
2900 Series and 3900 Series routers are the best choices for the voice gateway because they support SRST.
For a discussion on the advantages and disadvantages of each codec, See Voice traffic, on page 120.
TDM interfaces
The Cisco AS5400XM Universal Gateway offers unparalleled capacity in only two rack units (2 RUs) and
provides best-of-class voice, fax, and remote-access services. High density (up to one Channelized T3 (CT3)
of voice over IP (VoIP) and two CT3s of time-division multiplexing (TDM) switching), low power consumption
(as low as 2.4 A at 48 VDC per G.711 CT3), high-density packet voice digital signal processor (DSP) modules,
universal port DSPs, and session border control (SBC) features make the Cisco AS5400XM Universal Gateway
ideal for many network deployment architectures, especially co-location environments and mega points of
presence (POPs).
The Cisco AS5350XM Universal Gateway is the one-rack-unit (1 RU) gateway that supports 2-, 4-,8-, or
16-port T1/12-port E1 configurations and provides universal port data, voice, and fax services on any port at
any time. The Cisco AS5350XM Universal Gateway offers high performance and high reliability in a compact,
modular design. This cost-effective platform is ideally suited for internet service providers (ISPs) and enterprise
companies that require innovative universal services.
The Cisco 2800 Series and 3800 Series and the newer 2900 Series and 3900 Series Routers support the widest
range of packet telephony-based voice interfaces and signaling protocols within the industry, providing
connectivity support for more than 90 percent of the world's private branch exchanges (PBXs) and public
switched telephone network (PSTN) connection points. Signaling support includes T1/E1 Primary Rate
Interface (PRI), T1 channel associated signaling (CAS), E1-R2, T1/E1 QSIG Protocol, T1 Feature Group D
(FGD), Basic Rate Interface (BRI), foreign exchange office (FXO), E&M, and foreign exchange station (FXS).
The Cisco 2800 Series and 3800 Series Routers can be configured to support from two to 540 voice channels.
The Cisco 2900 Series and 3900 Series Routers can be configured to support from two to 720 voice channels.
For the most current information about the various digital (T1/E1) and analog interfaces supported by the
various voice gateways, see the latest product documentation available at the following sites:
• Cisco 2800 Series
http://www.cisco.com/en/US/products/ps5854/tsd_products_support_series_home.html
• Cisco 3800 Series
http://www.cisco.com/en/US/products/ps5855/tsd_products_support_series_home.html
• Cisco AS5300
http://www.cisco.com/en/US/products/hw/univgate/ps501/tsd_products_support_series_home.html
• Cisco 2900 Series
• http://www.cisco.com/en/US/products/ps10537/index.htm.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
105
Gateway options
Cisco Unified Border Element
Note Unlike flow-through mode, with flow-around mode, you lose the ability to do DTMF interworking,
transcoding, and other key functions such as telephone and media capabilities that flow-through will
otherwise allow.
A Unified Border Element is typically needed when replacing a TDM voice circuit with an IP voice trunk,
such as a SIP trunk, from a telephone company. The CUBE serves as a feature-rich demarcation point for
connecting enterprises to service providers over IP voice trunks.
The CUBE has been tested with, and can be used in, any of the following scenarios:
• SIP-to-SIP connectivity between a third-party SIP device and Cisco Unified CVP over the SIP trunks
certified by Cisco.
• SIP-to-SIP connectivity between Cisco Unified Communications Manager and Cisco Unified CVP.
• Co-residency of VoiceXML Gateway and CUBE for any of the above scenarios but with the limitation
that the call flow does not work when the configurations listed below occur at the same time on the
CUBE:
◦Survivability TCL script and incoming translation rules are configured under the same incoming
dial-peer.
◦Header-passing is enabled globally.
For more information about using the CUBE with Unified CVP, including topologies and configurations, see
,mn,.nm,,mml'
Cisco Unified Border Element for Contact Center Solutions, available at:
http://cisco.com/en/US/docs/voice_ip_comm/unified_communications/cubecc.html
Note Due to a limitation in Cisco IOS, the CUBE does not support mid-call escalation or de-escalation from
audio to video, and vice versa.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
106
Gateway options
Cisco Unified Border Element
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
107
Gateway options
Cisco Unified Border Element
application
service survivability flash:survivability.tcl
param ccb id:192.168.1.52;loc:testbed04;trunks:10
dial-peer voice 700051 voip
description Comprehensive outbound route to CVP
destination-pattern 7000200T
session protocol sipv2
session target ipv4:192.168.1.20:5060
dtmf-relay rtp-nte
voice-class sip profiles 103
codec g711ulaw
no vad
• The following Survivability.tcl options are not applicable for use on the ASR because they are traditionally
for POTS dial-peers:
◦ani-dnis-split.
◦takeback-method.
◦-- *8.
◦-- hf.
◦icm-tbct.
◦digital-fxo.
• The following Survivability.tcl options are not supported: aa-name, standalone, and standalone-isntime.
◦The aa-name option is not supported because CME auto-attendant service is not supported on ASR.
◦The standalone and standalone-isntime options are not supported because there is no support for
VXML on ASR.
• ASR 1000 does not terminate the TDM trunks. Therefore, the following TDM Gateway features do not
apply to ASR 1000:
• PSTN Gateway trunk and DS0 information for SIP calls to ICM.
• Resource Availability Indication (RAI) of DS0 trunk resources via SIP OPTIONS message to
ICM.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
108
Gateway options
Cisco Unified Border Element
Note Because ASR 1000 represents the introduction of new equipment, to ensure success of ASR 1000
deployments, any UCCE/CVP contact center integration that utilizes the ASR 1000 requires an Assessment
to Quality (A2Q) review. This review will be required for new UCCE customers, as well as existing UCCE
customers who desire to move to the ASR 1000.
Note Using a CUBE between Cisco Unified CM and CVP is not supported. This applies to using either Cisco
ASR 1000 Series or Cisco ISR as a Unified Border Element.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
109
Gateway options
Mixed G.729 and G.711 codec support
Gateway choices
Unified CVP uses gateways for two purposes: TDM ingress and VoiceXML rendering. Any Cisco gateway
that is supported by Unified CVP can usually be used for either purpose or both. However, depending on your
deployment model, you might need only one of the functions:
• Model #1: Standalone Self-Service
All calls use both ingress and VoiceXML.
• Model #2: Call Director
All calls use ingress only.
• Model #3a: Comprehensive Using Unified ICM Micro-Apps
All calls use ingress, and some calls use VoiceXML.
• Model #3b: Comprehensive Using Unified CVP VXML Server
All calls use ingress, and some calls use VoiceXML.
• Model #4: VRU Only with NIC Controlled Routing
All calls use both ingress and VoiceXML.
In cases where both ingress and VoiceXML are required, you can choose to run both functions on the same
gateways or you can choose to designate some gateways for ingress and others for VoiceXML. Use the
following guidelines to determine whether the functions should be combined or split:
• In classical branch office deployments, where the call needs to be queued at the branch where it arrived,
ingress and VoiceXML functions must always be combined.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
110
Gateway options
Gateway sizing
• In cases where a large number of non-CVP PSTN connections share the gateways, it is recommended
to dedicated Ingress for that purpose, and use separate VXML gateways.
• VoiceXML-only gateways are less costly because they do not require DSP farms or TDM cards. Use a
spreadsheet to determine which way you obtain the best price.
• With relatively low call volume, it is usually better to combine the functions for redundancy purposes.
Two combined gateways are better than one of each because the loss of one gateway still allows calls
to be processed, though at a lower capacity.
The next decision is whether to use Cisco Integrated Service Router (ISR) gateways (Cisco 2800, 2900 series
routers), ISGR-G2 (3800, or 3900 Series routers), or the Cisco AS5x00 Series Gateways. Guidelines state
that you use ISR gateways only in branch office sites, whereas AS5x00 Series gateways should be used in
centralized data center sites.
Sometimes it is difficult to determine what constitutes a branch office, and therefore which gateway is used.
The following guidelines can help with that determination:
• The classical definition of branch offices, for which you should use ISR gateways, includes:
◦Multiple sites where TDM calls will be arriving from the PSTN.
◦Those sites are separated from the data centers where most of the Unified CVP equipment resides.
◦One gateway is used at each site.
• If you have sites where you will be stacking multiple gateways for any reason, then those sites are data
center sites and should use Cisco AS5x00 Series gateways.
For more information on the Cisco AS5x00 Series Gateways, refer to the technical specifications available
at http://www.cisco.com/en/US/products/hw/univgate/ps501/index.html.
For more information on the Cisco Integrated Service Routers (ISRs), refer to the documentation available at
http://www.cisco.com/en/US/products/hw/routers/index.html.
Gateway sizing
Individual Cisco gateways can handle various call capacities depending on whether they are doing ingress
only, VoiceXML only, or a combination of the two. Gateways doing VoiceXML activities also have different
call capacities depending on whether or not they are supporting ASR or TTS activities and on the type of
VoiceXML application being executed. For instance, an intensive JavaScript application reduces call capacity.
Gateways doing HTTPS experience lower call capacity as compared to HTTP.
In general, gateways performing ingress-only can be sized according to the number of TDM cables that can
be connected to them. For gateways that are combined or VoiceXML-only, it is important to ensure that the
overall CPU usage is less than 75% on average. The numbers in the following table are based on Unified CVP
VoiceXML documents; other applications that generate more complex VoiceXML documents have a higher
impact on performance. The following factors affect CPU usage:
• Calls per second (cps)
• Maximum concurrent calls
• Maximum concurrent VoiceXML sessions
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
111
Gateway options
Gateway sizing
Before sizing the voice gateways, use the Unified CCE Resource Calculator to determine the maximum number
of trunks (DS0s) and VoiceXML IVR ports needed to support the entire solution.
For almost all Unified CVP deployment models, sizing is based on the maximum number of concurrent
VoiceXML sessions and VoIP calls. The following tables list this information for different IOS release versions
as follows:
• Table 1: For Cisco IOS Release 15.1.4.M7 and greater Maximum Number of VoiceXML Sessions
supported by Cisco Voice Gateways, on page 112 (IOS version 15.1.4.M7)
• The following tables (IOS version 15.1.4.M7 and greater):
◦Table 2: For Cisco IOS Release 15.1.4.M7 and greater Maximum Number of VoiceXML Sessions
Supported by Cisco Voice Gateways Executing Intensive JavaScript Applications
◦Table 3: For Cisco IOS Release 15.1.4.M7 and greater Maximum Number of VoiceXML Sessions
Supported by Cisco Voice Gateways Using HTTPS
Table 1: For Cisco IOS Release 15.1.4.M7 and greater Maximum Number of VoiceXML Sessions supported by Cisco Voice
Gateways
2901 12 8 9 6 2 GB
2911 60 40 47 31 2 GB
2921 90 60 71 48 2 GB
2951 120 80 95 64 2 GB
Based on ISO 15.1.4.M7, G.711, basic calls, Ethernet egress, CPU NTE 75% (5000XM
80%)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
112
Gateway options
Gateway sizing
Table 2: For Cisco IOS Release 15.1.4.M7 and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice
Gateways Executing Intensive JavaScript Applications
Table 3: For Cisco IOS Release 15.1.4.M7 and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice
Gateways Using HTTPS
Note The performance numbers listed in the Table 6, Table 7 and Table 8 are equivalent for MRCPv1 and
MRCPv2.
Note The following note does not apply to Cisco IOS Release 15.0.1M and IOS 15.1.4.M7.
Note Performance numbers for the Cisco 3825 Series and 3845 Series Integrated Services Routers (ISRs) are
higher when the voice gateway and the VoiceXML gateway functions reside on the same router (co-resident
deployment). When the call is connected to the VoiceXML gateway from the ingress voice gateway, the
media flows directly between the two. In a co-resident deployment, the gateway does not have to spend
CPU cycles to packetize and de-packetize the RTP packets. Hence, by saving these CPU cycles, the
gateway can support increased VoiceXML sessions.
The numbers in Table 1: For Cisco IOS Release 15.1.4.M7 and greater Maximum Number of VoiceXML
Sessions supported by Cisco Voice Gateways, Table 2: For Cisco IOS Release 15.1.4.M7 and greater Maximum
Number of VoiceXML Sessions Supported by Cisco Voice Gateways Executing Intensive JavaScript
Applications, and Table 3: For Cisco IOS Release 15.1.4.M7 and greater Maximum Number of VoiceXML
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
113
Gateway options
Gateway sizing
Sessions Supported by Cisco Voice Gateways Using HTTPS assume the only activities running on the gateway
are VXML with basic routing and IP connectivity. If you intend to run additional applications such as fax,
security, normal business calls, and so forth, then the capacity numbers presented here should be prorated
accordingly. The numbers mentioned in the "Voice Gateway and VoiceXML" column mean that the indicated
number of VoiceXML sessions and voice calls can be supported simultaneous on the same gateway. For
example, in Table 1: For Cisco IOS Release 15.1.4.M7 and greater Maximum Number of VoiceXML Sessions
supported by Cisco Voice Gateways the AS5350XM can terminate a maximum of 240 PSTN calls, and those
240 PSTN calls could have 240 corresponding VoiceXML sessions at the same time.
The numbers represent performance with scripts generated by Unified CVP Studio running on the Unified CVP
VXML Server. Other VoiceXML applications might perform differently. These figures apply if the CPU
utilization does not exceed more than 75%, Voice Activity Detection (VAD) is turned off, and your system
is running VoiceXML v2.0 and MRCP v2 with Cisco IOS Release 15.1.4.M7 and greater.
Note These performance numbers are accurate when used with either the Cisco Call Server or Cisco Unified CVP
VXML Server. Performance can, and often does, vary with different applications. Performance from
external VoiceXML applications (such as Nuance OSDMs) might not be representative of the performance
when interoperating with non-Cisco applications. You must ensure that the CPU usage is less than 75%
on average and that adequate memory is available on Cisco gateways at full load when running external
VoiceXML applications. Users should contact the application provider of the desired VoiceXML application
for performance and availability information. Be aware that external VoiceXML applications are not
provided by Cisco, and Cisco makes no claims or warranties regarding the performance, stability, or
feature capabilities of the application when interoperating in a Cisco environment.
Note Cisco does not specifically test or qualify mixes of traffic because there are infinite combinations. All
numbers should be seen as guidelines only and will vary from one implementation to the next based on
configurations and traffic patterns. It is recommended that the systems be engineered for worst-case traffic
(all ASR) if it is not known or cannot be predicted what kinds of calls will be offered to the VXML
gateway.
If you run VoiceXML on one of the Cisco 2900 and 3900 Series gateways, additional licenses (FL-VXML-1
or FL-VXML-12) are required.
Also consult the following links to ensure that the concurrent call load and call arrival rates do not exceed the
listed capacities:
• Model Comparison:
http://www.cisco.com/en/US/products/ps10536/prod_series_comparison.html
• Gateway Sizing for Contact Center Traffic:
http://cisco.biz/en/US/docs/voice_ip_comm/cucm/srnd/8x/gateways.html#wp1043594
In addition to these capacities, also consider how much DRAM and flash memory to order. The capacity that
comes with the machine by default is usually sufficient for most purposes. However, if your application
requires large numbers of distinct .wav files (as with complex self-service applications) or if your application
has unusually large .wav files (as with extended voice messages or music files), you might want to increase
the amount of DRAM in order to accommodate more want to expand your flash memory order. The use of
DRAM for prompt caching is discussed in detail in the chapter on Media file options, on page 143.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
114
Gateway options
Using MGCP gateways
Note HTTP cache can only be extended to100 MB in the current IOS versions.
When sending calls through Unified CM to Unified CVP, the following guidelines apply:
• The Unified CVP survivability.tcl script cannot be used in this solution. If the remote site is disconnected
from the central site, the call will be dropped.
• There will be an additional hit on the performance of Unified CM. This is because, in a "normal" Unified
CVP deployment, Unified CM resources are not used until the call is sent to the agent. In this model,
Unified CM resources are used for all calls to Unified CVP, even if they terminate in self-service. This
is in addition to the calls that are extended to agents. If all calls are eventually extended to an agent, the
performance impact on Unified CM is approximately double that of a "normal" Unified CVP deployment.
This factor alone typically limits this scenario to small call centers only.
• In order to queue calls at the edge, you must use the sigdigits feature in Unified CVP to ensure that the
calls are queued at the appropriate site or VXML gateway. For more information on how the sigdigits
feature works, see the chapters on Distributed deployments, on page 33, and Unified CVP design for
high availability, on page 41.
Note The Cisco Unified CVP provides the flexibility to add, modify, remove or deploy Unified CVP in many
scenarios to facilitate interoperability with third-party devices. Not all SIP service providers support
advanced features such as REFER, 302 Redirect Messages, DTMF-based take-back-and-transfer, or data
transport (UUI, GTD, NSS, etc). Please verify before planning on deploying these capabilities. Refer to
the interoperability note available at the following location for information on the interoperability support
for SBC when deployed in place of Cisco CUBE. http://www.cisco.com/en/US/solutions/ns340/ns414/
ns728/voice_portal.html
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
115
Gateway options
Using MGCP gateways
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
116
CHAPTER 8
Unified CVP VXML server design implications
Note Cisco Unified CVP VXML Server is coresident with the Call Server and Media Server.
When gauging Unified CVP VXML Server performance, consider the following key aspects:
• QoS and network bandwidth between the Web application server and the voice gateway.
See Network infrastructure considerations, on page 119, for more details.
• Performance on the Unified CVP VXML Server.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
117
Unified CVP VXML server design implications
Multi-language support
The Hardware and System Software Specification for Cisco Unified CVP (formerly called the Bill of
Materials), available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/prod_technical_
reference_list.html, specifies the supported hardware for a Unified CVP VXML Server.
• Use of prerecorded audio versus Text-to-Speech (TTS)
Voice user-interface applications tend to use prerecorded audio files wherever possible. Recorded audio
sounds much better than TTS. Prerecorded audio file quality must be designed so that it does not impact
download time and browser interpretation. Make recordings in 8-bit mu-law 8 kHz format.
• Audio file caching
Make sure the voice gateway is set to cache audio content to prevent delays from having to download
files from the media source. For more details about prompt management on supported gateways, see
Cisco IOS caching and streaming configuration, on page 146.
• Use of grammars
A voice application, like any user-centric application, is prone to certain problems that might be discovered
only through formal usability testing or observation of the application in use. Poor speech recognition
accuracy is one type of problem common to voice applications, and a problem most often caused by
poor grammar implementation. When users mispronounce words or say things that the grammar designer
does not expect, the recognizer cannot match their input against the grammar. Poorly designed grammars
containing many difficult-to-distinguish entries also results in many mis-recognized inputs, leading to
decreased performance on the Unified CVP VXML Server. Grammar tuning is the process of improving
recognition accuracy by modifying a grammar based on an analysis of its performance.
Multi-language support
The Cisco IOS Voice Browser or the Media Resource Control Protocol (MRCP) specification does not impose
restrictions on support for multiple languages. However, there might be restrictions on the automatic speech
recognition (ASR) or TTS server. Check with your preferred ASR or TTS vendor about their support for your
languages before preparing a multilingual application.
You can dynamically change the ASR server value by using the command cisco property com.cisco.asr-server
in the VoiceVXML script. This property overrides any previous value set by the VoiceXML script.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
118
CHAPTER 9
Network infrastructure considerations
This chapter presents deployment characteristics and provisioning requirements of the Unified CVP network.
Provisioning guidelines are presented for network traffic flows between remote components over the WAN,
including recommendations for applying proper Quality of Service (QoS) to WAN traffic flows.
For the most current information on network considerations, refer to the sections on deployment models,
bandwidth, and QoS presented in the latest version of the Cisco Unified Contact Center Enterprise Solution
Reference Network Design (SRND), available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html
This chapter covers the following topics:
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
119
Network infrastructure considerations
Unified CVP network architecture
• In a distributed Unified CVP deployment, when the ingress gateways are separated from the Unified
CVP servers by a WAN.
• In Unified CVP deployments where the ingress gateway and the agent are separated over a WAN. The
agent can be a TDM ACD agent or a Unified CCE agent.
Unlike Unified ICM, Unified CVP has a very simple view of QoS:
• Unified CVP has no concept of a private WAN network structure. All WAN activity, when required, is
conducted on a converged WAN network structure.
• Unified CVP does not use separate IP addresses for high and low priority traffic.
Adequate bandwidth provisioning is an important component in the success of Unified CVP deployments.
Bandwidth guidelines and examples are provided in this chapter to help with provisioning the required
bandwidth.
Note RSVP is a protocol used for call admission control, and it is used by the routers in the network to reserve
bandwidth for calls. RSVP is not qualified for call control signaling via the Unified CVP Call Server in
SIP. The recommended solution for Call Admission Control is to employ Locations configuration on CVP
and in UCM. Refer to Enhanced Location Call Admission Control, on page 127.
Voice traffic
Voice calls consist of Real-Time Transport Protocol (RTP) packets that contain actual voice samples. RTP
packets are transmitted in the following cases:
• Between the ingress PSTN gateway or originating IP phone and one of the following:
◦Another IP phone, such as an agent
The destination phone might or might not be co-located with the ingress gateway or calling IP
phone, and the connection can be over a WAN or LAN.
◦An egress gateway front-ending a TDM ACD (for legacy ACDs or IVRs)
The egress gateway might or might not be co-located with the ingress gateway, and the connection
can be over a WAN or LAN.
◦A VoiceXML gateway performing prompt-and-collect treatment
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
120
Network infrastructure considerations
Unified CVP network architecture
The VoiceXML gateway is usually the same as the ingress gateway, but it can be different. In
either case, both the ingress and VoiceXML gateways are typically co-located (located on the same
LAN). The connection is typically over a LAN but can be over a WAN.
• Between the VoiceXML gateway and the ASR or TTS server. The RTP stream between the VoiceXML
gateway and ASR/TTS server must be G.711.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
121
Network infrastructure considerations
Unified CVP network architecture
Note Currently approved deployment designs do not support SIP for interoperability between
the PGW and Unified CVP. If your design requires this functionality, contact the Cisco
Assessment to Quality (A2Q) team.
GED-125
The Unified CVP Call Server and the Unified ICM VRU PG communicate using the GED-125 protocol. The
GED-125 protocol includes:
• Messages that control the caller experience, such as notification when a call arrives
• Instructions to transfer or disconnect the caller
• Instructions that control the IVR treatment the caller experiences
The VRU PG normally connects to Unified CVP over a LAN connection. However, in deployments that use
clustering over the WAN, it is possible for Unified CVP to connect to the redundant VRU PG across the
WAN.
At this time, no tool exists that specifically addresses communications between the VRU PG and Unified CVP.
However, bandwidth consumed between the Unified ICM Central Controller and VRU PG is very similar to
the bandwidth consumed between the VRU PG and Unified CVP.
The VRU Peripheral Gateway to ICM Central Controller Bandwidth Calculator tool is available (with proper
login authentication) through the Cisco Steps to Success Portal at:
http://tools.cisco.com/s2s/HomePage.do?method=browseHomePage
You can also access the Bandwidth Calculator directly (with proper login authentication) at:
http://tools.cisco.com/s2slv2/ViewDocument?docName=EXT-AS-100901
If the VRU PGs are split across the WAN, the total bandwidth required would be double what the calculator
tool reports: once for Unified ICM Central Controller to VRU PG and once for VRU PG to Unified CVP.
Media Resource Control Protocol (MRCP)
The VoiceXML gateway communicates with ASR/TTS servers using Media Resource Control Protocol
(MRCP) v1.0 and v2 as well. This protocol currently works with Real-Time Streaming Protocol (RTSP) to
help establish control connections to the ASR/TTS server such as Nuance. The connection can be over the
LAN or WAN.
ICM Central Controller to Unified CVP VRU PG
No tool exists that specifically addresses communications between the Unified ICM Central Controller and
the Unified CVP VRU PG. Testing has shown, however, that the tool for calculating bandwidth needed
between the Unified ICM Central Controller and the IP IVR PG also produces accurate measurements for
Unified CVP if you perform the following substitution in one field:
For the field labeled Average number of RUN VRU SCRIPT nodes, substitute the number of Unified ICM
script nodes that interact with Unified CVP. Nodes that can interact with Unified CVP are Run External Script,
Label, Divert Label, Queue to Skill Group, Queue to Agent, Agent, Release, Send to VRU, and Translation
Route to VRU.
This bandwidth calculator tool is available (with proper login authentication) at:
http://tools.cisco.com/s2slv2/ViewDocument?docName=EXT-AS-100901
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
122
Network infrastructure considerations
Bandwidth sizing
Data traffic
Data traffic includes VoiceXML documents and prerecorded media files returned as a result of HTTP requests
executed by the VoiceXML gateway. Specifically:
• The VoiceXML gateway requests media files in an HTTP request to a media file server. The media
server response returns the media file in the body of the HTTP message. The VoiceXML gateway then
converts the media files to RTP packets and plays them to the caller. The connection in this case can be
over a WAN or LAN.
• The VoiceXML gateway requests VoiceXML documents from either the Unified CVP VXML Server
or the Unified CVP IVR Service. The connection in this case can be over a WAN or LAN.
This chapter focuses primarily on the types of data flows and bandwidth used between a remote ingress
gateway and the components with which it interfaces:
• Unified CVP VXML Server
• Unified CVP Call Server IVR Service
• Unified CVP Call Server SIP Service
• IP phones
• Media servers
• Egress gateways
• ASR or TTS servers
Guidelines and examples are presented to help estimate required bandwidth and, where applicable, provision
QoS for these network segments.
Bandwidth sizing
Most of the bandwidth requirements in a Unified CVP solution occur in a Distributed Unified CVP topology,
due primarily to the fact that the ingress and/or VoiceXML gateway is separated from the servers that provide
it with media files, VoiceXML documents, and call control signaling. For purposes of the following discussion,
assume all calls to a branch begin with one minute of IVR treatment followed by a single transfer to an agent
that also lasts one minute. Each branch has 20 agents, and each agent handles 30 calls per hour for a total of
600 calls per hour per branch. The call average rate is therefore 0.166 calls per second (cps) per branch.
Note that even a slight change in these variables might have a large impact on sizing. It is important to
remember that .166 calls per second is an average for the entire hour. Typically, calls do not come in uniformly
across an entire hour, and there are usually peaks and valleys within the busy hour. Try to find the busiest
traffic period, and calculate the call arrival rate based on the worst-case scenario.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
123
Network infrastructure considerations
Media file retrieval
played to the caller. The VoiceXML documents vary in size, depending on the type of prompt being used;
menu prompts with many selections are much larger than a simple prompt that simply plays an announcement.
On average, a VoiceXML document between the Unified CVP Call Server or Unified CVP VXML Server
and the gateway is about 7 kilobytes. You can calculate the bandwidth used by approximating the number of
prompts that will be used per call, per minute. The calculation, for this example, is as follows:
7,000 bytes * 8 bits = 56,000 bits per prompt
(.166 call/second) * (56,000 bit/prompt) * (# of prompts / call) = bps per branch
However, if you are going to use a more complex application that uses many menu prompts (more than the
average estimated above) or if you want to calculate the bandwidth more exactly, you can use the VoiceXML
document sizes listed in the following table to calculate the amount of bandwidth needed. The document sizes
in the following table are measured from the Unified CVP VXML Server to the VoiceXML Gateway.
Query gateway for Call-ID and GUID (one required 1,300 bytes
per call)
Menu (increases in size with number of menu choices) 1,000 bytes + 2,000 bytes per menu choice
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
124
Network infrastructure considerations
SIP signaling
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_
list.html
Assume that there is a total of 50 prompts, with an average size of 50 kB and a refresh interval of 15 minutes.
The bandwidth usage would then be:
(50 prompts) * (50,000 bytes/prompt) * (8 bits/byte) = 20,000,000 bits
(20,000,000 bits) / (900 secs) = 22.2 average kbps per branch
SIP signaling
SIP is a text-based protocol. The typical SIP call flow uses about 17,000 bytes per call. Using the previous
bandwidth formulas based on calls per second, the average bandwidth usage would be:
(17,000 bytes/call) * (8 bits/byte) = 136,000 bits per call
(0.166 calls/second) * (136 kilobits/call) = 22.5 average kbps per branch
Note Cisco does not test or qualify speech applications in WAN environment. For guidelines on design, support
over WAN and associated caveats, see the vendor specific documentation.
TAC will be providing limited support (as in the case of any third party interoperability certified products)
on issues related to speech applications.
ASR or TTS is bandwidth intensive. ASR or TTS RTP and MRCP traffic is not tagged with QoS DSCP
markings, therefore it is necessary to use access control lists (ACLs) to classify and re-mark the traffic at the
remote site and central site.
Classifying RTP Media Traffic Between VoiceXML Gateways and ASR or TTS Servers
The RTP port range used by the VoiceXML gateway is the normal Cisco IOS RTP UDP port range of 16384
to 32767; however, the RTP UDP port range used by the ASR or TTS server can vary by OS and ASR or
TTS vendor. Itis possible to construct an ACL to match the traffic from the ASR or TTS server based on the
VoiceXML gateway UDP port range; but if possible, Cisco recommends finding the ports used by the ASR
or TTS server as well. The RTP traffic should be marked with DSCP EF so that it is placed in the priority
queue with other voice traffic.
The QoS priority queue must also be configured to support the maximum number of ASR or TTS sessions
anticipated. If a call admission control mechanism such as Cisco Unified CM locations or Resource Reservation
Protocol (RSVP) is used, this extra priority queue bandwidth should not be included when configuring the
locations or RSVP bandwidth. For example, if you want to support two ASR or TTS G.711 sessions (80 kbps
each) as well as four IP telephony phone calls using G.729 (24 kbps each), the priority queue total bandwidth
would be 256 kbps. The locations call admission control or RSVP bandwidth should be limited to only the
IP telephony bandwidth (96 kbps in this example). Configuring the locations or RSVP bandwidth with 256 kbps
would allow IP telephony calls to use all of the bandwidth and conflict with the ASR or TTS sessions.
Classifying MRCP Traffic Between VoiceXML Gateways and ASR or TTS Servers
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
125
Network infrastructure considerations
G.711 and G.729 voice traffic
The MRCP traffic is much easier to classify. ASR or TTS servers listen on TCP 554 for MRCP requests,
therefore this port should be used in ACLs to classify the traffic. The bandwidth used by MRCP can vary
depending on how often the application uses the ASR or TTS resource. MRCP uses about 2000 bytes per
interaction. If there is an ASR or TTS interaction every 3 seconds per call, you can calculate the average
bandwidth as follows:
(2000 bytes/interaction) * (20 interactions/minute) * (8 bits/byte) = 320,000 bits per minute per call
(320,000 bits per minute) / (60 seconds/minute) = 5.3 average kbps per branch
If you configure a maximum of 6 ASR or TTS sessions at any given time, then (6 * 5.3 kbps) = 32 average
kbps per branch.
Limiting the Maximum Number of ASR or TTS-Enabled Calls
It is possible to limit the number of calls enable for ASR or TTS so that, once the limit is reached, regular
DTMF prompt-and-collect can be used instead of rejecting the call altogether. In the following example,
assume 5559000 is the ASR or TTS DNIS and 5559001 is the DTMF DNIS. You can configure the ingress
gateway to do the ASR load limiting for you by changing the DNIS when you have exceeded maximum
connections allowed on the ASR or TTS VoIP dial peer.
voice translation-rule 3 rule 3 /5559000/ /5559001/
!
voice translation-profile change
translate called 3
!
!Primary dial-peer is ASR or TTS enabled DNIS in ICM script
dial-peer voice 9000 voip
max-conn 6
preference 1
destination-pattern 55590..
...
!
!As soon as 'max-conn' is exceeded, next preferred dial-peer will change
the DNIS to a DTMF prompt & collect ICM script
dial-peer voice 9001 voip
translation-profile outgoing change
preference 2
destination-pattern 55590..
...
!
Note 80 kbps is the rate for G.711 full-duplex with no VAD, including IP/RTP headers and no compression.
24 kbps is the rate for G.729 full-duplex with no VAD, including IP/RTP headers and no compression.
For more information on VoIP bandwidth usage, refer to the Voice Codec Bandwidth Calculator (login
authentication required), available at http://tools.cisco.com/Support/VBC/do/CodecCalc1.do.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
126
Network infrastructure considerations
Call admission control
Note Resource Reservation Protocol (RSVP) is a protocol used for call admission control, and it is used by the
routers in the network to reserve bandwidth for calls. RSVP is not qualified for call control signaling via
the Unified CVP Call Server in SIP. The recommended solution for Call Admission Control is to employ
Locations configuration on Unified CVP and in Unified CM.
For more information on RSVP, see the latest version of the Cisco Unified Communications SRND Based on
Cisco Unified Communications Manager, available at:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
127
Network infrastructure considerations
Enhanced Location Call Admission Control
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
128
Network infrastructure considerations
Enhanced Location Call Admission Control
Another advantage of this deployment configuration is that in the event of WAN link failure, the call can still
be routed locally using the CVP survivability application running on the pots dial-peer for TDM originated
calls.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
129
Network infrastructure considerations
Enhanced Location Call Admission Control
Design considerations
The following considerations apply when using ELCAC:
• The SIP trunk configured between Unified CVP and Unified CM should be associated with Phantom
location. A new location called shadow location is added in Unified CM 9.0 for inter cluster ELCAC,
but it is not supported in Unified CVP.
• A trunk configured with MTP required will not work with the ELCAC siteID feature. The reason is
when MTP is inserted, the media is terminated between the end point and MTP resource, not between
the two end points.
• If a MTP/Transcoder/TRP media resource is inserted by the Unified CM media layer, the incoming
location information is not used.
• If the inter cluster call is not looped back to the same cluster, the former behavior of Location CAC logic
will apply.
• Each site is uniquely identified by one siteID. Multiple gateways at the same site would need to align
to the same siteID, but if two clusters happen to use the same location name, then two siteIDs can map
to the same physical branch.
• A second Unified CM cluster may have the same location as the first cluster, but be required to use a
unique siteID on Unified CVP. You can define a route in the proxy server to send those cluster calls to
the common VXML gateway at the same location, but used by both the clusters.
• Each cluster would manage the bandwidth for devices in its cluster. If two clusters happen to use the
same physical location, then they would each separately manage the bandwidth for the phones that they
manage.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
130
Network infrastructure considerations
Recommended port usage and QoS settings
Unified CVP Call Server, SIP TCP or UDP Call CS3 24 200 ms
5060 Signaling
Network latency
Once proper application bandwidth and QOS policies are in place, another important consideration in a
distributed CVP deployment is that of network latency. With sufficient network bandwidth, the primary
contributor to latency is distance between the VoiceXML gateway and the Call Server or VXML Server.In
distributed CVP deployments, it is important to minimize this latency and to also understand its effect on
solution performance.
The primary effect of network latency between CVP components is on the end user calling experience. Call
signaling latency, with SIP, between the CVP Call Servers and voice gateways affects the call setup time and
may add a period of silence during this setup. This includes the initial call setup and subsequent transfers or
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
131
Network infrastructure considerations
Network latency
conferences that are part of the final call flow. VoiceXML application document download time is also
significantly affected by network latency and will have a pronounced effect on the ultimate caller experience.
Some recommendations are defined below to help minimize the effect of geographic separation of VXML
gateway from CVP VXML Server. However, in some cases depending on the business needs of the customer
callflows, it may still be necessary to co-locate the CVP VXMLServer with the remote VXML gateways.
The solution makes heavy use of the HTTP protocol to transfer VoiceXML documents and other media files
that are ultimately played to the caller. For the best end user calling experience, this HTTP traffic should be
treated with a priority higher than that of normal HTTP traffic in an enterprise network. The recommendation
is to treat this HTTP traffic the same as CVP call signaling traffic if possible. Measures that may be used to
work around latency issues include moving the VXML Server to the same local area as the VoiceXML
gateway, or using Wide Area Application Services (WAAS).
Otherwise, system configuration changes listed in the following bullets can help with WAN delays.
1 Provide audio to the caller during periods of silence
The following settings provide ringback and audio during times of dead air so that the caller does not
disconnect.
• On the survivability service, the setting for “wan-delay-ringback” can be set to 1 to add a ringback
tone during longer than normal call setup times with IVR.
• IVR subsystem settings for IVR.FetchAudioDelay and IVR.FetchAudioMinimum are added. They
are WAN Delay settings for when root doc fetch is delayed over the WAN link.
• Specify the value for IVR.FetchAudio as follows: IVR.Fetchaudio= flash:holdmusic.wav. Leave the
default empty so that nothing will be played in a normal scenario.
Note • A default setting of 2 is needed to avoid a blip sound in a normal network scenario.
• Setting WAN Delay to zero will have the effect of immediately playing holdmusic.wav and then
playing it for a minimum of 5 seconds.
• ECC variables such as user.microapp.fetchdelay, user.microapp.fetchminimum and
user.microapp.fetchaudio may be used to override these values in between invocations of
getSpeechExternal microapps.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
132
Network infrastructure considerations
TCP/UDP ports used by Unified CVP, voice, and VoiceXML gateways
Note Because the Unified CVP Operations Console Server uses dynamic ports for communication with other
components, it cannot be deployed outside of a firewall while the rest of the Unified CVP components
reside inside the firewall.
Table 6: TCP/UDP Ports Used by Unified CVP, Voice Gateways, and VoiceXML Gateways
Voice Gateway to Unified CVP Call Server SIP TCP or UDP 5060
Voice Gateway to Unified CVP Call Server TCP 8000 (non-SSL); TCP 8443 (SSL)
Voice Gateway to Unified CVP VXML Server TCP 7000 (non-SSL); TCP 7443 (SSL)
Unified CVP Call Server to Egress Voice Gateway SIP TCP or UDP 5060
Unified CVP Call Server to VoiceXML Gateway SIP TCP or UDP 5060
Unified CVP Call Server to SIP Proxy Server TCP or UDP 5060
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
133
Network infrastructure considerations
TCP/UDP ports used by Unified CVP, voice, and VoiceXML gateways
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
134
CHAPTER 10
Call transfer options
Designing for call transfers is one of the major steps required when designing a Unified CVP deployment.
There are numerous transfer options that can be used with Unified CVP. The goal of this chapter is to explain
each of the various options and to provide pros, cons, and considerations associated with each.
This chapter covers the following topics:
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
135
Call transfer options
Takeback-and-Transfer
• These transfers are blind, meaning that if the transfer fails for any reason, Unified ICM does not recover
control of the call. Router Requery is not supported.
• From the standpoint of Unified ICM reporting, Release Trunk Transfers cause the switch leg to terminate,
resulting in a TCD record being written to the database for the call even though the caller is still potentially
talking to an agent. This behavior differs from other types of transfers in which the TCD record does
not get finalized until the caller actually hangs up.
• Because the ingress trunk is released, you do not have to size gateways to include calls that have been
transferred in this way. This behavior differs from other types of transfers in which gateway resources
continue to be occupied until the caller hangs up.
• Because Unified CVP is no longer monitoring the call, you do not have to size Unified CVP Call Servers
to include calls that have been transferred in this way. Additionally, Unified CVP Call Director port
licenses are not required.
There are three signaling mechanisms available to trigger a release trunk transfer:
• Takeback-and-Transfer, on page 136
• Hookflash and wink, on page 136
• Two B Channel Transfer, on page 138
Takeback-and-Transfer
TNT (also known as Transfer Connect) is a transfer mechanism offered by some U.S. PSTN service providers
(such as AT&T and Verizon). With this transfer method, DTMF tones are outpulsed to the PSTN by Unified
CVP. These inband tones act as a signaling mechanism to the PSTN to request a transfer to be completed. A
typical DTMF sequence is *8xxxx, where xxxx represents a new routing label that the PSTN understands.
Upon detection of a TNT DTMF sequence, the PSTN drops the call leg to the ingress gateway port and then
re-routes the caller to a new PSTN location (such as a TDM ACD location).
This behavior might be necessary for a customer with existing ACD site(s) but no IVR, who wants to use
Unified CVP initially as just an IVR. Over time, the customer might want to transition agents from the TDM
ACD(s) to Unified CCE and use Unified CVP as an IVR, queueing point, and transfer pivot point (thus
eliminating the need for TNT services).
In Unified CVP deployments with the ICM, the DTMF routing label outpulsed could have been a Unified
ICM translation routing label to enable passing of call data to another Unified ICM peripheral (such as a TDM
ACD). In this scenario, Unified CVP views the call as completed, and Unified CVP call control is ended.
With TNT, if the transfer to the termination point fails, there is nothing Unified CVP can do to re-route the
call. While some TNT services do have the ability to re-route the call back to Unified CVP, Unified CVP sees
this call as a new call.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
136
Call transfer options
Hookflash and wink
or ACD transfers the caller to the new termination, which could be an ACD queue or service on that same
PBX or ACD.
This behavior is necessary for a customer with an existing ACD but no IVR, who wants to use Unified CVP
initially as an IVR logically installed on the line side of their existing PBX or ACD. Over time, the customer
might want to transition agents from the TDM ACD to Cisco Unified CCE and have the voice gateways
connected to the PSTN instead of the line side of the PBX or ACD. In Unified CVP deployments with Unified
ICM, the routing label could be a Unified ICM translation routing label. This label enables passing of call
data to the ACD service (and subsequently to the agent in a screen pop). With hookflash and wink, if the
transfer to the termination point fails, there is nothing Unified CVP can do to re-route the call. While some
PBX or ACD models do have the ability to re-route the call back to Unified CVP, Unified CVP sees this call
as a new call.
Hookflash transfer has been problematic in the past because the PBXs and the gateways have constrained
support for this feature. If at all possible, avoid using the PBX for Unified ICM switching, and terminate all
incoming calls on Unified CVP ingress gateways rather than on the PBX, thus allowing Unified CVP to route
calls to the PBX rather than the other way around.
However, if hookflash transfers are required, the following guidelines and notes apply:
• Cisco 1700 Series Gateways were not tested with hookflash transfers.
• Cisco 2800 and 3800 Series Gateways can support Analog FXO or Digital FXO (T1/CAS). This function
is considered line-side hookflash to the PBX, and it worked very well in tests with Avaya Definity G3.
(However, E&M is not supported at this time.) You can adjust the hookflash duration with the command
timing hookflash-out under the voice-port. This feature is useful if you have a PBX that has a
non-configurable hookflash duration, and it gives you the ability to adjust the hookflash duration on the
gateway side.
• Cisco 5x00 Series Gateways were tested with T1/CAS and the command e&m-fgb dtmf dnis. E&M is
considered “trunk-side hookflash” to the PBX, and not all switches support trunk-side hookflash (the
Avaya Definity G3 does not). Additionally, the hookflash duration on the Cisco 5x00 Series Gateways
is 200 ms, and you must configure the PBX for this same duration. This option varies with switch type,
and a proof-of-concept with the switch vendor is highly recommended.
• In Deployment Model #1, Standalone Self-Service, a TCL script is required to produce the hookflash.
A TCL script is provided with Unified CVP.
• For Digital FXO (T1 CAS) Trunks, Automatic Number Identification (ANI) is not available to the call
when it gets to Unified CVP. In some Unified CVP deployment models, the ICM might already know
the ANI if the call had been pre-routed there.
• For Digital FXO (T1 CAS) Trunks, Dialed Number Identification Service (DNIS) must be configured
on the gateway, based on the T1/E1 channel on which the call arrives. The PBX is programmed to route
certain DNIS calls over certain T1 trunks. Because the call arrives to the gateway on that trunk, you can
definitively configure its DNIS. The drawback to this approach is that the gateway trunk allocation must
be predetermined. You must know what percentage of calls arrive to which DNISs so that the trunk
groups on the gateway can be allocated accordingly.
An alternate method that can be used on some PBXs is a “converse on step”, whereby DTMF tones
indicating DNIS and ANI are sent to the IVR. This method requires a single main Unified ICM routing
script to input DNIS digits using a Get Data (GD) Microapplication and to invoke the correct sub-script
based on the collected DNIS digits. This method requires close coordination between Cisco, the PBX
vendor, and the customer, and it has not yet been tested.
• For FGB E&M Trunks in Cisco 5x100 series Gateways, ANI and DNIS can be sent by using “*” as the
delimiter. For example: *ANI*DNIS*. For Configuration details, see ANI/DNIS Delimiter for CAS Calls
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
137
Call transfer options
SIP Hookflash support
Design considerations
The following limitations apply to using the SIP Hookflash feature:
• This feature is only supported on 2X and 3X gateways. It is not supported on 5X gateways (e.g. 5400XM).
• Hookflash only applies to TDM originated calls. Once hookflash is invoked by Unified CVP, Unified
CVP is no longer in control of the call.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
138
Call transfer options
Network Transfer
In Unified CVP deployments with Unified ICM, Unified ICM provides all call control. VoiceXML call control
from the Unified CVP VXML Server is not supported when Unified ICM is deployed with Unified CVP.
Unified ICM Managed transfers transfer the call to a new termination point, which can be any of the following:
• A Cisco Unified Communications Manager phone
• An egress port on the same gateway as the ingress port
• A distant egress gateway that has a TDM connection to a TDM ACD or PBX (making use of toll bypass
features)
• A Unified CVP VoiceXML gateway for queuing or self-service activities
To terminate the call, the voice gateway selects an outgoing POTS or VoIP dial-peer based on the destination
specified by Unified ICM. When a Unified ICM VoIP transfer occurs, the ingress voice gateway port is not
released. If the termination point is an egress voice gateway, then a second voice gateway port is utilized.
Unified CVP continues to monitor the call, and Unified ICM also retains control of the call and can instruct
Unified CVP to transfer the call to a new destination.
This type of transfer is used when Unified CVP is used as a call treatment platform and queue point for Unified
CCE agents. Unified CVP could also be used to provide call treatment to front-end calls to TDM ACD locations
supported by Unified ICM. This type of transfer allows for calls to be transferred between peripherals supported
by Unified ICM, with full call context and without any return of the voice path.
Calls that are transferred in this way have the following characteristics:
• Unified ICM Network Transfer using Unified CVP as the routing client functions properly because
Unified CVP continues to control the call.
• These transfers are supervised, meaning that if the transfer fails for any reason, the Unified ICM routing
script does recover control via the Router Requery mechanism.
• From the standpoint of Unified ICM reporting, the switch leg does not terminate until the caller actually
hangs up. Thus, the TCD record that is written for the switch leg of the call encompasses the entire life
of the call, from initial ingress to hang-up.
• Because the ingress trunk is not released, you must size gateways to include calls that have been
transferred in this way.
• Because Unified CVP continues to monitor the call, you must size Unified CVP Call Servers to include
calls that have been transferred in this way. Additionally, Unified CVP Call Director port licenses are
required, except for calls that are connected to Cisco Unified Communications Manager agents.
Network Transfer
Unified CVP provides the capability to transfer calls to another destination after they have been answered by
an agent. This capability are referred to as Network Transfer.
When a call is transferred from Unified CVP to an agent, and that agent wants to transfer the call to another
agent, the agent can make that transfer using either the agent IP phone or agent desktop. Transfers from the
IP phone are made using CTI route points that point to a Unified ICME script. Transfers from the agent desktop
are made using the Dialed Number Plan.
There are two flags in Unified ICME to control the Network Transfer:
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
139
Call transfer options
SIP Refer transfer
• NetworkTransferEnabled — This is a flag in the Unified ICME script. If enabled, it instructs the
Unified ICM to save the information about the initial routing client (the routing client that sent the
NewCall route request).
• NetworkTransferPreferred — This flag is checked on the Unified CVP PG configuration. If it is checked,
then any route request from this routing client (where Unified ICME knows about the initial routing
client) will send the route response to the initial routing client instead of the routing client that sent the
route request.
If a caller would like to dial the same number regardless of a blind transfer, warm transfer, or conference,
then the following recommendations and best practices can be used:
• Do not enable the NetworkTransferEnable flag in the Unified ICME script.
• Any transfer or conference request from an agent must dial the CTI Route Point of the same Unified CCE
PG to preserve the call context during the transfer. Dialing the Route Pattern or CTI Route Point of
another PG will not preserve the call context.
• Always use SendToVru as the first node in the Unified ICME routing script.
• Extra ports are used during the consultation, blind transfer, or conference. They are released only when
the originating consultation is terminated.
Note Direct Refer transfer using label works only if Send To VRU node is used before the
refer.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
140
Call transfer options
Intelligent Network release trunk transfers
The SIP Refer transfer can be invoked after Unified CVP queue treatment has been provided to a caller. SIP
Refer transfers can be made to Cisco Unified Communications Manager or other SIP endpoints, such as a
SIP-enabled ACD.
Router requery on a failed SIP Refer transfer is supported using SIP with the Unified CVP, but only on calls
where the survivability service is not handling the SIP Refer request.
VoiceXML transfers
VoiceXML call control is supported only in standalone Unified CVP deployments (Deployment Model #1)
in which call control is provided by the Unified CVP VXML Server. Deployment Model #3b, which also
incorporates the Unified CVP VXML Server, does not support VoiceXML call control. In those and all Unified
ICM integrated deployments, Unified ICM must make all call control decisions.
The Unified CVP VXML Server can invoke three types of transfers: Release Trunk Transfers, VoiceXML
blind transfers, and VoiceXML bridged transfers. Release Trunk Transfers result in the incoming call being
released from the ingress voice gateway. VoiceXML blind transfers result in the call being bridged to an
egress voice gateway or a VoIP endpoint, but the Unified CVP VXML Server releases all subsequent call
control. VoiceXML bridged transfers result in the call being bridged to an egress voice gateway or a VoIP
endpoint, but the Unified CVP VXML Server retains call control so that it can return a caller to an IVR
application or transfer the caller to another termination point.
Release Trunk Transfers from the Unified CVP VXML Server are invoked using the subdialog_return
element. The Unified CVP VXML Server can invoke a TNT transfer, Two B Channel transfer, and
HookFlash/Wink transfers as well as SIP Refer transfers. For TDM Release Trunk Transfers (TNT, TBCT
and Hookflash/Wink), the VoiceXML gateway must be combined with the ingress gateway in order for the
Release Trunk Transfer to work.
VoiceXML blind and bridged transfers are invoked using the Transfer element in Cisco Unified Call Studio.
VoiceXML Transfers will transfer the call to any dial-peer that is configured in the gateway.
VoiceXML Blind Transfers differ from VoiceXML Bridged Transfers in the following ways:
• VoiceXML blind transfers do not support call progress supervision; Bridged transfers do. This means
that if a blind transfer fails, the Unified CVP VXML Server script does not recover control and cannot
attempt a different destination or take remedial action.
• VoiceXML blind transfers cause the Unified CVP VXML Server script to end. Always connect the
“done exit” branch from a Blind transfer node to a subdialog_return and a hang-up node.
Bridged transfers do not terminate the script. The Unified CVP VXML Server waits until either the ingress
or the destination call ends. The script ends only if the ingress call leg hangs up. If the destination call leg
hangs up first, the script recovers control and continues with additional self-service activity. Note that the
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
141
Call transfer options
VoiceXML transfers
Unified CVP VXML Server port license remains in use for the duration of a bridged transfer, even though
the script is not actually performing any processing.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
142
CHAPTER 11
Media file options
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
143
Media file options
Co-Resident Unified CVP Call Server, Media Server, and Unified CVP VXML Server
Note Unified CVP Call Server, Media Server, and Unified CVP VXML Server are coresident in the same server.
If your Unified CVP Call Server, Media Server, and Unified CVP VXML Server reside on the same hardware
server and you have multiple co-resident servers, Unified CVP does not automatically use the same physical
server for call control, VXML, and media file services. Just because the components are co-resident, that does
not force one component to use the other co-resident components, and it is just as likely to use the components
located on another server.
By default, the components are load-balanced across all of the physical servers and do not attempt to use the
same server for all of the services. Over the course of thousands of calls, all of the components on all of the
servers are load-balanced and equally utilized, but for one particular call it is possible to be using several
different physical servers. Because of this, for one particular call you can be using SIP call control on one
server, VoiceXML on another server, and the media files on yet another server.
You can simplify management and troubleshooting by configuring Unified CVP to use the same physical
server for all of these functions on a per-call basis. Of course, if there is only one server in the system, then
this is not a concern. The instructions in the following procedures show you how to configure Unified CVP
so that it does use components on the same physical server instead of load-balancing and using a random
server for each component.
Related Topics
Choose co-resident Unified CVP VXML Server in ICM Script Editor, on page 144
Choose co-resident Media Server in Cisco Unified Call Studio, on page 145
Choose co-resident Unified CVP VXML Server using Micro-Apps, on page 145
Procedure
Step 1 When setting up the media_server ECC variable that specifies your Unified CVP VXML Server in the ICM
script, use the Formula Editor to set the media_server ECC variable to
concatenate("http://",Call.RoutingClient,":7000/CVP").
Where Call.RoutingClient is the built-in call variable that ICM sets automatically for you. The routing client
name in ICM is not necessarily the same as the Unified CVP Server's hostname (and usually is not the same).
Step 2 You can then use the routing client name as a hostname in the VXML gateway.
However, do not use non-compliant characters such as an underscore as part of the hostname because the
router cannot translate the hostname to an IP address if it contains any non-complaint characters. Cisco also
recommends using the ip hostname strict command in the router to prevent the use of invalid characters in
the hostname. This will ensure that the hostname is acceptable to Unified CVP.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
144
Media file options
Choose co-resident Media Server in Cisco Unified Call Studio
Step 3 Configure the routing client hostname for every Unified CVP Server Routing Client.
Procedure
Step 1 In the ICM script, set one of the ToExtVXML[] array variables with the call.routingclient data, such as
“ServerName=call.routingclient”.
This variable will be passed to the Unified CVP VXML Server, and the variable will be stored in the session
data with the variable name ServerName.
Step 2 In Cisco Unified Call Studio, use a substitution to populate the Default Audio Path.
Add the Application_Modifier element found under the Context folder, and specify the Default Audio Path
under the Settings tab in the following format:
http://{Data.Session.ServerName}
Procedure
Step 1 When setting up the media_server ECC variable that specifies your Media server in the ICM script, use the
Formula Editor to set the media_server ECC variable to concatenate("http://",Call.RoutingClient).
Where Call.RoutingClient is the built-in call variable that ICM sets automatically for you. The routing client
name in ICM is not necessarily the same as the Unified CVP Server hostname (and usually is not the same).
Step 2 You can then use the name of the routing client as a hostname in the VoiceXML gateway.
However, do not use non-compliant characters such as an underscore as part of the hostname because the
router cannot translate the hostname to an IP address if it contains any non-complaint characters. Cisco also
recommends using the ip hostname strict command in the router to prevent the use of invalid characters in
the hostname. This will ensure that the hostname is acceptable to Unified CVP.
Step 3 Configure the routing client hostname for every Unified CVP Server Routing Client.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
145
Media file options
Bandwidth calculation for prompt retrieval
Cache types
There are two types of cache involved in storing media files: the IVR Media Player cache and the HTTP Client
cache. The HTTP Client cache is used for storing files that are downloaded from the HTTP server. In
non-streaming mode, the entire media file is stored inside the HTTP Client cache. In streaming mode, the first
chunk of the media file is stored in the HTTP Client cache and in the IVR cache, and all subsequent chunks
of the file are saved in the IVR cache only.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
146
Media file options
Cache types
Because of the above recommendation to use only non-streaming mode, the IVR prompt cache is never used
and the HTTP Client cache is the primary cache. The HTTP Client cache also has the advantage of being able
to store 100 MB of prompts, whereas the IVR cache is limited to 16 MB.
To configure the HTTP Client cache, use the following IOS commands:
http client cache memory file <1-10000>
Where <1-10000> is the file size in kilobytes. The default maximum file size is 50 kB, but the recommended
file size is 600 kB. Any file that is larger than the configured HTTP Client memory file size will not be cached.
http client cache memory pool <0-100000>
Where <0-100000> is the total memory size available for all prompts, expressed in kilobytes. A value of zero
disables HTTP caching. The default memory pool size for the HTTP Client cache is 10 Mb. The recommended
memory pool size is the total size of all prompts stored on the media server, up to 100 MB.
Cache aging
The HTTP Client manages its cache by the “freshness” of each cached entry. Whether a cached entry is fresh
or stale depends on two numbers: Age and FreshTime. Age is the elapsed time since the file was last downloaded
from the server. FreshTime is the duration that the file is expected to stay fresh in the HTTP Client cache
since the file was last downloaded.
There are several variables that can affect the FreshTime of a file, such as HTTP message headers from the
server and the cache refresh value configured using the command line interface (CLI).
The FreshTime of a file is determined in the following sequence:
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
147
Media file options
Cache types
1 When a file is downloaded from the HTTP server, if one of the HTTP message headers contains the
following:
Cache-Control: max-age = <value in seconds>
Then the max-age is used as the FreshTime for this file.
2 If step 1 does not apply, but the following two headers are included in the HTTP message:
Expires: <expiration date time>
Date: <Current date time>
Then the difference (Expires – Date) is used as the FreshTime for this file.
3 The HTTP/1.1 spec, RFC 2616 (HyperText Transport Protocol), recommends that either one of the HTTP
message headers as described in step 1 or 2 above should be present. If the server fails to send both 1 and
2 in its HTTP response, then take 10% of the difference between Date and Last-Modified from the following
message headers:
Last-Modified: <last-modified date time>
Date: <Current date time>
So the FreshTime for this file is calculated as:
FreshTime = 10% * ((Date) – (Last-Modified))
4 The CLI allows the user to assign a FreshTime value to the files as a provisional value in case none of the
message headers in steps 1 to 3 are present:
http client cache refresh <1-864000>
The default refresh value is 86400 seconds (24 hours). The configured HTTP Client cache refresh has no
effect on files when any of the message headers in steps 1 to 3 are present. But if the resultant FreshTime
from the CLI command calculation turns out to be less than the system default (which is 86400 seconds),
the FreshTime will be set to the default value (86400 seconds). This command is also not retroactive. That
is, the newly configured refresh value applies only to new incoming files, and it has no effect on the entries
already in the cache.
Stale files are refreshed on an as-needed basis only. This means that a stale cached entry can stay in the cache
for a long time until it is removed to make room for either a fresh copy of the same file or another file that
needs its memory space in the cache.
A stale cached entry is removed on an as-needed basis when all of the following conditions are true:
• The cached entry becomes stale.
• Its refresh count is zero (0); that is, the cached entry is not being used.
• Its memory space is needed to make room for other entries.
When the Age exceeds the FreshTime and the file needs to be played, the HTTP Client will check with the
media server to determine whether or not the file has been updated. When the HTTP Client sends a GET
request to the server, it uses a conditional GET to minimize its impact on network traffic. The GET request
includes an If-Modified-Since in the headers sent to the server. With this header, the server will return a 304
response code (Not Modified) or return the entire file if the file was indeed updated recently.
Note that this conditional GET applies only to non-streaming mode. Under streaming mode, the HTTP Client
always issues an unconditional GET; that is, no If-Modified-Since header is included in the GET request, thus
resulting in an unconditional reload for each GET in streaming mode.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
148
Media file options
Branch office implications
You can reload individual files into cache by issuing the following command:
test http client get http://10.0.0.130/en-us/sys/1.wav reload
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
149
Media file options
Branch office implications
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
150
CHAPTER 12
Managing, monitoring, and reporting functions
This chapter discusses various types of managing, monitoring, and reporting functions that can be used with
Unified CVP. It covers the following areas:
The Operations Console provides web-based interfaces for mapping and summarizing the solution network
configuration, setting and displaying configuration information on a batch or per-node basis, and storing local
copies of these configurations. The Operations Console also provides the ability to distribute Cisco Unified
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
151
Managing, monitoring, and reporting functions
DS0 trunk information for reporting
Call Studio applications to Unified CVP VXML Servers. Finally, the Operations Console provides basic
visual indications as to which managed components are functioning properly and which are having problems.
The Operations Console provides access to the following operations:
• Health Monitoring
You can use any SNMP-standard monitoring tool to get a detailed visual and tabular representation of
the health of the solution network. All Unified CVP product components and most Unified CVP solution
components also issue SNMP traps and statistics that can be delivered to any standard SNMP management
station or monitoring tool.
• Statistical Monitoring
Unified CVP infrastructure statistics include real-time and interval data on the Java Virtual Machine
(JVM), threading, and licensing. You can access these statistics by selecting the Control Center from
the System menu and then selecting a device. SNMP statistics can also be used.
• Direct administration of individual Cisco IOS-based components
Administrators can select an individual gateway for direct administration. Secure Shell (SSH) is used
for the gateway.
Note Internally, the Operations Console is occasionally referred to as the OAMP (Operate, Administer, Maintain,
Provision). The Operations Console manages individual components through the Unified CVP Resource
Manager, which is co-located with each managed Unified CVP component. The Resource Manager is
invisible to the end-user.
For more information on the Operations Console, see the Operations Console online help.
For information about the many new features for the Operations Console, see the new Operations Console
Guide for Cisco Unified Customer Voice Portal, available at: http://www.cisco.com/en/US/products/sw/
custcosw/ps1006/products_user_guide_list.html.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
152
Managing, monitoring, and reporting functions
Formal reporting
• Unified Intelligent Contact Management Enterprise (ICME) — shown in the Extended Call Context
(ECC) variable user.media.id and stored with all Termination Call Detail (TCD) and Route Call Detail
(RCD) records
• Automatic speech recognition (ASR) and text-to-speech (TTS) servers — shown in logs as the logging
tag
• Cisco Unified Communications Manager (Unified CM) — appears in the detailed logs
Thus, with proper levels of logging enabled, a call can be traced through all of the above components.
The Unified CVP logs are located in $CVP_HOME\logs. All of the Unified CVP logs roll over at 12:00 AM
every night, with the date as part of the filename. The format of the date is yyyy-mm-dd. All of these logs
will also roll over when they reach the predefined size limit of 100 MB and will have a number as part of the
filename extension. The number indicates which log it was for that day. When the entire logs directory reaches
a predefined size, old files are purged as necessary.
For more information on Unified CVP logging, see the Troubleshooting Guide for Cisco Unified Customer
Voice Portal, available at:
http://cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.html
Note Although Unified CVP components do not themselves synchronize machine times, customers must provide
a cross-component time synchronization mechanism, such as NTP, in order to assure accurate time stamps
for logging and reporting.
Formal reporting
The Unified CVP Reporting Server houses the Reporting Service and hosts an IBM Informix Dynamic Server
(IDS) database management system.
The Reporting Service provides historical reporting to a distributed self-service deployment in a call center
environment. The system is used to assist call center managers with call activity summary information to
manage daily operations. It can also provide operational analysis of various IVR applications.
The Reporting Service receives reporting data from the IVR Service, the SIP Service (if used), and the
Unified CVP VXML Server. (To capture the data from the Unified CVP VXML Server in the Unified CVP
Reporting Server's database, the Unified CVP VXML Server should be added by using the CVP VXML
Server device in the Unified CVP Operations Console Server (Operations Console). Selecting the VXML
Server Standalone device option will not capture the Unified CVP Reporting data.) As stated, the Reporting
Service is deployed together with an Informix database management system, and it transforms and writes this
reporting data into that database. The database schema is prescribed by the Unified CVP product, but the
schema is fully published so that customers can develop custom reports based on it.
The Reporting Service does not itself perform database administrative and maintenance activities such as
backups or purges. However, Unified CVP provides access to such maintenance tasks through the Operations
Console.
A single Reporting Server may be used in a deployment. If a single Reporting Server is used, it does not
necessary represent a single point of failure, because data safety and security are provided by the database
management system, and temporary outages are tolerated due to persistent buffering of information on the
source components.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
153
Managing, monitoring, and reporting functions
New reporting features
If more than one Reporting Server is used, be aware of the following restrictions:
• Each Unified CVP Call Server can be associated with only one Unified CVP Reporting Server.
• Reports cannot span multiple Informix databases.
Note Although Unified CVP components do not themselves synchronize machine times, customers must provide
a cross-component time synchronization mechanism, such as NTP, in order to assure accurate time stamps
for logging and reporting.
Note For reporting requirements related to the Courtesy Callback feature, see Courtesy Callback, on page 86.
The following is the list of features introduced in Unified CVP for the Unified CVP Reporting server (Reporting
Server).
1 Use the Reporting server to integrate with Cisco Unified Intelligence Center (Unified IC), enabling you
can run user friendly custom reports in the Unified IC environment. Unified IC templates are shipped with
all Unified CVP installations. These templates provide examples to report against Call, Application,
Callback, and Trunk Grout Utilization structures.
2 The Reporting Server provides increased data retention times by increasing the database space requirements:
Size for Unified CVP Release 8.0(1) and Above
• 100 GB
• 200 GB
Note For Unified CVP, the 2GB option for database size is not supported for production.
3 All database backup files are compressed and stored on the Reporting Server. The backup file is called
cvp_backup_data.gz and is stored on the %INFORMIXBACKUP% drive in a folder named cvp_db_backup.
4 Using the new System CLI, you can make the request to list log files on the Reporting Server (show log).
This request includes the Informix Database Server Engine logs. The show tech-support command also
includes these files.
5 Debug can now be turned on (or off) from within the System CLI with the debug level 3 (or 0) command.
When on, this command generates trace files for all administrative procedures, Purge, Statistics and
Aggregator. Care should be taken when turning this on because the trace files place an elevated burden
on the database.
6 Log data for administrative procedures are now written on a nightly basis to the %CVP_HOME%\logs
folder.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
154
Managing, monitoring, and reporting functions
Backup and restore
7 All StartDateTime, EndDateTime and EventDateTime values are stored as UTC in the various Reporting
Server tables.
8 The Reporting Server supports the Analysis Manager tool by allowing Analysis Manager to query the
Reporting Server as long as the user is authenticated. This user would typically be the cvp_dbuser login.
9 Transfer Type data and Transfer Labels for SIP call events are now stored in the call event table.
10 There is a data aggregator, which aggregates Unified CVP data in fifteen minute increments. Cisco Unified
Intelligence Center templates are created to capture this information. Call data is summarized at 15 minute,
daily, and weekly intervals. Dominant Path information is summarized at the same intervals. These
summaries are stored in the call_15, call_daily, call_weekly, applicationsummary_15,
applicationsummary_daily, and applicationsummary_weekly tables. Call data is summarized into the
Call_* structure, while an aggregate of each element invoked by each application is stored in the
ApplicationSummary_* structures.
11 Summary purge results are now logged in the log table.
12 Three new scheduled tasks have been added to the Reporting Server scheduler:
• CVPSummary, which builds summary tables.
• CVPCallArchive, which archives Callback data to maintain callback database performance.
• CVPLogDump, which extracts the administrative logs on a nightly basis.
13 All metadata for administrative processes has been moved into a new Ciscoadmin database. This removes
the tables from normal view of reporting users.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
155
Managing, monitoring, and reporting functions
More information
backup Unified CVP files to a different machine, preferably at a different location. You must assume all
security and backup management responsibilities.
Backups are compressed and stored on disk. During a backup, the oldest of two backups is removed and
replaced with the most recent backup while a new backup is made. In the event of a hardware failure during
a backup which results in a bad backup image, the older backup image can be used to replace the failed backup
image. Retention of older backups is beyond the scope of the Unified CVP Reporting Server and should be
managed by the customer.
Note Although it is possible to restore a backup image from one reporting server to another, such a restoration
is not supported with the CVP restore process.
Procedure
More information
For more information on Unified CVP reporting, see the Reporting Guide for Cisco Unified Customer Voice
Portal, available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_
list.html
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
156
Managing, monitoring, and reporting functions
Analysis Manager versus Unified System CLI
3 Licensing.
• Common Licensing for all CVP components (VXML Server, Call Server, Reporting Server, and
Call Studio all support FlexLM)
• 30 ports with 30 day expiration for Call Server and VXML Server evaluation licenses
• 10,000 database writes for Reporting Server evaluation licenses
• Licenses are only valid if the new license feature, CVP_SOFTWARE, is added. This new feature
will be used to ensure that you have the right to run the current version of CVP
The CVP WebServices Manager (WSM) is a new component that is installed automatically on all Unified
CVP Servers, including Remote Operations Manager (ROM) only installations. WSM interacts with various
subsystems and infrastructure handlers, consolidates the response, and publishes an xml response. WSM
supports secure authentication and data encryption on each of the interfaces.
The following diagram shows how the two interfaces interact with the WSM to provide information about
Unified CVP components.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
157
Managing, monitoring, and reporting functions
Analysis Manager versus Unified System CLI
Analysis Manager
The Web Service Manager supports all diagnostic (health and status) requests from the new Analysis Manager.
Analysis Manager provides end users a common interface for collecting health and status information for all
devices in its network topology. If Unified CVP is configured as a part of the solution, you can leverage the
WSM through the Analysis Manager to collect diagnostic details like server map, version information, licenses,
configuration, components, logs, traces, performance factors, platform information for each CVP Device on
a component and sub-component level. Users can set/reset debug levels using the Analysis Manager on a
component and sub-component level.
The Analysis Manager is part of UCM RTMT tool.
A new user with username wsmadmin is created during installation with the same password as the Unified
CVP Operations Console Server administrator user. Use wsmadmin to control access to the diagnostic portal
services.
Note For a discussion of the Analysis Manager, and a related discussion of the Analysis Call Path tool, see
Cisco Unified Analysis Manager available at: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/
service/8_0_1/rtmt/ch1_overview.html.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
158
Managing, monitoring, and reporting functions
Analysis Manager versus Unified System CLI
Unified CVP box by using System mode. There is no additional configuration needed for System
mode.
• The Unified System CLI uses a consistent command across multiple products and servers.
• The Unified System CLI can be executed as a Windows scheduled job.
The following diagram summaries the high-level commands for the Unified System CLI and shows the devices
and Unified Cisco products of which it interacts .
Figure 8: High-level commands for Unified System CLI
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
159
Managing, monitoring, and reporting functions
Analysis Manager versus Unified System CLI
• System mode.
◦In the System mode, the Unified System CLI automatically detects the Unified CVP Operations
Console (which acts as a seed device for the CLI) and then interacts with all of the devices in the
device list in the Operations Console to extract the solution topology automatically.
In this mode, the show version command shows the version information for all devices in the
device list.
◦All of the commands available in local mode for a single device are available in system mode.
◦The command syntax remains the same in system mode.
◦There are additional options to limit the system command option to certain device group, device
type, or list of servers.
In addition to the interactive user interface, the Unified System CLI can be used as a batch command. This
feature allows the System CLI to be used in scheduled jobs.
Q. Does Unified System CLI affect the performance of a the device(s) it queries?
A. Unified System CLI runs at a low priority; it uses idle CPU time on the System. It should not affect call
processing even if executed on a system running under load.
The response time from the given CLI command varies depending on the load of the system and the server
response time. The response time when there in no running load should be below 5 seconds for each server
for simple operations like show version, show license, show debug, and show perf. The response time
when there is no running load for show platform should be below 10 seconds for each server.
However, the response time cannot be determined for commands such as show trace, show log, show
sessions, show all, and show tech-support. The response for these commands can vary depending on the
data being transferred by the server.
Q. Can I redirect the output of a Unified System CLI command to a network drive?
A. Yes. Just specify the path to the network drive.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
160
Managing, monitoring, and reporting functions
Analysis Manager versus Unified System CLI
Application data:
admin:
Note For detailed information on using the Unified System CLI, see: Unified System CLI in the
Configuration Guide for Cisco Unified Customer Voice Portal, available at: http://www.cisco.com/
en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
161
Managing, monitoring, and reporting functions
Analysis Manager versus Unified System CLI
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
162
CHAPTER 13
Sizing
This chapter discusses how to determine how many physical machines to order and, in the case of gateways,
what kind to order.
This chapter covers the following topics:
Overview
When sizing a contact center, first determine the worst-case contact center profile in terms of the number of
calls that are in each state. In other words, if you were to observe the contact center at its busiest instant in
the busiest hour, how many calls would you find are in each of the following states:
Self-service
Calls that are executing applications using the Unified CVP VXML Server.
Talking
Calls that are connected to agents or to third-party TDM VRU applications.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
163
Sizing
Overview
In counting the number of calls that are in the talking state, count only calls that are using Unified CVP or
gateway resources. To determine whether a talking call is using resources, you must consider how the call
gets transferred to that VRU or agent. If the call was transferred using VoIP, it continues to use an ingress
gateway port and it continues to use a Unified CVP resource because Unified CVP continues to monitor the
call and provides the ability to retrieve it and re-deliver it at a later time. The same is true of calls that are
tromboned to a TDM target, using both an incoming and an outgoing TDM port on the same gateway or on
a different gateway (that is, toll bypass). Calls that are transferred to VRUs or agents in this manner are counted
as talking calls.
However, if the call was transferred through *8 TNT, hookflash, Two B Channel Transfer (TBCT), or an
ICM NIC, neither the gateway nor Unified CVP play any role in the call. Both components have reclaimed
their resources, therefore such calls are not counted as talking calls.
Finally, include in the overall call counts those calls that have been transferred back into Unified CVP for
queuing or self-service, using either blind or warm methods. For instance, if a warm transfer is used and the
agent is queued at Unified CVP during the post-route phase, the call would use two ports due to two separate
call control sessions at Unified CVP. Because these calls usually do not amount to more than 5% or 10% of
the overall call volume, it is easy to overlook them.
The definitions of these call states differ from the definitions used for port licensing purposes. The use of
automatic speech recognition (ASR) or text-to-speech (TTS) has nothing to do with delineating which calls
are in which state, as it does for licensing purposes. Similarly, the call state determination has nothing to do
with whether the agents are Unified CCE agents or ACD agents, nor does it matter whether the customer
intends to use the Unified CVP to retrieve and re-deliver the call to another agent or back into self-service.
Note The solution must be sized for the number of ports in use for calls in a talking state to agents. Even though
licenses for those ports do not have to be purchased when using Unified CCE agents, TDM agents do
require a Call Director license.
In addition to the overall snapshot profile of calls in the contact center, you must also consider the busiest
period call arrival rate in terms of calls per second. You need this information for the contact center as a whole
because it is hard to identify a true maximum arrival rate, you can use statistical means to arrive at this number.
Except in fairly small implementations, this is seldom the critical factor in determining sizing.
With the above data, you can begin sizing each component in the network. This section deals entirely with
the number and type of physical components required to support the Unified CVP system, but it does not
include any discussion of redundancy. For an understanding of how to extend these numbers to support higher
reliability, see Unified CVP design for high availability, on page 41.
Note In Unified CVP, the Call Server, VXML Server, and Media Server are combined as one installation.
Installing the CVP Server will install all three components. In the earlier versions, Call Server, VXML
Server, and Media Server could be installed on different machines.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
164
Sizing
Unified CVP Call Server
Note The Unified CVP Call Server (Call Server) is not used in Model #1: Standalone Self-Service. This section
does not apply to such deployments.
Unified CVP Call Servers are sized according to the number of calls they can handle, in addition to their
maximum call arrival rate.
Note For UCS performance numbers, see the Cisco doc-wiki link: http://docwiki.cisco.com/wiki/Virtualization_
for_Unified_CVP.
Note The following Example Call Server call rate calculations pertain to the UCS-7845-I3-CCE2 server.
Each Call Server can handle 1200 SIP calls. Each Call Server is further limited to a sustained call arrival rate
of 14 call per second (cps) for SIP. However, Model #4 is exempt from this limitation because the Call Server
in that model does not perform any SIP processing.
Each Call Server can handle 900 SIP calls. Each Call Server is further limited to a sustained call arrival rate
of 10 call per second (cps) for SIP. However, Model #4 is exempt from this limitation because the Call Server
in that model does not perform any SIP processing.
Specifically, the number of Call Servers required is the larger of:
((Self Service) + (Queue and Collect) + Talking) / 900, rounded up
or
(Average call arrival rate) / 10, rounded up.
In addition, calls delivered to the Cisco Unified Communications Manager cluster should be load-balanced
among the subscribers in the cluster and should not exceed 2 calls per second (cps) per subscriber.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
165
Sizing
Call Server Log Directory Size Estimate
Size your system using the methods detailed in the guide, then multiply the CPS by 75%:
• For example, 10 CPS on a UCS platform without Agent Greeting translates into 7.5 CPS on a Call Server
with Agent Greeting enabled.
• Ports required are calculated based on the CPS and duration of agent greeting, and must be accounted
from the total supported ports of a server.
VXML Server call rate calculations are shown in the examples below.
Unified CVP can also be configured to use HTTPS on the Unified VXML Server and on the Unified CVP
IVR Service. (IVR Service can generate very basic VoiceXML documents and is part of the Unified CVP
Call Server.) Due to the large processing overhead of HTTPS, the Tomcat application server can achieve a
maximum of only 100 simultaneous connections, depending on the configuration.
The following table provides simultaneous call information for HTTPS calls using various applications and
call flow models.
Note In all of the above scenarios, the Reporting and Datafeed options were disabled. Also note that Cisco IOS
Release 12.4(15)T5 or later release is required on the gateway to support the HTTPS option. (Mainline
Cisco IOS currently is not supported.)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
166
Sizing
VXML Gateway Agent Greeting Prompt Cache Sizing
5 second greeting - 40 KB i.e. ~25 greetings per MB. This typical use case scenario provides caching for
approximately 80*25 agent = 2000 agents with 80% space reserved for Agent Greeting.
60 second greeting - 480 KB i.e. ~2 greeting per MB. The worst case scenario provides caching for
approximately 50*2 agent = 100 agents with 50% space used for Agent Greeting.
Media Server hardware equivalent to the following (or better) is required to handle the above profile:
• UCS-C210M2-VCD2 with RAID 5 (media server only)
• UCS-C210M2-VCD2 with RAID 5 (media server only)
• UCS-C210M2-VCD2 with RAID 5 (co-located media/call server)
Note The following call rate calculations pertain to the UCS-C210M2-VCD2 server.
The following components can be installed on the same physical server (co-resident):
• Unified CVP Call Server (Call Server)
• Unified CVP VXML Server (VXML Server)
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
167
Sizing
• Media Server
A SIP-based co-resident server can handle 900 SIP calls as well as 900 VXML Server sessions simultaneously,
and it can handle a sustained call arrival rate of 10 calls per second.
Note This means you can run 900 ports of Call Server doing SIP call control, and 900 ports of VXML Server
on one server with a 900 port license.
The number of Unified CVP Call Servers required is the larger of:
((Self Service) + (Queue and Collect) + Talking) / 900, rounded up,
or
(Average call arrival rate) / 10, rounded up, except in the VRU-only model
The co-resident media server can be used for up to 900 calls, assuming that prompt caching is enabled in the
VoiceXML gateways. If multiple co-resident servers are to be used, you must load-balance across the co-resident
media servers in order to spread the load of the calls across all of the servers. To reduce the administrative
overhead of managing content on multiple media servers, separate dedicated media servers can be used.
This means you can run 900 ports of the Call Server with SIP call control, and 900 ports of the VXML Server,
all on one server with 900 port licenses.
Example
For example, assume that your deployment must be sized for 900 self-service ports, 500 queue and collect
ports, and 3700 simultaneous calls to agents.
Note In the above example definition, self-service means that a call requires SIP call control and runs an
application on the VXML Server. Queue and collect means that a call requires SIP call control and runs
an application using Microapps only on the Call Server.
The following example applies for VoiceXML and HTTP sessions only. The same values apply to both
co-resident and distributed deployments of Call Servers and VXML Servers.
The number of servers required using SIP call control would be as follows:
((Self Service) + (Queue and Collect) + Talking) / 900, rounded up
((900) + (500) + 3700) / 900 = 5 servers
If you use the Cisco Unified Border Element as a Session Border Controller (SBC) for flow-through calls to
handle VoiceXML requirements, then you must use the sizing information presented above. The Cisco Unified
Border Element is limited to the maximum number of simultaneous VoiceXML sessions or calls as outlined
above for the particular situation and hardware platform.
If you use the Cisco Unified Border Element as an SBC to handle flow-through calls only (no VoiceXML),
then take Voice Activity Detection (VAD) into consideration and see the sizing information in the Cisco
Unified Border Element Ordering Guide, available at:
http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/order_guide_c07_462222.html
Co-Resident Unified CVP Reporting Server and Unified CVP Call Server
The Unified CVP Reporting Server can also be co-resident with the Unified CVP Call Server, but only for
Standalone VoiceXML deployments. The Call Server is normally not needed in a Standalone VoiceXML
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
168
Sizing
Cisco Unified SIP Proxy
deployment; but if reporting is desired, a Call Server is required in order to send the reporting data from the
VXML Server to the Reporting Server. Thus, when the Reporting Server is co-resident with a Call Server,
the Call Server is not processing any SIP calls but is simply relaying reporting data from the VXML Server.
The co-resident Call Server does not have a significant impact on performance in this model, therefore the
sizing information in the section on the Unified CVP Reporting Server, on page 170, does not change.
Note If Unified Border Element is to be used as an SBC to handle flow-thru or flow-around calls only (no vxml),
with VAD in consideration, we can use the Unified Border Element Ordering Guide for sizing.
Note If Unified Border Element is to be used as an SBC for flow-thru or flow-around calls AND is to handle
vxml requirements, we must use the sizing information in the Cisco Unified Customer Voice Portal Design
Guide. Unified Border Element will be limited to the maximum number of simultaneous vxml sessions\calls
as outlined there for the particular situation and hardware platform.
Note The performance numbers published are with Record- Route enabled. The performance numbers will
reduce if Record-Route is disabled. Cisco does not recommend Record-Route to be enabled.
A CVP call, from the proxy server perspective, entails on average, 4 separate SIP calls:
• Caller inbound leg
• VXML outbound leg
• Ringtone outbound leg
• Agent outbound leg
The rule of thumb for Unified CVP and CUSP proxy sizing is to define 4 SIP calls for every 1 CVP call, so
the CPS rate will be 500 / 4 = 125. The overall number of active calls is a function of Call Rate (CPS) * call
handle time (CHT). Assuming an average call center call duration of 180 seconds (CHT), we will get an
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
169
Sizing
Unified CVP video service
overall active calls value of 22,500 calls. As one Call Server can handle approximately 900 simultaneous
calls, this would all allow a single CUSP proxy to handle the load of 18 CVP Call Servers, in this scenario.
A real world customer deployment will need to take into account the CPS and the CHT in order to size the
proxy for their solution.
To size the Reporting Server, you must first estimate how much reporting data is generated by your VoiceXML
application. The example applications and the tables in subsequent sections of this chapter help you to determine
the number of reporting messages generated for your application.
Once you have determined the number of reporting messages generated by your application, complete the
following steps for each VoiceXML application:
1 Estimate the calls per second that the application receives.
2 Estimate the number of reporting messages for your application.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
170
Sizing
Multiple Reporting Servers
Use the following equation to determine the number of reporting messages generated per second for each
VoiceXML application:
A# = %CPS * CPS * MSG
Where:
A# = the number of estimated reporting messages per second for an application. Complete one calculation
per application (A1, A2, …, An).
CPS = the number of calls per second.
%CPS = the percentage of calls that use this VoiceXML application.
MSG = the number of reporting messages this application generates. To determine the number of reporting
messages generated by your application, use the information provided in the sections on Reporting message
details, on page 172, and Example applications, on page 173.
Next, estimate the total number of reporting messages that your deployment will generate per second by
summing the values obtained from the previous calculation for each application:
A(total) = A1+ A2+…..+An
This is the total number of reporting messages generated per second by your VoiceXML applications. The
Cisco UCS-C210M2-VCD2 Reporting Servers can handle 420 messages per second. If the total number of
reporting messages per second for your deployment is less than 420, you can use a single Reporting Server.
If it is greater, you need to use multiple Reporting Servers and partition the VoiceXML applications to use
specific Reporting Servers.
For more information on these requirements, see the Reporting Guide for Cisco Unified Customer Voice
Portal, available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_
list.html
When designing Unified CVP deployments with multiple Reporting Servers, observe the following guidelines:
• Subdivide applications that generate more combined call processing and application messages than are
supported by one Reporting Server.
• VoiceXML can be filtered, and filtering out non-interesting data creates more usable data repositories
that support higher message volume.
• Configure the dial plan and/or other available means to direct the incoming calls to the appropriate Call
Server and VXML Server.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
171
Sizing
Reporting message details
If you need to combine data from multiple databases, possible options may include:
• Exporting reporting data to Excel, comma separated values (CSV) files, or another format that allows
data to be combined out side of the database
• Exporting reporting data to CSV files and importing it into a customer-supplied database
• Extracting data to a customer-supplied data warehouse and running reports against that data
End 2
Subdialog_start 2
Subdialog_return 2
Hotlink 2
HotEvent 2
Flag 2
Action 2
Decision 2
Application Transfer 2
VoiceXML Error 2
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
172
Sizing
Example applications
LeaveQueue 2
Callback_Disconnect_Caller 3
Callback_Add 4
Callback_Get_Status 4
Callback_Set_Queue_Defaults 4
Callback_Update_Status 4
Callback_Enter_Queue 5
Callback_Reconnect 5
Callback_Validate 6
Form 10
Digit_with_confirm 20
Currency_with_confirm 20
ReqICMLabel 30
Note These elements are required in every application and cannot be filtered.
Example applications
This section presents some examples of applications that can be used to estimate the number of reporting
messages that will be generated by your particular application.
Low Complexity
Total: 16 reporting messages per call.
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
173
Sizing
Example applications
Subdialog_start 2
Play element 2
Play element 2
Play element 2
Play element 2
Subdialog_end 2
End 2
Subdialog_strart 2
Play element 2
Get input 5
Play element 2
Get input 5
Form 10
Input 5
Subdialog_end 2
End 2
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
174
Sizing
Example applications
Subdialog_strart 2
Play element 2
Get input 9
Play element 2
Get input 9
Form 10
Input 9
Subdialog_end 2
End 2
Subdialog_strart 2
Icmrequrestlabel 30
Form 10
ASR capture 9
Form 10
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
175
Sizing
Example applications
End 2
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
176
INDEX
A calls 13, 22, 23, 24, 25, 27, 28, 30, 36, 37, 38, 44, 51, 52, 56, 59, 60, 62, 63,
64, 75, 77, 95, 96, 97, 120, 121, 125, 135, 152, 163
ACD 77 admission control 37
admission control for calls 37 control of 23, 25, 28
aging cache 147 control traffic 121
Application Content Engine (ACE) 12 disposition of 44, 52, 56, 59, 60, 62, 63, 64
migrate from CSS to ACE 12 flows 13, 22, 24, 27, 30, 38, 96, 97
minimum license information 12 help desk 96
application examples 173 in progress 51
architecture 1 initial treatment 27, 30
ASR 12, 62, 104, 105, 125 log files 152
automatic call distributor (ACD) 77 maximum number 125
Automatic Speech Recognition (ASR) 12, 62, 104, 105, 125 originated by Cisco Unified CM 77, 95
outbound 96
queue and collect 163
B routing 75
self-service 163
backup and restore 155 survivability 36
bandwidth 119, 123, 146 tracking 152
for retrieving prompts 146 traffic 120
provisioning 119, 123 transfers 23, 24, 25, 27, 28, 30, 135
Basic Video Service 31, 170 typical call flow described 13
blind transfer 96 CCE 10
border element 106 Central Controller 121
branch office 33, 149 centralized 35, 57
gateways 33 VoiceXML gateways 57
media server 149 VXML Servers 35
Cisco IOS 49, 146
Cisco Unified Border Element 106
Cisco Unified Call Studio 7, 61, 118
C co-located VXML Servers and gateways 35
cache aging 147 co-resident 57, 167
caching 146, 147 ingress gateway and VoiceXML 57
prompts 146 servers 167
query URLs 147 components of CVP 4
call admission control 127 Comprehensive call flow model 15
Call Director 15, 23, 72, 97 described 15
call flow model described 15 Comprehensive deployment model 25, 72, 99, 100
deployment model 23, 72, 97 described 25
Call Server 165 Using ICM Micro-Apps 72, 99
Call Studio 7, 61, 118 Using Unified CVP VXML Server 72, 100
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
IN-1
Index
configuration of 44, 49, 51, 55, 56, 60, 61, 62, 64, 100, 101, 146 deployment models (continued)
ASR 62 Model #4a - VRU Only with NIC Controlled Routing 73
caching for prompts 146 Model #4b - VRU Only with NIC Controlled Pre-Routing 73
Cisco IOS gateway 49 Network VRU types 71
Cisco Unified CM 64, 101 standalone self-service 61, 62
dial plan 101 types and their uses, summarized 15
Intelligent Contact Management (ICM) 64 Unified CVP VXML Server (Standalone) 21
IVR service 55 VRU only 28
media server 60 design process 15
originating gateway 44 overall steps 15
SIP Proxy Server 49, 51 SIP protocol recommended 15
streaming for prompts 146 dial plan 101
TTS 62 disposition of calls 44, 52, 56, 59, 60, 62, 63, 64
Unified CVP VXML Server 61 distributed 17, 33, 57, 58
Unified ICM 100 deployments 33
VoiceXML gateway 56 gateways 33
consultative transfer 96 network options 17
Content Services Switch (CSS) 12 VoiceXML gateways 57, 58
control traffic 121 DNS Server 11
Correlation ID 68, 69 domain 5
CSS 12 CVP part of 5
CVP xiv, 1, 2, 4, 5, 118, 151, 163, 165, 167, 170 DTMF 104, 105
architecture 1
Call Server 165
Cisco Unified Call Studio 118
co-residency 167
E
components 4 Egress Gateway 9
described 2 enterprise domain 5
licensing xiv CVP part of 5
Operations Console 151 example applications 173
Server 5
sizing components 163
Video Service 170
F
firewalls 133
D flow of calls 96, 97
formal reporting 153
data 123, 151 functional deployment models 15, 21
reporting 151
traffic 123
deployment models 15, 21, 23, 25, 28, 33, 61, 62, 71, 72, 73, 74, 97, 99,
100, 101 G
Call Director 23 G.711 and G.729 support 126
Comprehensive models 25 gatekeeper 101
distributed models 33 configuration 101
functional models 21 gateways 8, 9, 33, 35, 43, 49, 56, 57, 58, 102, 103, 104, 105, 110, 111, 115
hosted implementations 74, 101 at a branch office 33
Model #1 - Standalone Self-Service 72, 97 centralized 57
Model #2 - Call Director 72, 97 Cisco IOS 49
Model #3a - Comprehensive Using ICM Micro-Apps 72, 99 co-located with VXML Servers 35
Model #3b - Comprehensive Using Unified CVP VXML distributed 33, 57, 58
Server 72, 100 maximum VoiceXML sessions 111
Model #4 - VRU Only 72 MGCP 115
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
IN-2
Index
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
IN-3
Index
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
IN-4
Index
transfers (continued) V
in Comprehensive deployments 28
in standalone VoiceXML deployments 23 video endpoints 9
to live agent 27, 30 Video Service 170
VoIP-based 24 voice response unit (VRU) 79
warm 96 voice traffic 120, 126
Translation Route ID 68, 70 VoiceXML 2, 6, 7, 9, 21, 33, 35, 56, 61, 104, 105, 111, 117, 123, 141, 166
troubleshooting 151 call transfers 141
TTS 12, 62, 104, 105, 125 centralized servers 35
Two B Channel Transfer, See TBCT Cisco Unified Call Studio 7, 61
Two B Channel Transfer (TBCT) 138 described 2
Type 10 VRU 69 documents 123
Type 2 VRU 70 Gateway 9
Type 3 VRU 69 gateways 33, 56, 104, 105
Type 7 VRU 69 maximum number of sessions 111
Type 8 VRU 70 over HTTP 117
types of Network VRUs 67, 71, 77 Server 6, 117, 166
sizing 166
Unified CVP VXML Server 61
Unified CVP VXML Server (Standalone) 21
U VoIP-based 24
Unified Call Studio 7, 61, 118 pre-routing 24
Unified CM 9, 35, 38, 63, 77, 95, 101 transfers 24
as egress gateway 35 VRU 79
as ingress gateway 35 VRU call flow model 15
call admission control 38 described 15
calls originated by 77, 95 VRU Only deployment model 28, 72
configuration 101 VRU Only with NIC Controlled Pre-Routing 73
described 9 VRU Only with NIC Controlled Routing 73
high availability 63 VRU PG 121
Unified Contact Center Enterprise (CCE) 10
W
warm consultative transfer 96
wink 136
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
IN-5
Index
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
IN-6