Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND) CVP 8 Cvp8xsrnd

User Manual: CVP-8

Open the PDF directly: View PDF PDF.
Page Count: 223 [warning: Documents this large are best viewed by clicking the View PDF Link!]

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
Cisco Unified Customer Voice Portal (CVP) Solution
Reference Network Design (SRND)
Cisco Unified Customer Voice Portal (CVP) Release 8.0(1)
October 1, 2012
Last Revised: January 21, 2013
Text Part Number: OL-15989-06
iii
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
CONTENTS
Preface xiii
Audience xiii
New or Changed Information for This Release xiii
Revision History xiv
Obtaining Documentation, Obtaining Support, and Security Guidelines xiv
CHAPTER
1Unified CVP Architecture Overview 1-1
What's New in This Chapter 1-1
What is VoiceXML? 1-2
What is the Cisco Unified Customer Voice Portal? 1-3
Unified CVP Product and Solution Components 1-4
Unified CVP Product Components 1-5
Unified CVP Call Server (Call Server) 1-5
Unified CVP VXML Server (VXML Server) 1-6
Cisco Unified Call Studio (Call Studio) 1-7
Unified CVP Reporting Server (Reporting Server) 1-7
Unified CVP Operations Console Server (Operations Console) 1-7
Additional Unified CVP Solution-Related Components 1-8
Cisco Ingress Voice Gateway 1-8
Cisco VoiceXML Gateway 1-9
Cisco Egress Gateway 1-9
Video Endpoints 1-9
Cisco Unified Communications Manager 1-10
Cisco Unified Contact Center 1-10
Cisco Gatekeeper 1-11
SIP Proxy Server 1-11
DNS Server 1-13
Cisco Security Agent 1-13
Content Services Switch 1-14
Application Content Engine (ACE) 1-15
Third-Party Media Server 1-15
Third-Party Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Servers 1-16
Network Monitor 1-17
Call Flows 1-17
Contents
iv
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Typical SIP Unified CVP Call Flow 1-17
Typical H.323 Unified CVP Call Flow 1-18
Design Process 1-19
H.323 and Unified CVP 1-20
Call Flow Models 1-20
How Unified CVP Routes Outbound Calls (Unified CVP Algorithm for Routing) 1-21
Distributed Network Options 1-22
Cube Deployment with SIP Trunks 1-22
Design Considerations 1-23
High Availability Options 1-23
Scalability Options 1-24
Virtualization 1-24
Quality of Service (QoS) 1-24
Licensing Information 1-24
CHAPTER
2Functional Deployment Models 2-1
What's New in This Chapter 2-1
Unified CVP VXML Server (Standalone) 2-2
Protocol-Level Call Flow 2-2
Transfers and Subsequent Call Control 2-3
Call Director 2-4
SIP Protocol-Level Call Flow 2-4
H.323 Protocol-Level Call Flow 2-5
Transfers and Subsequent Call Control 2-6
Comprehensive 2-6
SIP Protocol-Level Call Flow 2-8
H.323 Protocol-Level Call Flow 2-9
Transfers and Subsequent Call Control 2-10
VRU Only 2-11
Protocol-Level Call Flow 2-12
Basic Video Service 2-13
2-14
CHAPTER
3Distributed Deployments 3-1
What's New in This Chapter 3-1
Distributed Gateways 3-1
Ingress and/or Egress Gateway at the Branch 3-1
Ingress or VoiceXML Gateway at Branch 3-2
Contents
v
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Co-Located Unified CVP VXML Servers and Gateways 3-3
Gateways at the Branch, with Centralized Unified CVP VXML Servers 3-3
Cisco Unified Communications Manager 3-3
Unified CM as an Egress Gateway 3-3
Unified CM as an Ingress Gateway 3-4
Multicast Music-on-Hold (MOH) 3-4
Design Considerations 3-4
Call Survivability in Distributed Deployments 3-5
Call Admission Control Considerations 3-6
Gatekeeper Call Admission Control 3-6
Unified CM Call Admission Control 3-7
H.323 Call Flows 3-7
Multiple Cisco Unified CM Clusters 3-9
SIP Call Flows 3-10
RSVP 3-10
H.323 Gatekeeper Call Routing 3-10
CHAPTER
4Designing Unified CVP for High Availability 4-1
What's New in This Chapter 4-2
Overview 4-2
Layer 2 Switch 4-3
Originating Gateway 4-4
Configuration 4-4
Call Disposition 4-5
SIP Proxy 4-5
Cisco Unified SIP Proxy (CUSP) Support 4-7
CUSP Deployment Methods 4-7
Performance Matrix for CUSP Deployment 4-8
CUSP Design Considerations 4-9
Configuration 4-9
SIP Proxy Server Configuration 4-9
Cisco IOS Gateway Configuration 4-10
Call Disposition 4-11
Unified CVP SIP Service 4-11
Configuration 4-12
Configuring High Availability for Calls in Progress 4-12
Call Disposition 4-13
Server Groups 4-14
Server Group Heartbeat Settings 4-15
Contents
vi
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Static Routes Validation 4-15
Design Considerations 4-16
Diagnostics 4-16
Gatekeeper 4-16
Gatekeeper Redundancy Using HSRP 4-16
Gatekeeper Redundancy Using Alternate Gatekeeper 4-17
Configuration 4-18
HSRP Configuration 4-18
Alternate Gatekeeper 4-18
Call Disposition 4-19
Unified CVP H.323 Service 4-19
Configuration 4-20
Configuring High Availability for New Calls 4-20
Configuring High Availability for Calls in Progress 4-20
Additional Cisco IOS Gateway Configuration 4-21
Call Disposition 4-21
Unified CVP IVR Service 4-21
Configuration 4-22
Call Disposition 4-22
VoiceXML Gateway 4-23
Configuration 4-23
Centralized VoiceXML Gateways 4-24
Distributed VoiceXML Gateways (Co-Resident Ingress Gateway and VoiceXML) 4-24
Distributed VoiceXML Gateways (Separate Ingress Gateway and VoiceXML) 4-25
H.323 Alternate Endpoints 4-27
Call Disposition 4-28
Hardware Configuration for High Availability on the Voice Gateways 4-28
Content Services Switch (CSS) 4-28
Configuration 4-29
Call Disposition 4-29
Media Server 4-30
Configuration When Using Unified CVP Microapplications 4-30
Call Disposition When Using Unified CVP Microapplications 4-31
Configuration When Using Cisco Unified Call Studio Scripting 4-31
Unified CVP VXML Server 4-31
Configuration 4-31
Standalone Self-Service Deployments 4-31
Deployments Using ICM 4-32
Call Disposition 4-32
Contents
vii
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server 4-32
Configuration 4-32
Standalone Self-Service Deployments 4-32
Deployments Using ICM 4-33
Call Disposition 4-33
Cisco Unified Communications Manager 4-33
Configuration 4-34
Call Disposition 4-34
Intelligent Contact Management (ICM) 4-34
Configuration 4-34
Call Disposition 4-35
CHAPTER
5Interactions with Cisco Unified ICM 5-1
What's New in This Chapter 5-2
Network VRU Types 5-2
Overview of Unified ICM Network VRUs 5-3
Unified CVP as a Type 10 VRU 5-3
Unified CVP as Type 5 VRU 5-4
Unified CVP as Type 3 or 7 VRU (Correlation ID Mechanism) 5-5
Unified CVP as Type 8 or 2 VRU (Translation Route ID Mechanism) 5-6
Network VRU Types and Unified CVP Deployment Models 5-6
Model #1: Standalone Self-Service 5-7
Model #2: Call Director 5-8
Model #3a: Comprehensive Using ICM Micro-Apps 5-8
Model #3b: Comprehensive Using Unified CVP VXML Server 5-8
Model #4: VRU Only 5-8
Model #4a: VRU Only with NIC Controlled Routing 5-8
Model #4b: VRU Only with NIC Controlled Pre-Routing 5-9
Hosted Implementations 5-10
Overview of Hosted Implementations 5-10
Using Unified CVP in Hosted Environments 5-11
Unified CVP Placement and Call Routing in a Hosted Environment 5-11
Network VRU Type in a Hosted Environment 5-13
Deployment Models and Sizing Implications for Calls Originated by Cisco Unified Communications
Manager and ACDs 5-13
Using Third-Party VRUs 5-15
DS0 Trunk Information 5-15
Trunk Utilization Routing and Reporting 5-16
Combining Gateway Trunk Utilization with Server Group Pinging 5-16
Contents
viii
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Deployment Considerations 5-16
Enhanced User-to-User Information 5-17
Manipulating the UUS Field 5-18
Using UUI 5-18
REFER and 302 Redirects and UUI 5-19
Design Considerations 5-19
Custom SIP Headers 5-19
Passing Information in SIP Headers to Unified ICM 5-19
String Format and Parsing 5-20
Passing of Headers from the ICM Script 5-20
Examples of Unified ICM Scripting for Custom SIP Headers 5-21
Courtesy Callback 5-21
Example Scripts and Audio Files 5-22
Callback Criteria 5-23
Typical Use Scenario 5-23
Courtesy Callback Prerequisites and Design Considerations 5-24
Post Call Survey 5-25
Post Call Survey Typical Uses 5-25
Post Call Survey Design Considerations 5-25
CHAPTER
6Calls Originated by Cisco Unified Communications Manager 6-1
What's New in This Chapter 6-1
Differences in Calls Originated by Cisco Unified Communications Manager 6-1
Customer Call Flows 6-2
Unified ICM Outbound Calls with Transfer to IVR 6-2
Internal Help Desk Calls 6-2
Warm Consultative Transfers and Conferences 6-3
Protocol Call Flows 6-3
Model #1: Standalone Self-Service 6-3
Model #2: Call Director 6-4
Model #3a: Comprehensive Using ICM Micro-Apps 6-5
Model #3b: Comprehensive Using Unified CVP VXML Server 6-6
Deployment Implications 6-6
Unified ICM Configuration 6-6
Hosted Implementations 6-7
Cisco Unified Communications Manager Configuration 6-7
Gatekeeper or SIP Proxy Dial-Plan Configuration 6-7
Sizing 6-8
Gateways 6-8
Contents
ix
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
KPML Support 6-8
MTP Usage on UCM Trunk 6-8
Design Considerations 6-9
CHAPTER
7Gateway Options 7-1
What's New in This Chapter 7-1
PSTN Gateway 7-2
VoiceXML Gateway with DTMF or ASR/TTS 7-2
VoiceXML and PSTN Gateway with DTMF or ASR/TTS 7-3
Cisco Integrated 3G-H324M Gateway 7-3
Gateway Topology and Call Flow 7-3
CVP Configuration 7-4
TDM Interfaces 7-4
Cisco Unified Border Element 7-5
Mixed G.729 and G.711 Codec Support 7-6
Gateway Choices 7-6
Gateway Sizing 7-7
Using MGCP Gateways 7-11
CHAPTER
8Design Implications for Unified CVP VXML Server 8-1
What is VoiceXML over HTTP? 8-1
Multi-Language Support 8-2
Differences in the Supported Web Application Servers 8-2
Where to Install Cisco Unified Call Studio 8-3
CHAPTER
9Network Infrastructure Considerations 9-1
What's New in This Chapter 9-1
Bandwidth Provisioning and QoS Considerations 9-2
Unified CVP Network Architecture Overview 9-2
Voice Traffic 9-2
Call Control Traffic 9-3
Data Traffic 9-5
Bandwidth Sizing 9-5
VoiceXML Documents 9-5
Media File Retrieval 9-6
H.323 Signaling 9-7
SIP Signaling 9-7
Contents
x
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
ASR and TTS 9-7
Voice Traffic (G.711 and G.729) 9-9
Call Admission Control 9-9
Local Branch Call Admission Control (LBCAC/Queue-at-the-Edge) 9-9
Queue-at-the-Edge Branch Office Deployment Model 9-10
LBCAC Concept Definitions 9-11
Importance and Comparison of LBCAC Feature 9-11
Design Considerations 9-11
High Availability and Failover 9-12
Additional Important Information for LBCAC 9-12
QoS Marking 9-13
Network Latency 9-13
Blocking Initial G.711 Media Burst 9-15
Network Security Using Firewalls 9-16
CHAPTER
10 Call Transfer Options 10-1
What's New in This Chapter 10-1
Release Trunk Transfers 10-2
Takeback-and-Transfer (TNT) 10-2
Hookflash and Wink 10-3
SIP Hookflash Support 10-4
Design Considerations 10-4
Two B Channel Transfer (TBCT) 10-4
ICM Managed Transfers 10-5
Network Transfer 10-6
SIP Refer Transfer 10-7
H.323 Refer Transfer 10-7
Intelligent Network (IN) Release Trunk Transfers 10-7
VoiceXML Transfers 10-8
CHAPTER
11 Using the GKTMP NIC 11-1
The Cisco Gatekeeper External Interface 11-1
The Unified ICM GKTMP NIC 11-1
Typical Applications of GKTMP with Unified CVP 11-2
Protocol-Level Call Flow 11-3
Deployment Implications 11-5
Contents
xi
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
CHAPTER
12 Media File Options 12-1
Deployment and Ongoing Management 12-1
Co-Resident Unified CVP Call Server, Media Server, and Unified CVP VXML Server 12-2
Bandwidth Calculation for Prompt Retrieval 12-3
Configuring Caching and Streaming in Cisco IOS 12-3
Streaming and Non-Streaming 12-3
Caching 12-4
Caching Query URLs 12-4
TCP Socket Persistence 12-4
Cache Aging 12-5
Branch Office Implications 12-6
CHAPTER
13 Managing, Monitoring, and Reporting 13-1
What's New in This Chapter 13-1
Unified CVP Operations Console Server: Managing and Monitoring 13-1
DS0 Trunk Information for Reporting 13-2
End-to-End Tracking of Individual Calls: Log Files 13-3
Formal Reporting 13-3
New Reporting Features 13-4
Cisco Unified IC Templates 13-5
Backup and Restore 13-6
More Information 13-6
Unified System CLI and Web Services Manager (WSM) 13-7
Analysis Manager versus the Unified System CLI 13-7
The Analysis Manager 13-8
Unified System CLI Overview 13-8
Unified System CLI Modes of Operation 13-9
Unified System CLI Questions and Answers 13-10
CHAPTER
14 Sizing 14-1
What's New in This Chapter 14-1
Sizing Overview 14-2
Unified CVP Call Server 14-3
Call Server Log Directory Size Estimate 14-3
Unified CVP VXML Server (VXML Server) 14-4
Unified CVP Co-Residency 14-5
Unified Presence Server 14-7
Contents
xii
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Unified CVP Video Service 14-8
Sizing Unified CVP Basic Video Service 14-8
Unified CVP Reporting Server 14-8
How to Use Multiple Unified CVP Reporting Servers 14-9
Reporting Message Details 14-10
Example Applications 14-11
CHAPTER
15 Licensing 15-1
I
NDEX
xiii
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Preface
Last revised on: May 2, 2010
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_gui
des_list.html
Note Unless stated otherwise, the information in this document applies to Cisco Unified Customer Voice
Portal (CVP) 8.x (8.0 and all subsequent 8.x releases). Any differences between the various releases of
Cisco Unified CVP are specifically noted in the text.
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,
refer to the documentation at the preceding URL.
New or Changed Information for This Release
Within each chapter, new and revised information is listed in a section titled What’s New in This Chapter.
xiv
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Preface
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_gui
des_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.
Obtaining Documentation, Obtaining Support, and Security
Guidelines
For information on obtaining documentation, obtaining support, providing documentation feedback,
security guidelines, and also recommended aliases and general Cisco documents, see the monthly
What’s New in Cisco Product Documentation, which also lists all new and revised Cisco technical
documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Revision Date Comments
August 8, 2008 Updates were added for licensing and several other topics.
February 27, 2008 Initial release of this document for Cisco Unified CVP 7.0.
November 30, 2009 Corrected some minor errors.
August 18, 2009 Content was updated as indicated in New or Changed Information for This
Release, page xiii.
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, page 7-1,
and Call Transfer Options, page 10-1.
April 20, 2010 Initial release of this document for Cisco Unified CVP 8.0.
CHAPTER
1-1
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
1
Unified CVP Architecture Overview
Last revised on: May 2, 2010
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:
• What is VoiceXML?, page 1-2
• What is the Cisco Unified Customer Voice Portal?, page 1-3
• Unified CVP Product and Solution Components, page 1-4
• Call Flows, page 1-17
• Design Process, page 1-19
• Quality of Service (QoS), page 1-24
• Licensing Information, page 1-24
What's New in This Chapter
Table 1-1 lists the topics that are new in this chapter or that have changed significantly from previous
releases of this document.
Table 1-1 New or Changed Information Since the Previous Release of This Document
New or Revised Topic Description
Cisco Security Agent, page 1-13 There is a new version of CSA especially for Unified
CVP
Application Content Engine (ACE), page 1-15 An alternative to CSS for load balancing and
failover.
1-2
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
What is VoiceXML?
What is VoiceXML?
Voice eXtensible Markup Language, or VoiceXML VXML, 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 via 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.
How Unified CVP Routes Outbound Calls
(Unified CVP Algorithm for Routing),
page 1-21
Steps through the process of outbound call routing.
Cube Deployment with SIP Trunks, page 1-22 Introduces support for the Cisco Unified Border
Element product.
Virtualization, page 1-24 Unified CVP may be installed and run on Virtual
Machines (VMs).
Table 1-1 New or Changed Information Since the Previous Release of This Document
New or Revised Topic Description
1-3
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
What is the Cisco Unified Customer Voice Portal?
What is the Cisco Unified Customer Voice Portal?
Unified CVP is both a product and a solution. As a product, its media kit includes specific software
items, as listed in the first part of Unified CVP Product and Solution Components, page 1-4. As a
solution, Unified CVP relies on additional Unified CVP components. The additional components are
described in Additional Unified CVP Solution-Related Components, page 1-8. The resulting solution
provides carrier-class IVR and IP switching services on Voice over IP (VoIP) networks.
Unified CVP includes the following features:
• Carrier-class Performance
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 H.323 or SIP call control
to provide switching services similar to takeback-and-transfer (TNT) between IP endpoints via the
Unified ICM Enterprise (ICME) interface. Integration with Cisco Unified Presence Server and a
gatekeeper helps provide easily managed dial plans.
Supports call routing services for both SIP (RFC 3261) and H.323 protocols. Existing customers can
continue to use H.323 call services. Or, they can migrate to SIP over time. The Unified CVP solution
can run as a hybrid, directing both SIP and H.323 calls until all call flows are switched over to SIP.
• IP-based IVR services
–
IVR Services. In addition to switching and transfer, Unified CVP provides classic
prompt-and-collect functions, such as Press 1 for Sales.
–
Voice Enabled IVR Services. 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.
–
Queuing. 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. 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.
• Unified CVP Operations Console Server (Operations Console)
Centrally operate, administer, maintain, and provision the components in the Unified CVP solution
from its web-based Operations Console. Integrate with Cisco Contact Center Support Tools. (Refer
to Unified CVP Operations Console Server (Operations Console), page 1-7 for hosting
information.)
1-4
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
• VRU reporting
Access historical data using its included centralized reporting database. Design and run custom
reports using its well-documented schema.
• Compatibility and Integration
–
Use with other Cisco Call Routing and VoIP Products, including, Cisco Unified Intelligent
Contact Management Hosted or Cisco Unified Intelligent Contact Management Enterprise,
Cisco Gatekeepers, Cisco Gateways, and Unified Contact Center Enterprise (UCCE).
–
Use with Cisco Unified Communications Manager (Unified CM). Unified CM manages and
switches VoIP calls among IP phones. When combined with Unified ICME, Unified CM
becomes the UCCE product.
–
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 (details)
Unified CVP integrates with Cisco Unified Contact Center via a VRU Peripheral Gateway (PG).
This integration enables Cisco Unified Contact Center Enterprise (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 Cisco Unified Communications Manager PG be used for Unified
CCE integration with Cisco Unified Communications Manager.
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 up-front menus and prompts by the parent Unified ICM and
Unified CVP, and it intelligently routes the calls via 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 will retain call data, and the ICM will provide 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.
Unified CVP Product and Solution Components
As mentioned previously, Unified CVP is both a product and a solution. The following topics describe
both the components that make up the Unified CVP product, and the additional components that make
up the Unified CVP solution.
The Cisco Unified Customer Voice Portal (CVP) product consists of the following components:
• Unified CVP Call Server (Call Server), page 1-5
• Unified CVP VXML Server (VXML Server), page 1-6
• Cisco Unified Call Studio (Call Studio), page 1-7
1-5
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
• Unified CVP Reporting Server (Reporting Server), page 1-7
• Unified CVP Operations Console Server (Operations Console), page 1-7
• Additional Unified CVP Solution-Related Components, page 1-8
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, page 1-8
• Cisco VoiceXML Gateway, page 1-9
• Cisco Egress Gateway, page 1-9
• Video Endpoints, page 1-9
• Cisco Unified Communications Manager, page 1-10
• Cisco Unified Contact Center, page 1-10
• Cisco Gatekeeper, page 1-11
• SIP Proxy Server, page 1-11
• DNS Server, page 1-13
• Cisco Security Agent, page 1-13
• Content Services Switch, page 1-14
• Third-Party Media Server, page 1-15
• Application Content Engine (ACE), page 1-15
• Third-Party Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Servers, page 1-16
• Network Monitor, page 1-17
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.
Unified CVP Product Components
The following topics describe the Cisco Unified Customer Voice Portal (CVP) product components.
Note A Unified CVP server can, optionally, be part of the enterprise domain.
Unified CVP Call Server (Call Server)
The Unified CVP Call Server (Call Server) component provides the following independent services,
which all run on the same Windows 2003 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 hairpinned through this service, this
service does not touch the RTP traffic.
1-6
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
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
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, the IVR Service, and the H.323
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.
• H.323 Service (Formerly known as the Unified CVP Voice Browser)
This service interacts with the IVR Service to relay call arrival, release, and transfer call control
between it and the other H.323 components. This service is needed only for deployments using
H.323.
A Unified CVP Call Server can be deployed co-resident with the Unified CVP VXML Server or a media
server. Optionally, a Unified CVP Call Server can be deployed as part of the Enterprise Windows
Domain.
For hardware details, refer to 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
Unified CVP VXML Server (VXML Server)
The Unified CVP 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 or WebSphere, and many customers add their own custom-built or off-the-shelf J2EE
components to interact with back-end hosts and services. Unified CVP 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. In 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 be installed co-resident with a Unified CVP Call Server or the media server.
The VXML Server can execute on Windows 2003 servers. For hardware requirements and details, refer
to 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
For a further discussion of the VXML Server, and its latest added features, refer to the User Guide for
Cisco Unified CVP VXML Server and Cisco Unified Call Studio, Release 8.0(1).
1-7
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
Cisco Unified Call Studio (Call Studio)
The Cisco Unified Call Studio (Call Studio) is the service creation environment (script editor) for
Unified CVP VXML Server applications. It is based on the open source Eclipse framework, and it
provides advanced drag-and-drop graphical editing as well as the ability to insert vendor-supplied and
custom-developed plug-ins that enable applications to interact with other services in the network. The
Call Studio is essentially an offline tool whose only interaction with the Unified CVP VXML Server is
to deliver compiled applications and plugged-in components for execution.
The Call Studio executes on Windows XP or Windows Vista workstations or servers. Because the license
is associated with the MAC address of the machine on which it is running, customers typically designate
one or more data center servers for that purpose. Cisco Unified Call Studio cannot run on machines also
running a headless version of the Cisco Security Agent.
For additional hardware details, refer to 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
Note Cisco Security Agent is not supported on Unified Call Studio.
Unified CVP Reporting Server (Reporting Server)
The Unified CVP Reporting Server is a Windows 2003 server that hosts an IBM Informix Dynamic
Server (IDS) database management system. The Reporting Server provides consolidated historical
reporting for a distributed self-service deployment. 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 Server receives reporting data from the IVR Service, the SIP Service (if used), and the
Unified CVP VXML Server (VXML Server). The Reporting Server depends on the Unified CVP Call
Server (Call Server) to receive call records.
For Standalone Unified CVP VXML Server deployments, one Call Server is needed per Reporting
Server. The Reporting Server must be local to the Call Server(s) and VXML Server(s) that it is servicing.
Deploying the Reporting Server at a remote location across the WAN is not supported. Multiple
Reporting Servers should be used and placed at each site when Call Server(s) and VXML Server(s) exist
at multiple locations.
The Reporting Server does not itself perform database administrative and maintenance activities such as
backups or purging. However, Unified CVP provides access to such maintenance tasks through the
Unified CVP Operations Console Server.
Unified CVP Operations Console Server (Operations Console)
The Unified CVP Operations Console Server is a Windows 2003 server that provides an Operations
Console for the browser-based administration and configuration for all Unified CVP product
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.
However, beginning with Unified CVP 8.0(1), it can be located on the same server with Support Tools
2.4.
1-8
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
The Operations Console also offers a direct link to Support Tools, which can collect trace logs and
perform other diagnostic and instrumentation functions on many solution components. The Operations
Console is, in effect, the 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 browser-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 those components are currently
using them. The configured or offline view shows the status of all configuration parameters that are
stored in the Operations Server database and will be deployed to the device the next time a Save and
Deploy option is executed.
The Operations Console allows configuration parameters to be updated or preconfigured even when the
target component is not online or running. If the target server (without its services) comes online, the
user can apply the configured settings to that server. These settings will become active when that server's
services also come online. Only then will they be reflected in the runtime view.
The Operations Console Server is not a redundant component. As such, the Operations Console Server
cannot be duplicated within a deployment. Backups of the configuration database should be take
regularly or whenever changes are made.
Additional Unified CVP Solution-Related Components
The following additional components are used in the various call flow models (solutions) described in
Call Flows, page 1-17.
Cisco Ingress Voice Gateway
The Cisco Ingress Voice Gateway is the point at which an incoming call enters the Unified CVP system.
It terminates TDM calls on one side and implements VoIP on the other side. It serves as a pivot point for
extension of calls from the TDM environment to VoIP endpoints. Therefore, WAN bandwidth is
conserved because no hairpinning of the media stream occurs. It also provides for sophisticated call
switching capabilities at the command of other Unified CVP solution components.
Unified CVP Ingress Voice Gateways support both SIP and H.323. Media Gateway Control Protocol
(MGCP) voice gateways are supported if they are registered with Cisco Unified Communications
Manager.
For the most current list of supported gateways, refer to Gateway Choices, page 7-6. For approved
gateway/software combinations refer to 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
1-9
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
The Ingress Gateway can be deployed separately from the VoiceXML Gateway, but in most
implementations they are one and the same: one gateway performs both functions. Gateways are often
deployed in farms, for Centralized deployment models. In Branch deployment models, one combined
gateway is usually located at each branch office.
Cisco VoiceXML Gateway
The VoiceXML Gateway hosts the Cisco IOS Voice Browser. This component interprets VoiceXML
pages from either the Unified CVP Server IVR Service or the Unified CVP VXML Server. The
VoiceXML Gateway encodes .wav files and accepts DTMF input. It then returns the results to the
controlling application and waits for further instructions.
The Cisco VoiceXML Gateway can be deployed on the same router as the Unified CVP Ingress Voice
Gateway. This model is typically desirable in deployments with small branch offices. But the VoiceXML
Gateway can also run on a separate router platform, and this model is typically desirable in deployments
with large or multiple voice gateways, where only a small percentage of the traffic is for Unified CVP.
This model enables an organization to share PSTN trunks between normal office users and contact center
agents and to route calls based upon the dialed number.
The Cisco VoiceXML Gateway can encode .wav files stored in flash memory or on a third-party media
server. Prompts retrieved from a third-party media server can be cached in the router to reduce WAN
bandwidth and prevent poor voice quality. The VoiceXML doc will provide a pointer to the location of
the .wav file to be played or it will provide the address of a TTS server to generate a .wav file. The
VoiceXML Gateway interacts with ASR and TTS servers via MRCP.
Supported VoiceXML Gateways include the Cisco 2800 Series, 3800 Series, 5350XM, and 5400 XM.
For the most current list of supported VoiceXML Gateways, refer to 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
Unless it is combined with the Ingress Gateway (described in the previous topic), the VoiceXML
Gateway does not require any TDM hardware. All its interfaces are VoIP on one side and HTTP (carrying
VXML or .wav files) and MRCP (carrying ASR and TTS traffic) on the other side. As with Ingress
Gateways, VoiceXML Gateways are often deployed in farms for Centralized deployment models, or one
per office in Branch deployments.
Cisco Egress Gateway
The Egress Voice Gateway is used only when calls need to be extended to TDM networks or equipment
such as the PSTN or a TDM ACD. While the RTP stream goes between the ingress and egress voice
gateway ports, the signaling stream logically goes through the Unified CVP Server and ICM in order to
allow subsequent call control (such as transfers).
Video Endpoints
When using the Unified CVP Basic Video Service, the following video endpoints are supported:
• Cisco Unified IP Phone 7985G
• Cisco Unified Video Advantage
• Cisco TelePresence
1-10
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
Cisco Unified Communications Manager
Cisco Unified Communications Manager (Unified CM) is the main call processing component of a Cisco
Unified Communications system. It manages and switches VoIP calls among IP phones. Unified CM
combines with Cisco Unified Intelligent Contact Manager Enterprise (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 an
available Unified CM SIP trunk, and H.323 gateway calls are routed to an available Unified CM H.323
trunk.
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 both SIP and H.323 devices. PSTN calls that
arrived on MGCP voice gateways registered with Unified CM can also be routed or transferred to
Unified CVP via either SIP or H.323, depending upon the deployment model chosen.
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. 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. Unified CVP is supported with
H.323 for Cisco Unified CM 4.x or later releases. For full details on version compatibility, consult 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 Contact Center
Either Cisco Unified CCE or Cisco Unified Intelligent Contact Management (ICM) is a required
component when advanced call control (IP switching, transfers to agents, and so forth) is required in
Unified CVP. The Hosted versions of these products might also be used for this purpose. Unified ICM
provides call-center agent management capabilities and call scripting capabilities. Variable storage
capability and database access through the Unified CCE or Unified ICM application gateways are also
powerful tools. A Unified CVP application can take advantage of these capabilities because Unified CVP
applications can be called from within a Unified CCE or Unified ICM script in a non-standalone Unified
CVP deployment model.
The Unified CVP Call Server (Call Server) maintains a GED-125 Service Control Interface connection
to Unified CCE or Unified ICM. GED-125 is a third-party-control protocol in which a single socket
connection is used to control many telephone calls. From the point of view of Unified CCE or Unified
ICM, the Call Server is a voice response unit (VRU) connected to Unified CCE or Unified ICM, just as
all other GED-125 VRUs are connected. Unified CVP is simply a VRU peripheral to Unified CCE or
Unified ICM.
1-11
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
Cisco Gatekeeper
The gatekeeper is a network element used by H.323 gateways for call routing. The gatekeeper is required
for all H.323 installations for dial plan configuration and bandwidth management.
Scenarios for gatekeeper usage include:
• To map specific dialed numbers to specific Unified CVP Servers or VoiceXML gateways.
• To load-balance new calls to a set of Unified CVP Servers or VoiceXML gateways.
• To route the transfer of callers from a VoiceXML gateway port to a Cisco IP Phone.
• To provide failover capabilities for H.323 endpoints.
The Gatekeeper is the focus for high availability design in the H.323 protocol arena, and it is only used
in Unified CVP implementations that use H.323 for call control. Like the SIP Proxy Server, it mixes
directory lookup services with load balancing and failover capabilities, producing fault tolerance among
H.323 endpoints. Unlike the SIP Proxy Server, control messages do not pass through it to target
endpoints; instead, it uses a request/response server paradigm.
Two gatekeeper failover mechanisms are supported:
• HSRP. For redundancy, Gatekeepers can be deployed in pairs using the HSRP (Hot Standby Routing
Protocol), one redundant pair per site.
• Alternate Gatekeepers. The VBAdmin SetGatekeeper command allows multiple IP addresses to be
configured. The H.323 Service keeps track of a currently active Gatekeeper from that IP list. It
begins by sending all requests to the first gatekeeper on the list.
If the currently active Gatekeeper fails, it moves to the next one in the list, and that one becomes the
current gatekeeper. The H.323 Service continues to use that gatekeeper until it too fails, at which
time it begins using the subsequent Gatekeeper in the list. When the list is exhausted, the next
failover is back to the top of the list.
For sizing purposes, each Gatekeeper should be sized to handle the entire load.
For more information on H.323 gatekeepers, refer to the Overview of the Cisco IOS Gatekeeper available
online at: http://www.cisco.com/en/US/docs/ios/12_2/gktmp/gktmpv4_2/iosgk.html.
Also consult the Cisco Gatekeeper External Interface Reference, available at
http://www.cisco.com/en/US/docs/ios/12_3/gktmpv4_3/guide/gktmp4_3.html
SIP Proxy Server
The SIP Proxy Server is the component that routes individual SIP messages among SIP endpoints. It
plays a key role in Unified CVP high-availability architecture for call switching. It is designed to support
multiple SIP endpoints of various types and to implement load balancing and failover among these
endpoints. Deployment of a SIP Proxy in the solution enables a more centralized configuration of the
dial plan routing configuration.
The Cisco Unified Presence Server (CUP Server), which has a built-in SIP Proxy function, and the Cisco
Unified SIP Proxy Server (CUSP Server), which runs on an ISR gateway, are tested and supported with
Unified CVP.
The SIP Proxy can be configured with multiple static routes (also called server group elements on the
CUSP Server) in order to do load balancing and failover with outbound calls. The static routes can point
to an IP address or a regular DNS A host record.
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.
1-12
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
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. If a SIP Proxy Server is not used, then Ingress Gateways and Unified CMs must point
directly to Unified CVP. In such a deployment, load balancing is done via DNS SRV lookups from the
gateway to the DNS Server. Load balancing of calls outbound from Unified CVP (outbound call leg) can
be done in a similar fashion.
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 the Cisco Unified Presence Server is being used as the SIP Proxy Server, dial plan management
is available in the web administration of the static routes.
• If the Cisco Unified Presence Server is being used as the SIP Proxy Server, you are better positioned
to also take advantage of Presence and Cisco Unified Client, as a compliment to Unified CVP.
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 via 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 in similar
fashion.
• Failover of SIP rejections (code 503 only) can also be performed if SRV records are configured with
ordered priorities.
The following guidelines apply to the use of a Cisco Unified Presence server as a SIP Proxy:
• A Unified CM publisher is required in order to install Cisco Unified Presence. Therefore, you need
at least one Unified CM publisher if you plan on using the Cisco Unified Presence server as a SIP
Proxy (even for a TDM-only deployment with no Unified CM or Unified CCE agents). Unified CM
does not need any Device License Units to perform this function.
• A Cisco Unified CM 7.x publisher can support six Cisco Unified Presence nodes per cluster,
contained in three dual-node sub-clusters.
• The Cisco Unified Presence servers can be clustered over the WAN, provided the required
conditions are met. Refer to Cisco Unified Presence Server documentation for clustering over WAN
conditions. Document is available at:
http://www.cisco.com/en/US/products/ps6837/tsd_products_support_series_home.html
In situations where redundancy across two or more sites is required but clustering over the WAN
with Cisco Unified Presence servers is not needed or cannot be supported, you will need at least one
Unified CM publisher and one Cisco Unified Presence server at each site. Cisco Unified Presence
configuration data is not shared between clusters, so you must configure each Cisco Unified
Presence server with dial plan information.
• If you have multiple Cisco Unified Presence servers, in order for them to provide redundancy to
Unified CVP, you must configure a DNS SRV record that provides load balancing and/or failover
pointing at both servers. You then configure Unified CVP to use this single DNS SRV record as the
SIP Proxy Server.
1-13
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
• If you have multiple Cisco Unified Communications Manager clusters, you do not need a Cisco
Unified Presence server attached to each cluster for SIP Proxy functionality. It is possible for a
single Cisco Unified Presence server to provide SIP Proxy services for multiple clusters. However,
depending on where the clusters are located, you might want to have multiple Cisco Unified
Presence servers for redundancy (such as with clustering over the WAN).
DNS Server
This optional component may be installed anywhere in the network. Its purpose in general is to resolve
hostnames to IP addresses. Unified CVP, can make both Type A record lookups and SRV Type record
lookups. If the DNS server is slow to respond, is unavailable, is across the WAN, or so forth, this will
affect 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 Cisco Unified Presence Server
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 Cisco Unified Presence Server supports DNS SRV,
but it has not been tested in Unified CVP deployments.) 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.
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.
Cisco Security Agent
The Cisco Security Agent (CSA) software is an optional, but highly recommended, component of
Unified CVP which enhances the security of the Unified CVP servers. By monitoring the behavior of
applications running on a Unified CVP server, monitoring the network traffic, and so forth, CSA
effectively prevents malicious software from disrupting the services provided by the server.
The Cisco Security Agent is not an anti-virus tool. Rather, it provides behavior-based protection and is
intended to be used in combination with one of the supported third-party anti-virus products. The list of
supported anti-virus products is provided in the Unified CVP Bill of Materials (BOM).
The Cisco Security Agent provided for Unified CVP has been specially configured to allow the Unified
CVP software, and all the supported third party products, to perform their functions. Other versions of
CSA are not configured for Unified CVP and cannot be installed on a Unified CVP server.
1-14
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
There are two ways to use the CSA feature of Unified CVP:
• If you want the protection of CSA but do not intend to customize its protection policies, install the
unmanaged Cisco Security Agent provided by Cisco.
• If you want to modify the behavior of CSA, buy and install the Cisco Security Agent Management
Console for CSA and import and modify the policies supplied with the unmanaged agent.
The Cisco Security Agent is not automatically installed by the Unified CVP installer. After installing
Unified CVP, do one of the following:
• Obtain the unmanaged version of CSA for Unified CVP and install it on the server. The unmanaged
version will include the supplied Cisco security policies which cannot be modified.
• Or, obtain the Cisco Security Management Console and install it. Then obtain the .export file that
contains the Cisco security policy, modify the policy as desired, and deploy CSA using your
modified policy.
For detailed information about Cisco Security Agent, its unmanaged and managed versions, and about
obtaining and installing the software, refer to Cisco Security Agent Installation/Deployment Guide for
Cisco Unified Customer Voice Portal, Release 8.0(1). The document is available under Install and
Upgrade Guides at
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/prod_installation_guides_list.html
You can also download the software from the Cisco website, refer to:
http://tools.cisco.com/support/downloads/pub/Redirect.x?mdfid=270563413
Note Cisco does not support a user-modified version of the CSA security policy. Also, note that CSA for
Unified CVP is not supported on the device running Unified CVP Call Studio, nor on any non-CVP
devices. There are specific versions of CSA for other Cisco devices
Content Services Switch
The Content Services Switch (CSS) is a load-balancing device designed to provide robust, highly
available and scalable network services for data centers. The CSS can be logically placed between one
or more VoiceXML Gateways and one or more Unified CVP VXML Servers, Media Servers, and
ASR/TTS Servers. Various mechanisms allow the CSS to implement transparent load balancing and
failover across these servers. One of these mechanism is the stateful redundancy mechanism, which is
called Adaptive Session Redundancy in CSS terms. Adaptive Session Redundancy (ASR) provides
session-level redundancy for applications where active flows (including TCP and UDP) must continue
without interruption, even if the master CSS fails-over to the backup CSS.
CSS is an optional device, but it is highly recommended. Without it, the IVR Service implements a poor
man's failover mechanism, but it is not load-balanced and various retries and delays are part of the
algorithm, all of which can be avoided if CSS is used.
The CSS is normally deployed as a Virtual Router Redundancy Protocol (VRRP) pair. VRRP provides
box-to-box redundancy for CSS pairs. For session-level redundancy (stateful failover), CSS pairs could
use the Adaptive Session Redundancy option to minimize VXML Server license port usage during a CSS
failover. VRRP is useful in all deployment models except for Call Director call flows, which do not
require use of Unified CVP VXML Servers, Media Servers, or ASR/TTS servers. If SSL is used in the
solution, you will need an SSL module for the CSS 11503 or 11506 chassis.
1-15
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
Application Content Engine (ACE)
You may use the Application Content Engine (ACE) as an alternative to the Content Services Switch
(CSS) for server load balancing and failover. As a load-balancing device, ACE determines which server
in a set of load-balanced servers, should receive the client request for service. Load balancing helps
fulfill the client request in the shortest amount of time without overloading either the server or the server
farm as a whole.
Refer to the Cisco ACE 4700 Series Appliance Server Load-Balancing Configuration Guide to learn
more about load-balancing with ACE.
To migrate from CSS to ACE, use the ACE2CSS Converter tool. Refer to:
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A2/configuration/
css_to_ace/user/guide/cssaceug.html
To configure Unified CVP for ACE. refer to the Configuration and Administration Guide for Cisco
Unified Customer Voice Portal available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.html
You must have an ACE license to use ACE under load conditions. The minimum licensing requirements
for ACE are:
• 1-Gbps throughput license (ACE-AP-01-LIC)
• A non-default SSL feature license, if you intend to use ACE for SSL
• Application Acceleration License (ACE-AP-OPT-LIC-K9) which allows more than 50 concurrent
connections on ACE
Refer to the your 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
Refer to 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
Third-Party Media Server
The media server component is a simple web server, such as Microsoft IIS or Apache, and is an optional
component that can provide prerecorded audio files, external VoiceXML documents, or external ASR
grammars to the gateway. Because some of these files can be stored in local flash memory on the
gateways, the media server can be an optional component. However, in practice, most installations use
a centralized media server to simplify distribution of prerecorded customer prompt updates. Media
server functionality can also include a caching engine. The gateways themselves, however, can also do
prompt caching when configured for caching. Typical media servers used are Microsoft IIS and Apache,
both of which are HTTP-based.
As with ASR/TTS Servers, Media Servers may be deployed simplex, as a redundant pair, or with CSS
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.
1-16
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Unified CVP Product and Solution Components
The Media Server can be installed co-resident with the Unified CVP Call Server or Unified CVP
VXML Server.
For the most current information on media servers, refer to 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
Third-Party Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Servers
This component provides speech recognition services and text-to-speech services for the VoiceXML
Gateway. Communication between the ASR/TTS server(s) and the VoiceXML Gateway uses Media
Resource Control Protocol (MRCP). MRCP v1 can be used on the VoiceXML Gateway when the
application is based on either 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 VXML Server.
For capacity and redundancy reasons, a Content Services Switch (CSS) is usually used to mediate
between a VoiceXML Gateway and a farm of ASR/TTS servers. If CSS is not used, then a VoiceXML
Gateway can support a maximum of two ASR/TTS Servers.
Cisco does not sell, OEM, or support any ASR/TTS software or servers. Cisco does, however, test
Unified CVP with ScanSoft, Nuance, and IBM offerings. 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, by which Unified ICM passes a pointer to
an external grammar source. The 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, ScanSoft,
Nuance, and IBM are the supported ASR/TTS engines. These ASR/TTS engines also support (with
limitations) voice recognition and synthesis for multiple languages.
For the latest information on supported languages and limitations of these ASR/TTS engines, refer to
the following websites:
• Nuance and ScanSoft
http://www.nuance.com
• IBM
http://www-306.ibm.com/software/voice/
These are third-party products, 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 with Cisco Unified
1-17
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Call Flows
CVP. For additional details on supported ASR and TTS products, consult 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
Network Monitor
An SNMP management station can be used to monitor the solution deployment's health.
Call Flows
This section describes the Unified CVP call flows for both SIP and H.323 calls.
Typical SIP Unified CVP Call Flow
Unified CVP provides the ability to switch calls using Session Initiation Protocol (SIP) rather than, or
in addition to, H.323. SIP is the preferred protocol for Unified CVP. The H.323 protocol support is
available primarily to provide backward compatibility for users of previous versions of Unified CVP.
These are referred to as legacy deployments.
The remainder of this topic presents a typical call flow scenario using SIP. The description roughly
follows the Comprehensive call flow model. However, it is not presented as an actual solution, only as
an introduction to the overall flow of information in a Unified CVP solution.
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.
Typical SIP Unified CVP call flow:
1. The call arrives at an Ingress Voice Gateway and sends an invite message to the SIP Proxy Server
which forwards the message to the SIP Service.
2. The Proxy Server determines the IP address of the Unified CVP Server for the dialed number and
then forwards the invite to the selected Unified CVP Server SIP Service.
1-18
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Call Flows
3. The SIP Service consults Unified ICME via the Unified CVP Server ICM Service, which causes
Unified ICME to run a routing script.
4. The routing script typically initiates a transfer of the call to a VoiceXML Gateway port via the SIP
service.
5. The VoiceXML Gateway sends a message to the IVR service, which requests scripted instructions
from Unified ICME.
6. Unified ICME exchanges VRU instructions with the VoiceXML gateway via the IVR service. The
instructions can include requests to invoke more sophisticated applications on the Unified CVP
VXML server. Such requests result in multiple exchanges between the Unified CVP VXML Server
and the VoiceXML Gateway to provide self-service.
7. If the customer wants to transfer to a live agent, the Unified ICME routing script queues the caller
for an available agent. While waiting for an available agent, Unified ICME provides additional
instructions to the VoiceXML Gateway to provide queueing treatment to the caller.
8. When an agent becomes available, Unified ICME sends a message to the Unified CVP Server SIP
Service, which forwards a message via the SIP Proxy Server to the Ingress Gateway and to
Unified CM to transfer the call away from the VoiceXML Gateway port and deliver it to the
Unified CM agent IP phone.
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 Content Services Switch (CSS), which offers
sophisticated failover and redundancy capability. (CSSs are optional, though recommended, and are not
displayed in the diagram.)
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
(Operations Console). 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.
VXML Server applications are designed and built using Call Studio (essentially an offline tool and not
shown in the diagram).
Typical H.323 Unified CVP Call Flow
This topic, and the following diagram, present a typical call flow scenario using H.323. Like the previous
SIP description, it follows the Comprehensive call flow model, but is only intended as an introduction,
not as a suggested implementation.
1-19
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Design Process
H.323 Call Flow:
1. A typical H.323 Unified CVP call arrives at an ingress voice gateway and sends a route request to
the H.323 Gatekeeper to determine which Unified CVP Server should receive this new call.
2. The ingress gateway interacts with the Unified CVP Server H.323 Service, which consults Unified
ICME via the Unified CVP Server IVR Service and Unified CVP Server ICM Service. This
consultation causes Unified ICME to run a routing script.
3. The routing script typically initiates a transfer of the call to a VoiceXML Gateway port via the ICM,
IVR, and H.323 Services.
4. The VoiceXML Gateway sends a message to the H.323 Service, which requests scripted instructions
from Unified ICME via the IVR and ICM Services.
5. Unified ICME exchanges VRU instructions with the VoiceXML Gateway via the ICM, IVR, and
H.323 IVR Services. Among these VRU instructions can be requests to invoke more sophisticated
applications on the Unified CVP VXML Server. Such requests will result in multiple exchanges
between the Unified CVP VXML Server and the VoiceXML Gateway in order to provide
self-service.
6. If the customer wants to transfer to a live agent, the Unified ICME routing script queues for an
available agent. While waiting for an available agent, the Unified ICME provides additional
instruction to the VoiceXML Gateway to provide queueing treatment to the caller.
7. When an agent becomes available, Unified ICME sends a message to the Unified CVP Server H.323
Service, which queries the H.323 gatekeeper for routing instructions to the appropriate Unified CM
H.323 trunk.
8. The H.323 Service signals to the Ingress Gateway and Unified CM to transfer the call away from
the VoiceXML Gateway port and deliver it to the Unified CM agent IP phone.
Refer to Typical SIP Unified CVP Call Flow, page 1-17 for more information.
Design Process
When designing a Unified CVP deployment consider the following high-level steps:
1. It is critical to first choose a call flow model for your functional deployment.
2. After choosing a call flow model, Unified CVP solution designers must determine where the Unified
CVP components are going to be deployed (in the data center or at a branch).
1-20
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Design Process
3. Then Unified CVP solution designers much choose the amount of availability and resiliency that is
justifiable or required.
4. Finally, Unified CVP solution designers must size the deployment to provide the justifiable or
required grade of service for the initial deployment and near-term growth.
Note SIP Protocol Best Choice for Unified CVP Deployments
SIP provides improved scalability, performance, and interoperability. It is the preferred protocol to use
for call control.
H.323 and Unified CVP
For users of previous versions of Unified CVP, where SIP was not an alternative, upgrading while
keeping call flows unchanged (at least initially) is a useful option. Indeed, a Unified CVP solution is
capable of running as a hybrid, that is, some call flows using H.323 and some using SIP. The software
must all be upgraded first; then flows must be cut over in groups, perhaps by DNIS or by application (see
the discussion in Installation and Upgrade Guide for Cisco Unified Customer Voice Portal). A single
call can be controlled by either SIP or H.323, but not both. Different call legs on the same overall call
should also be consistent regarding protocol, either SIP or H323. For example, if the TDM call is SIP,
then the consult from the UCM into CVP by the agent should also use SIP. However, a single Unified
CVP component can carry some calls in each category.
Most customers who are staying with H.323 are advised to move to the Comprehensive Call Flow Model,
if they currently use Queue and Transfer.
SIP implementation is not equivalent to H.323. SIP does not support GKTMP. If this feature is required,
you must remain with H.323 protocol.
Note For information on converting from H.323 to SIP, refer to the Configuration and Administration Guide
for Cisco Unified Customer Voice Portal.
Call Flow Models
As mentioned previously, the first step in the design process is to determine what functionality you need.
Unified CVP offers a number of call flow models to support differing needs. The deployment model you
choose depends on the call flow preferences, geographic distribution requirements, and hardware
configurations that best satisfy your company's needs.
• Unified CVP VXML Server (standalone) — Provides a standalone VRU with no integration to
Unified ICM for queuing control or subsequent call control. Used to deploy self-service VXML
applications.
• Call Director — Provides IP switching services only.
This model is useful if you want to:
–
Only use Unified CVP to provide Unified ICME with VoIP call switching.
–
Want to prompt/collect using third-party VRUs and ACDs.
–
Do not want to use a Unified CVP VXML Server.
• Comprehensive — Provides IVR services, queue treatment, and IP switching services. The
previously described typical call flows use this functional deployment model.
1-21
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Design Process
This model is useful if you want to:
–
Want to use Unified CVP to provide Unified ICME with VoIP call switching capabilities.
–
Want to use Unified CVP to provide Unified ICME with VRU services—including integrated
self-service applications, queuing, and/or initial prompt and collect.
–
Want to use video IVR, video queuing, and video agent capabilities.
–
Might want to use an optional Unified CVP VXML Server.
–
Might want to prompt or collect using optional ASR/TTS services.
• 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.
–
Do not want to use Unified CVP for switching calls.
–
Might want to use an optional Unified CVP VXML Server.
–
Might want to prompt or collect 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, page 2-1.
How Unified CVP Routes Outbound Calls (Unified CVP Algorithm for Routing)
When you are configuring a dial plan and call routing, you can combine Unified CVP features (such as
Location Based CAC, SigDigits, SendToOriginator, LocalSRV, and Use Outbound Proxy) to achieve
your desired effect.
The following priority and conditionals are used to formulate the destination SIP URI for the outbound
calls made by Unified CVP. This description covers CONNECT messages which include labels from the
ICM (VXML GW, CUCM, etc), as well as calls to the ringtone service, recording servers, and error
message playback service.
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 Send to Originator 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.
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.
1-22
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Design Process
5. Else throw RouteNotFoundException WARNING trace in the logs.
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.
Distributed Network Options
After choosing a functional deployment model, Unified CVP solution designers must determine where
the Unified CVP components will be deployed. Unified CVP deployment can use one of the following
primary distributed network options:
• Combined Branch Gateways — Enables call treatment at the edge and integration of locally dialed
numbers into the enterprise virtual contact center. This option can be either a combined Ingress and
VoiceXML gateway, or separate gateways, but typically the gateways are combined when deployed
in a branch.
• Branch Ingress Gateways with Centralized VoiceXML Gateways — Enables integration of locally
dialed numbers and resource grouping of VoiceXML gateways. This option might be desirable for
organizations with many medium to large branches, but with few contact center calls in those
branches. However, VRU announcements would have to traverse the WAN from the VoiceXML
Gateway to the Ingress Gateway.
• Branch Egress Gateways — Enables calls to be transferred across the WAN to remote TDM
terminations.
• Branch Agents — Enables a virtual contact center where agents can be located anywhere on the IP
network.
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, page 3-1.
Cube Deployment with SIP Trunks
The use of third party SIP trunks with Unified CVP is supported by using the Cisco Unified Border
Element (CUBE) product. CUBE performs the role of session border controller (SBC), for SIP
normalization and interoperability.
Note ASR100X platform is not supported for CUBE with CVP Solution.
CUBE on ISR gateways is supported. Also, survivability service is supported on the CUBE gateway.
1-23
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Design Process
Design Considerations
Please observe the following restrictions when deploying CUBE with SIP Trunks:
• Specifically with REFER call flows initiated with Unified CVP Call Server, CUBE does not
currently support passing the Refer-To header URI destination as-is from CVP. It rewrites the
destination address based on the dial peer configuration. The impact of this issue is that dial plan
needs to be duplicated on CVP and CUBE. The following note is further explanation.
Note IOS voice architecture and call routing is based on the assumption that dial-peer match is
required for all outbound calls. All voice components (SIP, H.323, Application) in IOS presume
that there is a matched dial-peer for an outgoing call and tries to get the call properties from that
dial-peer.
Routing a Unified CVP-initiated REFER transparently through CUBE, without a dial peer
configuration, is not supported.
• 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 a Unified CVP generated REFER message with GTD or NSS
mime body pass through. It will send the REFER, but will drop the mime body portion.
• If you plan to use the Alternate Destination Routing (ADR) feature of the service provider, do not
use Unified CVP survivability.
High Availability Options
After choosing a functional deployment model and distributed deployment options, Unified CVP
solution designers must choose the amount of availability required. Unified CVP solution designers can
increase solution availability in the following areas:
• Multiple gateways, Unified CVP Servers, Unified CVP VXML Servers, VRU PGs, Cisco Unified
Presence Servers, and gatekeepers — Enables inbound and outbound call processing and IVR
services to continue upon component failure.
• Multiple call processing locations — Enables call processing to continue in the event of a loss of
another call processing location.
• Redundant WAN links — Enables Unified CVP call processing to occur upon failure of individual
WAN links.
• Content Services Switches — Provides an efficient means to remove failed Unified CVP Servers,
Unified CVP VXML Servers, and Media Servers from the load-balancing algorithms being used for
those components.
• Application Content Engine (ACE) — Provides an alternative to the Content Services Switch (CSS)
for server load balancing and failover.
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
Designing Unified CVP for High Availability, page 4-1.
1-24
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Quality of Service (QoS)
Scalability Options
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 Content Services Switch (CSS) or the Application
Content Engine (ACE) Refer to Content Services Switch, page 1-14 and Application Content Engine
(ACE), page 1-15.
For more details on choosing appropriate hardware for your deployment, see the chapter on Sizing,
page 14-1.
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:
• 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 physically on the host.
For specific information about virtualization with Unified CVP, refer to:
http://www.cisco.com/go/uc-virtualized.
Quality of Service (QoS)
Quality of Service is the measure of transmission quality and service availability of a network. Unified
CVP implements Layer 3 QoS defaults on all relevant network paths, and 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, refer to the Operations Console online help.
For QoS design information, refer to the Enterprise QoS 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.
1-25
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
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/C
CBU_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.
1-26
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 1 Unified CVP Architecture Overview
Licensing Information
CHAPTER
2-1
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
2
Functional Deployment Models
Last revised on: October 13, 2010
This chapter covers the following functional deployment models for Unified CVP:
• Unified CVP VXML Server (Standalone), page 2-2
• Call Director, page 2-4
• Comprehensive, page 2-6
• VRU Only, page 2-11
For each model, this chapter provides a short discussion of the typical customer requirements for that
deployment model, a list of the 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. Distributed deployment scenarios where
components are separated across a WAN link are discussed in the chapter on Distributed Deployments,
page 3-1. High-availability deployment options are covered in the chapter on Designing Unified CVP
for High Availability, page 4-1.
What's New in This Chapter
Table 2-1 lists the topics that are new in this chapter or that have changed significantly from previous
releases of this document.
Table 2-1 New or Changed Information Since the Previous Release of This Document
New or Revised Topic Described in:
There are no new topics for the April 12, 2010 version of
the SRND.
2-2
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Unified CVP VXML Server (Standalone)
Unified CVP VXML Server (Standalone)
This deployment model is the simplest of the Unified CVP functional deployment models. It provides
organizations with a standalone IVR solution for automated self-service. 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. Figure 2-1 illustrates this model.
Figure 2-1 Functional Deployment Model for a Unified CVP VXML Server (Standalone)
This model requires the following components:
• Ingress voice gateway(s)
• VoiceXML gateway(s) (Can be co-resident with the ingress gateway)
• Unified CVP VXML Server(s)
• Cisco Unified Call Studio
• Unified CVP Operations Console Server
Optional components for this model include:
• ASR/TTS server(s)
• Third-party media server(s)
• Content Services Switch(es)
• Application Content Engine (ACE)
• Egress voice gateway(s)
• Unified CVP Reporting Server
Protocol-Level Call Flow
1. A call arrives at the ingress gateway via TDM, SIP, or H.323. The gateway performs normal inbound
POTS or VoIP dial-peer matching.
2. The selected VoiceXML gateway port invokes the Unified CVP self-service TCL script.
3. The TCL script invokes the Unified CVP standalone bootstrap VoiceXML Document, which
performs an HTTP request to the configured IP address of the Unified CVP VXML Server.
270619
Customer Data
servers
PSTN VXML
MRCP/RTSP
IOS
Gateway
ASR/TTS
V
Unified CVP
VXML server
(standalone)
Backend
Interface
2-3
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Unified CVP VXML Server (Standalone)
4. The Unified CVP VXML Server runs the application specified in the HTTP URL and returns a
dynamically generated VoiceXML document to the VoiceXML gateway. The Unified CVP
VXML Server application may access back-end systems to incorporate personalized data into the
VoiceXML document that is sent to the VoiceXML gateway.
5. The VoiceXML gateway parses and renders the VoiceXML document. For spoken output, the
VoiceXML gateway either retrieves and plays back prerecorded audio files referenced in the
VoiceXML document, 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 dialogue ends when either the caller hangs up, the application releases, or the application
initiates a transfer.
Transfers and Subsequent Call Control
In addition to providing self-service, the Standalone VoiceXML deployment model can transfer callers
to another endpoint – either VoIP (for example, Cisco Unified Communications Manager) or TDM (for
example, egress voice gateway to PSTN or TDM ACD). However, no IVR application data can be passed
to the new endpoint with this deployment model, therefore there will be no agent screen pop if the
endpoint is a TDM ACD.
This model supports the following types of transfers:
• VoiceXML Bridged Transfer
• VoiceXML Blind Transfer
• Release Trunk Transfer (TNT, hookflash, TBCT, and SIP Refer)
The VoiceXML transfers are invoked using Cisco Unified Call Studio's transfer element. Release Trunk
Transfers are invoked by providing specially formatted return values in Cisco Unified Call Studio's
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 to the chapter on Call Transfer Options, page 10-1.
2-4
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Call Director
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, and they wish to use 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 cradle-to-grave reporting for all
calls. Although customers can have a 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 Cisco Unified Contact Center Enterprise, 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.
Call Director deployments can utilize either H.323, SIP, or a combination.
This model requires the following components:
• Ingress voice gateway(s)
• Egress voice gateway(s)
• Unified CVP Server
• Unified CVP Operations Console Server
• Cisco Unified ICM Enterprise
• H.323 gatekeeper (H.323 deployments)
• SIP Proxy Server (for SIP deployments)
Optional components for this model include:
• Unified CVP Reporting Server
SIP Protocol-Level Call Flow
VoIP-based Pre-Routing
1. A call arrives at the ingress gateway and sends a SIP INVITE message to the SIP Proxy Server,
which forwards the request to the Unified CVP Server SIP Service.
2. The SIP Service sends a route request to Unified ICM via the Unified CVP Server ICM Service and
the VRU PG. This route request causes Cisco Unified ICM to run a routing script based upon the
dialed number and other criteria.
3. The Unified ICM routing script selects a target and returns a translation route label to the Unified
CVP Server SIP Service, which then signals via the SIP Proxy Server to the egress voice gateway
(which connects to the TDM termination) and the ingress voice gateway to enable the call to be set
up between the ingress and egress voice gateways. While the RTP stream flows directly between the
ingress and egress voice gateways, call control signaling flows through Unified CVP in order to
allow subsequent call control.
2-5
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Call Director
4. When the call arrives at the selected termination, the termination equipment sends a request to its
PG for routing instructions. This step resolves the translation route and allows any call data from the
previously run Unified ICM script to be passed to the selected termination. If the selected
termination is a TDM IVR platform, then self-service will be provided and the caller can either
release or request to be transferred to a live agent. If the selected termination is a TDM ACD
platform, then the caller will be queued until an available agent is selected by the TDM ACD. Call
data can then be popped onto the agent screen. After receiving live assistance, the caller can either
release or request to be transferred to another agent.
VoIP-based Transfer
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 (via its PG) to Cisco 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.
H.323 Protocol-Level Call Flow
VoIP-based Pre-Routing
1. A call arrives at the ingress gateway and sends a RAS request to the H.323 gatekeeper to find the IP
address of an appropriate Unified CVP Server for that dialed number.
2. The ingress voice gateway then sends an H.225 call setup message to the Unified CVP Server H.323
Service. For a brief instance, a G.711 voice stream exists between the ingress voice gateway and the
Unified CVP Server H.323 Service.
3. The Unified CVP Server H.323 Service sends a route request to Cisco Unified ICM via the Unified
CVP Server IVR Service, Unified CVP ICM Service, and VRU PG. This request causes Unified
ICM to run a routing script based upon the dialed number and other criteria.
4. The Unified ICM routing script selects a target and returns a translation route label (dialed number)
to the Unified CVP Server H.323 Service, which then sends a RAS request to the H.323 gatekeeper
to find the IP address of the selected termination (an egress voice gateway to the PSTN or
front-ending a TDM peripheral).
5. The Unified CVP Server H.323 Service then sends an H.225 call setup message to the egress voice
gateway and makes an Empty Capability Set (ECS) request to the ingress voice gateway to redirect
the call. While the RTP stream flows directly between the ingress and egress voice gateways, call
control signaling flows through Unified CVP in order to allow subsequent call control.
6. When the call arrives at the selected termination, the termination equipment sends a request to its
PG for routing instructions. This step resolves the translation route and allows any call data from the
previously run Unified ICM script to be passed to the selected termination. If the selected
termination is a TDM IVR platform, then self-service will be provided and the caller can either
release or request to be transferred to a live agent. If the selected termination is a TDM ACD
2-6
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Comprehensive
platform, then the caller will be queued until an available agent is selected by the TDM ACD. Call
data can then be popped onto the agent screen. After receiving live assistance, the caller can either
release or request to be transferred to another agent.
VoIP-based Transfer
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 will send a
post-route request with call data (via its PG) to Cisco 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 H.323 Service to release the call leg to the originally selected
termination and to extend the call to a new termination. The H.323 Service queries the H.323
gatekeeper in order to get an IP address for the 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.
Transfers and Subsequent Call Control
In addition to the transfers managed by Unified ICM (as described above), the Call Director deployment
model can transfer calls to non-ICM terminations or invoke a Release Trunk Transfer in the PSTN. If a
call is transferred to a non-ICM termination, then no call data can be passed to the termination, no further
call control is possible for that call, and the cradle-to-grave call reporting that Unified ICM captures is
completed. In the case of a Release Trunk Transfer, the ingress voice gateway port is released, no call
data can be passed to the termination, and no further call control is possible for that call. If the Release
Trunk Transfer was translation-routed to another ICM peripheral, call data and cradle-to-grave reporting
can be maintained. For more details on transfers, see the chapter on Call Transfer Options, page 10-1.
If a selected termination (for either a new or transferred call) returns a connection failure or busy status,
or if the target rings for a period of time that exceeds the Unified CVP Call Server's ring-no-answer
(RNA) timeout setting, the Unified CVP Call Server cancels the transfer request and sends a transfer
failure indication to Unified ICM. This scenario causes a Router Requery operation. The Unified ICM
routing script then recovers control and has the opportunity to select a different target or take other
remedial action.
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 data between these endpoints and provide cradle-to-grave reporting for
all calls. Figure 2-2 illustrates this model.
2-7
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Comprehensive
Figure 2-2 Comprehensive Functional Deployment 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 either H.323, SIP, or a combination.
This model requires the following components:
• Ingress voice gateway(s)
• VoiceXML gateway(s) (Can be co-resident with the ingress gateway)
• Unified CVP Server
• Unified CVP Operations Console Server
• Cisco Unified ICM Enterprise
• H.323 gatekeeper (for H.323 deployments)
• SIP Proxy Server (for SIP deployments)
Optional components for this model include:
• Unified CVP VXML Server
• Egress voice gateway(s)
• ASR / TTS server(s)
• Third-party media server(s)
• Content Services Switch(es)
• Application Content Engine (ACE)
• Unified CVP Reporting Server
270617
Unified CVP
VXML server
Customer Data
servers
PSTN VXML GED-125
Backend
Interface
SIP or H.323
SIP or H.323
MRCP/RTSP
IOS
Gateway
ASR/TTS
CVP
Call server
Agent
Endpoint
V
Cisco Unified
Communications
Manager
M
2-8
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Comprehensive
SIP Protocol-Level Call Flow
Initial Call Treatment and Self-Service
1. A call arrives at the ingress gateway and sends a SIP invite message to the SIP Proxy Server, which
forwards the request to the Unified CVP Server SIP Service.
2. The SIP Service sends a route request to Unified ICM via the Unified CVP Server ICM Service and
the VRU PG. This route request causes Cisco Unified ICM to run a routing script based upon the
dialed number and other criteria.
3. The Unified ICM routing script utilizes a Send to VRU node to return a label to the SIP Service to
have the call sent to a VoiceXML gateway. The Unified CVP Server SIP Service sends an invite
message to the VoiceXML gateway via the SIP Proxy Server, which translates the label DN to the
IP address of the VoiceXML gateway.
4. The Voice XML gateway sends an HTTP new-call message to the Unified CVP Server IVR Service
with the label DN provided by Unified ICM. The IVR Service then sends a route request message
to Unified ICM (via the Unified ICM Service), which then allows Unified ICM to re-enter the
previously started routing script. The routing script is re-entered at the successful exit path of the
Send to VRU node. The Unified ICM routing script then uses Run Script nodes to instruct the IVR
service about the desired call treatment. If call treatment requires complex IVR self-services, service
control can be redirected to a Unified CVP VXML Server application. Upon completion of the
Unified CVP VXML Server application or a request by the caller to transfer to a live agent, service
control is returned to the Unified CVP Server IVR Service. If the initial call treatment is simple with
just a few prompts, then the IVR Service can utilize Unified CVP microapplications to generate
VoiceXML documents for the VoiceXML gateway, and a Unified CVP VXML Server is not
required.
Caller Requests to Transfer to Live Agent
1. When the caller requests to transfer to a live agent, the Unified ICM routing script queues the caller
for an appropriate skill group and sends Run VRU Script messages to the IVR Service to have queue
treatment provided (assuming no agent is available).
2. When a Unified CCE agent becomes available, Unified ICM requests the Unified CVP Server IVR
Service to transfer the call the selected agent.
3. The IVR Service then requests the SIP Service to transfer the caller to the dialed number of the
selected agent. The SIP Service then sends a SIP invite message to the SIP Proxy Server, which finds
the Cisco Unified Communications Manager SIP Trunk IP address associated with this agent DN,
and then forwards the SIP Invite message to Cisco Unified Communications Manager (Unified CM).
4. Unified CM accepts the incoming SIP Trunk call and routes it to the selected agent.
Caller Requests to be Transferred to a Second Skill Group
1. If the caller requests to be transferred to a second agent, then the first agent will initiate a transfer
from their Unified CCE agent desktop application. This action generates a route request from the
agent PG to the Unified ICM central controller. Unified ICM then executes a routing script that
queues the call to another skill group. Assuming no agent is available, the Unified ICM script will
use the Send to VRU node, which will signal to the SIP Service to release the call leg to the
Unified CM SIP Trunk and connect the call back to a VoiceXML gateway.
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. Unified ICM then 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.
2-9
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Comprehensive
3. When a second Unified CCE agent becomes available, Unified ICM requests the Unified CVP
Server IVR Service to transfer the call the selected agent.
4. The IVR Service then requests the SIP Service to transfer the caller to the dialed number of the
selected agent. The SIP Service then 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 CVP 7.0(2) 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).
H.323 Protocol-Level Call Flow
Initial Call Treatment and Self-Service
1. A call arrives at the ingress gateway and sends a RAS request to the H.323 gatekeeper to find the IP
address of the Unified CVP Server for that dialed number.
2. The ingress voice gateway then sends an H.225 call setup message to the Unified CVP Server H.323
Service. For a brief instance, a G.711 voice stream exists between the ingress voice gateway and the
Unified CVP Server H.323 Service.
3. The Unified CVP Server H.323 Service sends a route request to Cisco Unified ICM via the Unified
CVP Server IVR Service, Unified CVP ICM Service, and VRU PG. This request causes Unified
ICM to run a routing script based upon the dialed number and other criteria.
4. The Unified ICM routing script utilizes a Send to VRU node to return a label to the H.323 Service
to have the call sent to a VoiceXML gateway. The H.323 Service sends a RAS request to the H.323
gatekeeper to find the IP Address of the VoiceXML gateway associated with the label returned by
Unified ICM. The Unified CVP H.323 Service sends an H.225 setup message to the VXML
Gateway.
5. The Voice XML gateway sends an HTTP new-call message to the Unified CVP Server IVR Service,
with the label DN provided by Unified ICM. The IVR Service then sends a route request message
to Unified ICM (via the IVR Service, ICM Service, and VRU PG), which then allows Unified ICM
to re-enter the previously started routing script. The routing script is re-entered at the successful exit
path of the Send to VRU node. The Unified ICM routing script then uses Run Script nodes to instruct
the IVR service about the desired call treatment. If call treatment requires complex IVR
self-services, service control can be redirected to a Unified CVP VXML Server application. Upon
completion of the Unified CVP VXML Server application or a request by the caller to transfer to a
live agent, service control is returned to the Unified CVP Server IVR Service. If the initial call
treatment is simple with just a few prompts, then the IVR Service can utilize Unified CVP
microapplications to generate VoiceXML documents for the VoiceXML gateway, and a
Unified CVP VXML Server is not required.
2-10
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Comprehensive
Caller Requests to Transfer to Live Agent
1. When the caller requests to transfer to a live agent, the Unified ICM routing script queues the caller
for an appropriate skill group and sends Run VRU Script messages to the IVR Service to have queue
treatment provided (assuming no agent is available).
2. When a Unified CCE agent becomes available, Unified ICM requests the Unified CVP Server IVR
Service to transfer the call the selected agent.
3. The IVR Service then requests the H.323 Service to transfer the caller to the dialed number of the
selected agent. The H.323 Service then sends a RAS message to the H.323 gatekeeper to find the
Unified CM H.323 Trunk IP address associated with this agent DN, and then sends an H.225 call
setup message to Unified CM.
4. Unified CM accepts the incoming H.323 trunk call and routes it to the selected agent.
Caller Requests to be Transferred to a Second Skill Group
1. If the caller requests to be transferred to a second agent, then the first agent will initiate a transfer
from their Unified CCE agent desktop application. This action generates a route request from the
agent PG to the Unified ICM central controller. Unified ICM then executes a routing script that
queues the call to another skill group. Assuming no agent is available, the Unified ICM script will
use the Send to VRU node, which signals to the H.323 Service to release the call leg to the
Unified CM H.323 Trunk and to connect the call back to a VoiceXML gateway. A RAS request to
the H.323 gatekeeper is to find the IP address of the VoiceXML gateway.
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. Unified ICM then 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 the selected agent.
4. The IVR Service then requests the H.323 Service to transfer the caller to the dialed number of the
selected agent. The H.323 Service sends a RAS request to the H.323 gatekeeper to get the IP address
of the Unified CM H.323 trunk associated with the second agent DN. The H.323 Service then sends
an H.225 setup message to Unified CM.
5. Unified CM accepts the incoming H.323 trunk call and routes it to the second agent.
Transfers and Subsequent Call Control
In addition to transfers manager by Unified ICM (as described above), the Comprehensive deployment
model can transfer calls to non-ICM terminations or it can invoke a Release Trunk Transfer in the PSTN.
If a call is transferred to a non-ICM termination, then no call data can be passed to the termination, no
further call control is possible for that call, and the cradle-to-grave call reporting that Unified ICM
captures is completed. In the case of a Release Trunk Transfer, the ingress voice gateway port is released,
no call data can be passed to the termination, and no further call control is possible for that call. If the
Release Trunk Transfer was translation-routed to another ICM peripheral, call data and cradle-to-grave
reporting can be maintained. For more details on transfers, see the chapter on Call Transfer Options,
page 10-1.
If a selected termination (for either a new or transferred call) returns a connection failure or busy status,
or if the target rings for a period of time that exceeds the Unified CVP Call Server's ring-no-answer
(RNA) timeout setting, the Unified CVP Call Server cancels the transfer request and sends a transfer
2-11
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
VRU Only
failure indication to Unified ICM. This scenario causes a Router Requery operation. The Unified ICM
routing script then recovers control and has the opportunity to select a different target or take other
remedial action.
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 via a Cisco Unified
ICM PSTN Network Interface Controller (NIC). Two Unified ICM PSTN NICs are available that 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 IVRs); they also allow Unified ICM to invoke mid-call
transfers in the PSTN. Figure 2-3 illustrates this model.
Figure 2-3 Functional Deployment Model for VRU Only
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 (via 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 via a VoiceXML gateway, the Unified CVP Server IVR Service, the
Unified CVP Server ICM Service, and Unified ICM. In this functional deployment model, neither the
Unified CVP Server H.323 Service nor the Unified CVP Server SIP Service is 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 cradle-to-grave reporting for all calls.
270618
Customer Data
servers
PSTN VXML GED-125
MRCP/RTSP
IOS
Gateway
PSTN Switch
or PGW
ASR/TTS
CVP
Call server
ICM
PSTN NIC
V
Unified CVP
VXML server
Backend
Interface
2-12
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
VRU Only
This model requires the following components:
• Ingress voice gateway(s)
• VoiceXML gateway(s) (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)
Optional components for this model include:
• Unified CVP VXML Server
• ASR / TTS server(s)
• Third-party media server(s)
• Content Services Switch(es)
• Application Content Engine (ACE)
• Unified CVP Reporting Server
• H.323 gatekeeper (for H.323 deployments)
• SIP Proxy Server (for SIP deployments)
Protocol-Level Call Flow
Initial Call Treatment and Self-Service
1. A call arrives at the PSTN, and the PSTN sends a new-call message to Unified ICM via either a
CRSP NIC or SS7 NIC. Unified ICM invokes a routing script based upon the dialed number, and the
routing script uses either a Send to VRU node or a Translation Route to VRU node to send a result
to the PSTN to have the call routed to the Unified CVP ingress voice gateway. Depending upon the
PSTN capability and Unified ICM VRU type for the Unified CVP deployment, the response returned
to the PSTN is either a translation route label (dialed number) or a dialed number plus correlation
ID.
2. The PSTN routes the call to an available ingress voice gateway port. The ingress voice gateway
performs normal inbound POTS dial-peer matching to deliver the call to an available VoiceXML
gateway port. An H.323 RAS request to an H.323 gatekeeper or a SIP Invite message to a SIP Proxy
server could be used to aid in the routing of the call to an available VoiceXML gateway port, if
desired.
3. The Voice XML gateway sends an HTTP new-call message to the Unified CVP Server IVR Service
with the dialed number delivered from the PSTN. This dialed number represents either a translation
route label or a correlation ID. Either way, the Unified ICM VRU PG will recognize this call and
send a request instruction message to the in-progress Unified ICM routing script. The next routing
script node is typically a Run VRU Script node to instruct the VRU which microapplication is to be
executed.
4. The Unified CVP Server IVR Service sends a dynamically generated VoiceXML document to the
VoiceXML gateway for rendering.
5. The VoiceXML gateway parses and renders the VoiceXML document. If call treatment requires
complex IVR self-services, service control can be redirected to a Unified CVP VXML Server
application. Upon completion of the Unified CVP VXML Server application or a request by the
caller to transfer to a live agent, service control is returned to Unified CVP Server IVR Service. If
the initial call treatment is simple with just a few prompts, then the IVR Service can utilize Unified
2-13
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Basic Video Service
CVP microapplications to generate VoiceXML documents for the VoiceXML gateway, and a
Unified CVP VXML Server is not required. If desired, the Unified ICM routing script can terminate
the call, and a disconnect message will be sent by the Unified ICM to the PSTN via the PSTN NIC.
Caller Requests to Transfer to Live Agent
6. When the caller requests to transfer to a live agent, the Unified ICM routing script queues the caller
for an appropriate skill group and sends Run VRU Script messages to the IVR Service to have queue
treatment provided (assuming no agent is available).
7. When a Unified CCE agent or a TDM ACD agent becomes available, Unified ICM immediately
sends a connect message to the PSTN via the PSTN NIC. The connect message will contain either
a translation route label or a dialed number plus correlation ID (depending upon the PSTN
capabilities). Upon receipt of the connect request, the PSTN releases the call leg to the Unified CVP
ingress voice gateway and connects the call to the new termination. If the new termination is a TDM
ACD, the previous queueing treatment could be skipped and the TDM ACD could provide the queue
treatment. Any call data associated with this call will be passed to the Unified ICM Peripheral
Gateway (PG) for the selected peripheral.
Caller Requests to be Transferred to a Second Skill Group
8. If the caller requests to be transferred to a second agent, then the first agent will initiate 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.
9. 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 via 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 (via the Unified CM
PG) to transfer the call.
Basic Video Service
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 Service:
• Cisco Unified IP Phone 7985G
• Cisco Unified Video Advantage
• Cisco TelePresence
The Basic Video Service supports the following call flows with Cisco TelePresence:
• A TelePresence caller dials into Unified CVP, receives audio-only IVR and/or queuing treatment,
and then is transferred to an Agent on a second TelePresence unit.
• A TelePresence caller dials into Unified CVP, receives audio-only IVR and/or queuing treatment,
and then is transferred to an Agent on a second TelePresence unit. The TelePresence Agent can
conference in a second Agent on an audio-only IP phone by dialing a direct extension from their
TelePresence phone.
• A TelePresence caller dials into Unified CVP, receives audio-only IVR and/or queuing treatment,
and then is transferred to an Agent on a second TelePresence unit. The TelePresence Agent can
conference in a Unified CVP dialed number that results in audio queuing, followed by connection
to a second Agent on an audio-only IP phone.
2-14
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 2 Functional Deployment Models
Basic Video Service
• A TelePresence caller dials into Unified CVP, receives audio-only IVR and/or queuing treatment,
and then is transferred to an Agent on an audio-only IP Phone. MTP must be enabled on the SIP
trunk or else one-way audio is encountered.
Because the Basic Video Service is simply an extension of the SIP-based Comprehensive deployment
model, the required components and SIP protocol-level call flow details are identical.
CHAPTER
3-1
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
3
Distributed Deployments
Last revised on: May 2, 2010
In a distributed deployment, the ingress gateways are geographically separated from the Unified CVP
Call Server. This chapter discusses how these types of deployments should be designed as well as how
to handle call survivability and call admission control.
The chapter covers the following major topics:
• Distributed Gateways, page 3-1
• Call Survivability in Distributed Deployments, page 3-5
• Call Admission Control Considerations, page 3-6
What's New in This Chapter
Table 3-1 lists the topics that are new in this chapter or that have changed significantly from previous
releases of this document.
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.
Ingress and/or Egress Gateway at the Branch
In this deployment model, ingress gateways located at a branch office are typically used to provide
callers with access using local phone numbers rather than centralized or non-geographic numbers. This
capability is especially important in international deployments spanning multiple countries. Egress
Table 3-1 New or Changed Information Since the Previous Release of This Document
New or Revised Topic Description
Multicast Music-on-Hold (MOH), page 3-4 Describes two methods for using Multicast
Music-on-Hold.
RSVP, page 3-10 RSVP available for SIP trunks.
3-2
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Distributed Gateways
gateways are located at branches either for localized PSTN breakout or for integration of decentralized
TDM platforms into the Unified CVP switching solution. Apart from the gateways, all other Unified
CVP components are centrally located, and WAN links provide data connectivity from each branch
location to the central data center.
Ingress or VoiceXML Gateway at Branch
Consideration needs to be given to other voice services that are being run at the branch. For example,
the branch is typically a remote Cisco Unified Communications Manager (Unified CM) site supporting
both ACD agent and non-agent phones. This model also implies that the PSTN gateway is used not only
for ingress of Unified CVP calls but also for ingress/egress of normal user calls for that site. In
circumstances where the 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 downside of this method is that each NetworkVRU requires its own
VRU scripts in Unified ICM. The Unified ICM configuration overhead of making a change to each
NetworkVRU script quickly becomes overwhelming when a large number of remote sites are
required.
• Configure Unified CVP using the SigDigits feature.
The SigDigits feature in Unified CVP allows you to use the dial plan on the SIP Proxy or gatekeeper
to route calls to the correct site. When the call arrives at an ingress gateway, the gateway will
prepend digits before sending the call to Unified CVP. Those prepended digits are unique to that site
from a dial-plan perspective.
When the call arrives at Unified CVP, Unified CVP will strip the prepended digits and store 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, which 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 will prepend the
digits that it stored in memory before initiating the transfer. The dial plan in the SIP Proxy or
gatekeeper 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. The
prepended digits are prepended as a tech-prefix when using H.323.
It is important to remember that when the VXML gateway receives the call, the CVP bootstrap
service will be 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 VXML request. Note that digits could be prepended to
translation route DNs as well, and that the egress or receiving component (such as Cisco Unified
CM) may need to strip digits to see the original DN.
3-3
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Distributed Gateways
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 setsigdigits X for H.323,
and for SIP it is called Prepend Digits 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, page 3-6, for more information.)
Co-Located Unified CVP VXML Servers and Gateways
Either all gateways and servers are centralized or each site has its own set of co-located Unified CVP
VXML Servers and gateways.
Advantages of co-location:
• A WAN outage does not impact self-service applications.
• No WAN bandwidth is required.
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.
Gateways at the Branch, with Centralized Unified CVP VXML Servers
Advantages of centralized VoiceXML:
• Administration and reporting are centralized.
• Unified CVP VXML Server capacity can be shared among branch offices.
Disadvantages of centralized VoiceXML:
• Branch survivability is limited.
• WAN bandwidth must be sized for additional VoiceXML over HTTP traffic.
Cisco Unified Communications Manager
In a Unified CVP environment, Cisco Unified Communications Manager (Unified CM) can be an ingress
or egress gateway. It is more common for Unified CM to be an egress gateway because typically callers
are calling from the PSTN, being queued by Unified CVP, and then being switched to Unified CM for
handling by an agent. If the caller is not calling from the PSTN but from an IP phone instead, then
Unified CM is an ingress gateway from the perspective of Unified CVP.
Unified CM as an Egress Gateway
Unified CVP normally depends on the gatekeeper for dial-plan resolution and call admission control. To
deploy Unified CM alongside Unified CVP, you must use Unified CM call admission control for calls
between the ingress Unified CVP gateway and the agent IP phone. The ability for Unified CM to identify
3-4
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Distributed Gateways
the ingress Unified CVP gateway correctly is complicated because the Unified CVP Call Server is the
component that is actually making the H.323 call to Unified CM. Therefore, Unified CM sees the call as
coming from the centralized Unified CVP Call Server rather than from the remote ingress gateway.
The Unified CVP Call Server is able to solve this problem by setting the sourcesignaladdress field
inside the H.323 setup to the IP address of the ingress gateway. Upon receiving the setup from Unified
CVP, Unified CM sees the source signaling address and knows that the address is the one that should be
used when determining from which location the call is coming. Because Unified CM has this ingress
gateway IP configured, Unified CM will use its Locations call admission control configuration to deduct
the bandwidth between the ingress gateway and the destination IP phone locations. The Unified CVP
Call Server should not be configured as a gateway in Unified CM; instead, the Unified CVP Call Server
should send calls to Unified CM via a gatekeeper-controlled H.323 trunk. (See Call Admission Control
Considerations, page 3-6, for more information on call admission control mechanisms.)
Unified CM as an Ingress Gateway
When an IP phone initiates a call to Unified CVP, Unified CM acts as the ingress gateway to Unified
CVP. An H.323 or SIP trunk is used to send calls to Unified CVP. For more information on these types
of call flows, see the chapter on Calls Originated by Cisco Unified Communications Manager, page 6-1.
Multicast Music-on-Hold (MOH)
Multicasting may be used for Music-on-Hold with supplementary services on Unified CM as an
alternative to the unicast MOH. There are two ways to deploy using this feature:
• With Unified CM multicasting the packets on the local LAN
• With the branch gateway(s) multicasting on their local LAN(s)
Use the latter method when SRST (survivable remote site telephony) is configured on the gateway. This
method enables the deployment to use MOH locally and avoid MOH streaming over the WAN link.
Note References for Using Multicast MOH
Refer to the following for configuring MOH on the Call Manager Enterprise (CME):
http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmemoh.html#w
pmkr1022205
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/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 all doesn't 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.
3-5
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Call Survivability in Distributed Deployments
Call Survivability in Distributed Deployments
Distributed deployments require design considerations for other voice services that are being run at the
branch. For example, the branch is typically a remote Unified CM site supporting both ACD agent and
non-agent phones. This deployment also implies that the PSTN gateway is used not only for ingress of
Unified CVP calls but also for ingress/egress of the regular non-ACD phone calls.
Branch reliability becomes somewhat more of an issue than it is in a centralized Unified CVP model
because WANs are typically less reliable than LAN links. Therefore, you must provide mechanisms that
are local to the branch to gracefully handle calls that are impacted by loss of a WAN link to the central
site.
Call survivability must be considered for both the Unified CVP and non-CVP calls. For the Unified CM
endpoint phones, survivability is accomplished via a Cisco IOS feature known as Survivable Remote
Site Telephony (SRST). For further details on SRST, refer to 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 H.225 or 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, refer to 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. So 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, refer to the latest
version of Configuration and Administration Guide for Cisco Unified Customer Voice Portal, available
at
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_g
uides_list.html.
Also refer to Cube Deployment with SIP Trunks, page 1-22.
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.
3-6
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Call Admission Control Considerations
Note Router requery is not supported when using SIP Refer with Unified CVP Comprehensive Call Flow, and
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 itself.
Call Admission Control Considerations
Call admission control must also be considered from a solution perspective, not just a Unified CVP
perspective. These considerations are most evident in the distributed branch office model where there
are other voice services, such as Cisco Unified CM, sharing the same gateways with Unified CVP and
the amount of bandwidth between the sites is limited. The most important item to consider in this case
is which call admission control mechanisms are in place on the network so that a consistent call
admission control mechanism can be used to account for all the calls traversing the WAN from that site.
If two call admission control mechanisms can admit four calls each and the WAN link is able to handle
only four calls, then it is possible for both call admission control entities to admit four calls onto the
WAN simultaneously and thereby impair the voice quality. If a single call admission mechanism cannot
be implemented, then each call admission control mechanism must have bandwidth allocated to it. This
situation is not desirable because it leads to inefficient bandwidth over-provisioning.
There are three call admission control mechanisms that can be used in a Unified CVP environment:
gatekeeper call admission control, Unified CM Locations, and Unified CM RSVP Agent. In a single-site
deployment, call admission control is not necessary.
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
Gatekeeper Call Admission Control
In a pure TDM environment where Unified CVP is switching calls from an ingress gateway to an egress
gateway attached to a TDM ACD/IVR, the gatekeeper can handle the call admission control
functionality.
If Unified CM is the egress gateway, gatekeeper call admission control can be used only if the ingress
Unified CVP gateways and the IP phones are at different sites. Note that gatekeeper dial-plan resolution
is still in use.
Because Unified CM locations-based call admission control is used between the remote sites of a cluster,
a gatekeeper typically is used for dial-plan resolution only. Understanding the routing of calls in the dial
plan and the gatekeeper resolution is important because call routing situations might occur in which it is
necessary to use more than one set of gatekeepers in the implementation. This is particularly common
3-7
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Call Admission Control Considerations
when using this model in a situation where more than one Unified CM cluster are being used to control
the remote sites. For further discussion and information on this topic, see H.323 Gatekeeper Call
Routing, page 3-10.
Unified CM Call Admission Control
If Unified CM is sending or receiving calls from Unified CVP and there are Unified CVP gateways and
IP phone agents co-located at remote sites, it is important to understand the call flows in order to design
and configure call admission control correctly.
H.323 Call Flows
The gatekeeper and Unified CM do not share bandwidth usage information. Networks shared by both the
gatekeeper and IP phones will have two separate call admission control mechanisms determining if there
is enough bandwidth to place a call. Instead of using the gatekeeper for call admission control, it is
possible to use Unified CM Locations as the call admission control mechanism for Unified CVP calls.
How Unified CM determines an endpoint’s location is key to designing call admission control properly.
Consider the basic call flow of a Unified CVP call versus a non-CVP call. When a user picks up an IP
phone and makes a call from the remote site to the central site, Unified CM considers the location
definitions of the endpoints and the codec requirements defined in the Unified CM Region
configurations and decides whether or not to allow the call. Note that the call admission control and the
codec requirements are controlled between these endpoints by Unified CM as the controlling call agent.
By default, Unified CM looks at the source IP address of an incoming H.323 call to determine which
H.323 device is originating the call. Unified CM then uses the configuration of this device to determine
its location and to perform call admission control for the call. When Unified CVP is delivering calls from
a remote branch gateway to a Unified CM IP Phone, Unified CVP is in the middle of the H.323 signaling,
so the source IP address from Unified CM's perspective is the Unified CVP Server. Because the Unified
CVP Server is centralized along with Unified CM, it is not possible to perform call admission control
based on the Unified CVP Server's IP address. Unified CM must be aware that calls arriving from
Unified CVP are actually coming from a gateway at a specific branch so that it can calculate call
admission control correctly. In order to solve this problem, Unified CVP must be configured to insert
information in the payload of the H.323 SETUP message that identifies the IP address of the originating
gateway, and Unified CM must be configured to look at this information when determining on which
gateway an H.323 call is arriving.
This requires enabling one Unified CM service parameter and ensuring that another parameter is set to
its default value:
• Change the cluster-wide service parameter Accept unknown TCP connection to True. (The default
is False.)
• Ensure that the service parameter Device Name of gatekeeper trunk that will use port 1720
remains at its default setting of blank.
When set to True, the service parameter Accept Unknown TCP Connection changes the behavior for
inbound H.323 calls. Unified CM accepts an unknown H.225 TCP connection and waits for the H.323
SETUP message. Unified CM then extracts the User-to-User Information Element (UUIE) and examines
the sourceCallSignalAddress field, which contains the IP address of the originating gateway.
Unified CM compares this address against its configured gateways. If a match is found, the call is treated
as if it originated from the voice gateway and not the Unified CVP Server. The Unified CVP Server IP
address must not be configured as an H.323 gateway, otherwise Unified CM will match first on the
source IP address and will not look at the information in the sourceCallSignalAddress field. In order to
3-8
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Call Admission Control Considerations
deliver calls to Unified CM from Unified CVP without specifying Unified CVP as an H.323 gateway,
you must configure an H.323 Gatekeeper Trunk in Unified CM so that Unified CVP will sends calls to
Unified CM via the gatekeeper over the trunk.
The Unified CM service parameter Device Name of gatekeeper trunk that will use port 1720 is used
to force a gatekeeper-controlled trunk to register to a gatekeeper on port 1720. This feature causes any
inbound H323 call that is signaling on port 1720 to be treated immediately as a gatekeeper-controlled
trunk call. The H.225 signaling address is not examined in this case.
This behavior is not how Unified CM traditionally treats a gatekeeper-controlled H.323 call. Typically,
all gatekeeper-controlled calls come from the hub location (location None or Hub_None). These changes
ensure that the call is not treated as a gatekeeper-controlled call and that locations-based call admission
control is applied. Note that, in this model, if Unified CM does not match the gateway signaling address
in its list of configured gateways, it rejects the call. Figure 3-1 illustrates the decision tree for H.323 call
processing.
Figure 3-1 Cisco Unified CM H.323 Signaling Flow Topology
To configure Unified CVP to work correctly with Unified CM call admission control, use VBAdmin to
set the Unified CVP Server parameter setlocationsbasedcac on. This setting tells Unified CVP to
populate the sourceCallSignalAddress field and to use TCP port 1720 when sending calls to Unified CM.
191324
Match
Match
No Match
Equals
Port 1720
No
Not equal to
Port 1720
No
Match
Match
Inbound H.323 call
to Cisco Unified
CallManager
Check
H.225 TCP connection
peer IP address
against configured
H.323 gateways.
Process call,
sourcing it as if from
configured gateway.
Ye s
No Match
Examine
signaling
port number.
Is it configured as
a gatekeeper
controlled trunk?
Does the port number
match a dynamic port used
for a configured
gatekeeper controlled trunk?
Process call as an
incoming gatekeeper
controlled trunk call.
Send ARQ to gatekeeper,
and process call using
the IP peer address.
Wait for H.225
Setup Message,
then extract source
signaling address.
Check
H.225 signaling
addressagainst
configured H.323
gateways
H225ReleaseComplete
with cause IE - Call
Rejected. User hears
re-order tone.
Process call,
sourcing it as if from
configured gateway.
Accept inbound
H.225 TCP
connection.
3-9
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Call Admission Control Considerations
When using this feature in conjunction with calls originated by Unified CM, the
sourceCallSignalAddress populated by Unified CVP will be the IP address of Unified CM. If the call is
transferred back to Unified CM, it will inspect this field and try to find a configured gateway with that
IP address, but the call will fail because normally Unified CM will never be configured as a gateway. As
a workaround to this problem, configure each Unified CM in the cluster as an H.323 gateway, but be sure
to never configure the Unified CM dial plan to send calls using those gateways.
Multiple Cisco Unified CM Clusters
When more than one centralized Unified CM cluster are used for the remote sites, additional
consideration must be given to routing calls based on agent selection. In a multi-cluster environment,
each cluster manages a group of remote sites and tracks the voice calls to those sites within the
locations-based call admission control mechanism. Using the changes discussed above, Unified CM
considers H.323 calls within its locations-based call admission control mechanism. Because H.323 is a
peer-to-peer protocol, an H.323 gateway can signal a call to any other call agent that will accept it.
Considering the locations-based call admission control mechanism described above, it is necessary for
the remote gateway to be told to signal a call to the Unified CM cluster that owns the location of that
remote gateway. However, in a Unified CCE environment, Unified ICM tracks the availability of agents
without considering on which cluster they are located. This ability provides great scalability for
Unified CCE but must be accounted for in this type of implementation.
If a call coming in through a Unified CVP ingress gateway is destined for an IP Phone at a different site
registered to a different cluster, the call must first be routed through the cluster that is handling call
admission control for the ingress gateway, and then routed to the destination cluster. If the call is routed
directly from the ingress gateway to the destination cluster, the cluster that is handling call admission
control for the ingress gateway is not aware of the call traversing the WAN and does not deduct
bandwidth appropriately.
This call routing can be handled by using the SigDigits feature in Unified CVP and its associated
dial-plan configuration. The SigDigits feature in Unified CVP allows you to use the dial plan on the SIP
Proxy or gatekeeper to route calls to a specific Unified CM cluster. When the call arrives at an ingress
gateway, the gateway will prepend digits before sending the call to Unified CVP. Those prepended digits
are unique to that site from a dial-plan perspective. When the call arrives at Unified CVP, Unified CVP
will strip the prepended digits and store them in memory, resulting in the original DID on which the call
arrived. When Unified ICM returns a label to Unified CVP in order to transfer the call to an agent phone,
Unified CVP will prepend the digits that it stored in memory before initiating the transfer. The dial-plan
configuration in the SIP Proxy or gatekeeper is configured with the prepended digits so that calls with a
certain prepended digit string are sent to a specific Unified CM cluster. The digits are prepended as a
tech-prefix when using H.323.
For more information on how the SigDigits feature works, see Distributed VoiceXML Gateways
(Separate Ingress Gateway and VoiceXML), page 4-25.
3-10
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Call Admission Control Considerations
SIP Call Flows
With SIP-based call flows, Cisco Unified CM 6.0 (and prior releases) is able to look at only the source
IP address of the incoming SIP INVITE from Unified CVP. This limitation causes a problem with call
admission control because Unified CM is not able to identify which gateway behind Unified CVP
originated the call.
Cisco Unified CM 6.1 has enhanced the SIP Trunk to look beyond the source IP address and to inspect
information contained in the SIP header when determining which device originated a call. This
enhancement allows the SIP trunk to be dynamically selected by the original source IP address rather
than the remote port on Unified CVP, and therefore different SIP profiles and settings can be used on the
source trunks that are different from the Unified CVP trunk.
More specifically, the Call-Info header in the SIP INVITE will specify the originating device in the
following format:
<sip: IPAddress:port>;purpose=x-c isco-origIP
Where IPAddress:port indicates the originating device and its SIP signaling port.
This source IP SIP trunk selection feature does not impact the bandwidth monitoring for call admission
control. In Unified CM release 8.0, bandwidth monitoring is performed with SIP using locations
configuration on Unified CVP and Unified CM. The following header is used by the location server in
Unified CM to manipulate bandwidth information for call admission control.
Call-Info: [urn:x-cisco-remotecc:callinfo];x-cisco-loc-id="PKID";x-cisco-loc-name="Loc-NAME"
RSVP
Cisco Unified CM 5.0 introduced support for Resource Reservation Protocol (RSVP) between endpoints
within a cluster, and 8.0 UCM introduces RSVP over the SIP Trunk. 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 or H323 in the 8.0 release.
The recommended solution for CAC is to employ Locations configuration on Unified CVP and in
Unified CM.
For more information on RSVP, refer to 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
H.323 Gatekeeper Call Routing
For proper configuration of remote H.323 gateways with a Unified CM cluster, first consider the H.225
implications of this configuration without the use of gatekeeper.
When configuring dial-peer destinations for the Cisco IOS Gateways, you must configure a dial peer
pointing to the IP addresses of the Unified CM servers that are processing calls for that gateway. These
server IP addresses must be the same servers that are in the redundancy group of the device pool
definition for that gateway in the Unified CM configuration. (See Figure 3-2.) If the remote H.323
gateway sends a call to a Unified CM server that is not in the redundancy group for that gateway, the call
is rejected. For example, if the Madison gateway in Figure 3-2 sends a call to the.3 server, the call is
rejected.
3-11
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Call Admission Control Considerations
Figure 3-2 Dial Peer Configuration
While the example in Figure 3-2 is simple to understand, the configuration can become challenging to
maintain for several hundred remote sites over an extended period of time. If the Cisco Unified CM
gatekeeper redundancy group is changed, all the remote H.323 gateway dial-peer targets must be
changed to match the new IP address of the server added to the redundancy group. A gatekeeper can help
reduce this challenge.
When using the gatekeeper for configuration, the H.323 gateway makes a Registration Admission Status
(RAS) request to the gatekeeper for an IP address to which to send the call. The gatekeeper automatically
responds with one of the Unified CM server addresses defined in the redundancy group for the
gatekeeper trunk. If the redundancy group is changed, Unified CM must re-register to the gatekeeper.
However, no further configuration is necessary on the remote gateway.
191325
San Jose Headquarters
.1
.3
.2
WAN V
M
M
M
M
Publisher
Madison
Dial Peer Configuration
dial-peer voice 1 voip
destination-pattern 1...
preference 1
session target ipv4:10.10.10.1
dial-peer voice 2 voip
destination-pattern 1...
preference 2
session target ipv4:10.10.10.2
Be sure to configure a dial peer for each
Cisco Unified CallManager server in the
redundancy group and device pool assigned
to the gateway in Cisco Unified CallManager.
Ensure that the IP addresses in the configurations
match on both sides of the link.
The Cisco Unified CallManager redundancy
group for the Madison gateway contains the
.1 and .2 servers.
3-12
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 3 Distributed Deployments
Call Admission Control Considerations
CHAPTER
4-1
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
4
Designing Unified CVP for High Availability
Last revised on: April 4, 2011
This chapter describes guidelines and best practices for designing a high-availability Unified CVP
system.
This chapter covers the following topics:
• Overview, page 4-2
• Layer 2 Switch, page 4-3
• Originating Gateway, page 4-4
• SIP Proxy, page 4-5
• Unified CVP SIP Service, page 4-11
• Server Groups, page 4-14
• Gatekeeper, page 4-16
• Unified CVP H.323 Service, page 4-19
• Unified CVP IVR Service, page 4-21
• VoiceXML Gateway, page 4-23
• Content Services Switch (CSS), page 4-28
• Media Server, page 4-30
• Unified CVP VXML Server, page 4-31
• Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server, page 4-32
• Cisco Unified Communications Manager, page 4-33
• Intelligent Contact Management (ICM), page 4-34
4-2
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
What's New in This Chapter
What's New in This Chapter
Table 4-1 lists the topics that are new in this chapter or that have changed significantly from previous
releases of this document.
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
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,
including the network infrastructure. A good Unified CVP design is tolerant of most failures (defined
later in this chapter), 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 preparation and design planning to avoid costly upgrades
or maintenance later in the deployment cycle. Always design for the worst possible 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).
Table 4-1 New or Changed Information Since the Previous Release of This Document
New or Revised Topic Description
Cisco Unified SIP Proxy (CUSP) Support,
page 4-7
Two deployment methods for the CUSP proxy
server
Server Groups, page 4-14 Dynamic routing feature that enables the
originating endpoint to have knowledge of the
status of the destination address before attempting
to send the SIP INVITE
VoiceXML Gateway, page 4-23 Support for mixed G.729 and G.711 codecs on
different legs of the same call, and new load
balancing assistance features
4-3
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Layer 2 Switch
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:
• H.323 Service — Responsible for H.323 processing of incoming and outgoing calls as well as
registering with the gatekeeper. The H.323 Service was known as the Unified CVP Voice Browser
in previous versions of Unified CVP.
• 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.
Layer 2 Switch
Figure 4-1 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. The following sections
describe the failover strategy for each of these components.
Figure 4-1 Redundant Unified CVP System
191323
SIP Proxy /
Gatekeeper
SIP Proxy /
Gatekeeper
VRU PG
VXML
server
Call
server
CSS /
ACE
V
PSTN
VRU PG
VXML
server
Call
server
CSS /
ACE
V
4-4
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Originating Gateway
In Figure 4-1, 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 Content Services Switch (CSS) 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 CSS
is still functional.
• Although Figure 4-1 shows a CSS being used for redundancy, you may also use the Application
Content Engine (ACE). Refer to Application Content Engine (ACE), page 1-15.
For more information on data center network design, refer to the Data Center documentation available at
http://www.cisco.com/go/designzone
Note NIC teaming is not currently supported in the Unified CVP solution.
Note 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:
• Configuration, page 4-4
• Call Disposition, page 4-19
Configuration
For the most current information on how to provide redundancy and reliability for originating gateways
and T1/E1 lines, 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_gui
des_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 H.323 or SIP. Unlike MGCP, SIP and H.323 do not have redundancy features built into the
protocol. Instead, SIP and H.323 rely on the gateways and call processing components for
redundancy.
• When configuring the gateway, it is best to bind the H.323 or SIP signaling to the virtual loopback
interface, as illustrated in the following configuration examples:
H.323:
4-5
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
SIP Proxy
interface Loopback0
ip address 10.0.0.10 255.255.255.255
h323-gateway voip interface
h323-gateway voip id sj-gk ipaddr 10.0.1.100 1719 <<- GK IP
h323-gateway voip h323-id sj-gw1
h323-gateway voip bind srcaddr 10.0.0.10
SIP:
voice service voip
sip
bind control source-interface Loopback0
bind media source-interface Loopback0
This configuration allows call signaling to operate independent of the physical interfaces. In this
way, if one interface fails, the other interface can handle the traffic. 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 Router(s) for the network is then configured with redundant routes to the Loopback address
through the use of static routes or a routing protocol. If a routing protocol is used, pay careful
attention to 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.
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.
SIP Proxy
A SIP Proxy server plays a similar role to the gatekeeper in a Unified CVP solution. 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 and/or hardware required for SIP Proxy if not already deployed.
4-6
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
SIP Proxy
• Static routes using Server Groups (DNS SRV records) on a DNS Server
–
Advantages:
Weighted load balancing and redundancy.
–
Disadvantages:
Might not be able to use an existing DNS server, depending on the location of the DNS server.
The ability to share or delegate DNS server administration rights might not be possible in some
organizations.
Dial-plan configuration needs to be configured on each device individually (Cisco Unified
Communications Manager, 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, or so forth, this will affect performance.
• Static routes using local DNS SRV records
–
Advantages:
Weighted load balancing and redundancy.
Does not depend on an external DNS Server, thus eliminating a point of failure, latency, and
DNS Server performance concerns.
–
Disadvantages:
Dial plan must be configured on each device individually (Cisco Unified Communications
Manager, Unified CVP, and gateways).
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, the per-hop delay is
3.5 seconds (if retry count is 2) or 7.5 seconds (if retry count is 3). This delay is on every call or every
other call (on average) during failure, depending on load balancing, and is accordance with section
17.1.1.1 of RFC 3261 regrading the T1 timer.
• Static routes using IP addresses
–
Advantages:
Does not depend on any other device (DNS or Proxy) to deliver calls to the destination.
–
Disadvantages:
No redundancy possible for SIP calls from Unified CVP.
Dial plan must be configured on each device individually.
This option makes sense only for environments that do not have redundancy (single server) or for
lab deployments.
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, page 4-11.
Note Due to long delays when DNS is used with the Cisco Unified Presence proxy server, Cisco recommends
that you disable the DNS server on the Cisco Unified Presence server (CUP Server). Refer to CUP Server
release notes for more information.
4-7
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
SIP Proxy
Cisco Unified SIP Proxy (CUSP) Support
The 8.0(1) release of Unified CVP has been validated with Cisco Unified SIP Proxy Server (CUSP
Server) version 1.1.4. This means that Unified CVP now supports both the CUP and CUSP proxy servers.
The following bullets show the differences between the two implementations:
• CUSP is a dedicated SIP proxy server, whereas the CUP proxy is a presence server with a proxy
engine.
• There is a difference in the hardware they run on: the CUSP server runs on the gateway, and the CUP
server runs in the MCS machine.
• CUP also has different default settings. For example, Record Route is on by default on the CUP
proxy, since it is needed for MS OCS federation. Record route is off by default on the CUSP proxy.
• For additional information, refer to the Solution sizing tool:
http://tools.cisco.com/cucst/faces/login.jsp
CUSP Deployment Methods
There are 2 deployment options supported with CUSP proxy in the CVP solution. These methods are
presented in the next two topics.
Deployment Option A - Redundant Sip Proxy Servers
This method:
• Consists of 2 gateways for redundancy, geographically separated, 1 proxy module each, using SRV
priority for redundancy of proxies, no HSRP.
• The ISR is dedicated to the proxy blade function and is not co-located as a VXML gateway, or as a
TDM gateway, due to platform validation restrictions on CUSP.
• TDM gateways are configured with SRV or with Dial Peer Preferences to use the primary and
secondary CUSP proxies.
• CUSP is set with Server Groups to find primary and back up Unified CVP, Unified CM and VXML
gateways.
• Unified CVP is set up with Server Group to use the primary and secondary CUSP proxies.
• Cisco Unified CM is set up with a Route Group with multiple SIP Trunks, to use the primary and
secondary CUSP proxies.
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)
4-8
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
SIP Proxy
Deployment Option B - Redundant SIP Proxy Servers (Double Capacity)
This method:
• Consists of 2 gateways for redundancy, 2 proxy modules in each chassis. All 4 proxy servers are in
active mode with calls being balanced between them.
• Uses SRV to load balance across proxies with priority.
• The ISR is dedicated to the proxy blade function and is not co-located as a VXML gateway, nor as
a TDM gateway, due to platform validation restrictions on CUSP.
• TDM gateways are set with SRV or with Dial Peer Preferences to use the primary and secondary
CUSP proxies.
• CUSP is set with Server Groups to find primary and back up Unified CVP, Unified CM and VXML
gateways.
• Unified CVP is set up with Server Group to use the primary and secondary CUSP proxies.
• Cisco Unified CM is set up with Route Group with multiple SIP Trunks, to use the primary and
secondary CUSP proxies.
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)
Performance Matrix for CUSP Deployment
Table #2 in the CUSP public data sheet “Performance Measured in the Number of New Call Attempts
per Second" shows performance data for the CUSP server.
CUSP baseline tests were done in isolation on the proxy, and capacity numbers (450 TCP, 500 UDP
transactions per second) should be used as the highest benchmark, and most stressed condition
allowable.
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
When a consult with CVP queuing occurs, an additional 4 SIP transactions will be incurred for the
session, effectively doubling the number of calls.
4-9
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
SIP Proxy
CUSP Design Considerations
Always turn the Record Route setting off on the proxy server to avoid a single point of failure and allow
fault tolerance routing, as well as increase the performance of the Proxy server. Using record route
setting on the proxy server doubles the impact to performance, as shown in the CUSP baseline matrix,
and also breaks the high availability model since the proxy becomes a single point of failure for the call,
if the proxy were to go down.
Record Route is turned off by default on CUSP.
Note Upstream Element Routing with SIP Heartbeats
With CUSP proxy, any response to a INVITE or OPTIONS is a good response, so CUSP will not mark
an element down when it receives a response. If the response is configured in the failover response code
list for the server group, then CUSP will failover to the next element in the group; otherwise, it will send
the response downstream as the final response.
The CUP proxy version 7.0(5) supports upstream route destination status using OPTIONS ping and
INVITE requests, but with a variation on how it was implemented in CUSP. CUP will only start pinging
a route only after it has failed a call attempt or a OPTIONS ping with any 5XX response. It will mark
the destination as out-of-service with any 5XX response to an INVITE or an OPTIONS message.
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.
SIP Proxy Server Configuration
The SIP Proxy Server should be configured with static routes that point at the appropriate devices
(Unified CVP Call Servers, VoiceXML gateways, Cisco Unified Communications Manager cluster, and
so forth). The SIP Proxy Server configuration allows you to specify the priority of the routes. In the case
where there are multiple routes to the same destination, you can configure the SIP Proxy to load-balance
across the destinations with equal priority or to send the calls in a prioritized manner using different
priorities.
The Cisco Unified Presence Server 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 Cisco Unified
Presence Server does support the DNS SRV feature, but it has not been tested in Unified CVP
deployments.) The static routes can point to an IP address or a regular DNS A host record.
To reduce the impact of a Proxy Server failure, Cisco recommends that you disable the RecordRoute
header from being populated by the SIP Proxy Server. (It is on by default on a Cisco Unified Presence
Server proxy.) In this way, the inbound calls route through a SIP Proxy; but once they reach the Unified
CVP Call Server (Call Server), the signaling is exchanged directly between the originating device and
the Call Server, and a SIP Proxy failure will not affect the calls in progress.
4-10
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
SIP Proxy
Cisco IOS Gateway Configuration
With Cisco IOS gateways, dial-peers are used to match phone numbers, and the destination can be a SIP
Proxy Server, DNS SRV, or IP address. The following example shows a Cisco IOS gateway configuration
to send calls to a SIP Proxy Server using the SIP Proxy's IP address.
sip-ua
sip-server ipv4:10.4.1.100:5060
dial-peer voice 1000 voip
session target sip-server
...
The sip-server command on the dial-peer tells the Cisco IOS gateway to use the globally defined
sip-server that is configured under the sip-ua settings. In order to configure multiple SIP Proxies for
redundancy, you can change the IP address to a DNS SRV record, as shown in the following example.
The DNS SRV record allows a single DNS name to be mapped to multiple servers.
sip-ua
sip-server dns:cvp.cisco.com
dial-peer voice 1000 voip
session target sip-server
...
Alternatively, you can configure multiple dial-peers to point directly at multiple SIP Proxy servers, as
shown in the following example. This configuration allows you to specify IP addresses instead of relying
on DNS.
dial-peer voice 1000 voip
session target ipv4:10.4.1.100
preference 1
...
dial-peer voice 1000 voip
session target ipv4:10.4.1.101
preference 1
...
In the preceding examples, the calls are sent to the SIP Proxy server for dial plan resolution and call
routing. If there are multiple Unified CVP Call Servers, the SIP Proxy server would be configured with
multiple routes for load balancing and redundancy. It is possible for Cisco IOS gateways to provide load
balancing and 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
4-11
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Unified CVP SIP Service
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
Call Disposition
Calls are handled as indicated for the following failure scenarios:
• Primary SIP Proxy Server fails
Active calls are preserved. Subsequent transfers of calls are successful, provided the backup SIP
Proxy is available and the RecordRoute header is not being populated by the SIP Proxy. If the
RecordRoute header is populated, signaling to the gateway will not be possible and subsequent
transfer attempts will fail.
• All SIP Proxy Servers fail or are unreachable
New calls arriving at the gateway are default-routed if survivability is configured on the gateway.
Unified CVP SIP Service
The Unified CVP SIP Service is the service on the Unified CVP Call Server (Call Server) that handles
all incoming and outgoing SIP messaging and SIP routing. The Call Server can be configured to use a
SIP Proxy server for outbound dial plan resolution, or it can be configured to use static routes based on
IP address or DNS SRV. Call Servers do not share configuration information about static routes;
therefore, if a change needs to be made to a static route, then the change must be made on each Call
Server's SIP Service. Cisco recommends that you use a SIP Proxy Server to minimize configuration
overhead.
4-12
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Unified CVP SIP Service
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 (Operations Console), 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.
Under the SIP Service configuration, configure the following:
• Enable Outbound Proxy = True
• Use DNS SRV type query = True
• The DNS SRV record should then be configured with the list of SIP Proxy Servers.
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.
Configuring High Availability for Calls in Progress
In the event that a Call Server fails with calls in progress, it is possible to salvage all calls if certain
gateway configuration steps have been taken. A Call Server can fail in one of several ways:
• The server can crash.
• The process can crash.
• The process can hang.
• There can be a network outage.
4-13
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Unified CVP SIP Service
The configuration discussed in this section protects against all of these situations. However, the
following two situations cannot be protected against:
• Someone stops the process with calls in progress. This situation occurs when a system administrator
forgets to put the Call Server out-of-service first to allow calls in progress to finish before stopping
the process.
• The Call Server exceeds the recommended call rate. Although there is a throttle for the absolute
number of calls allowed in the Call Server, there is no throttle for 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 of the CVP solution if one of the components is
not sized correctly or if the call load is not balanced according to the weight and sizing of each call
processing component. (Refer to Chapter 14, “Sizing” for call server call rate details.)
For call survivability, configure the originating gateways as described in the latest version of the
Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configurati
on_guides_list.html
The survivability.tcl script itself 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 H.323 or SIP Service involved anywhere 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) has 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 has not hung up 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.)
4-14
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Server Groups
• New calls
New calls are directed by the 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 Groups
A Server Group is a dynamic routing feature that enables the originating endpoint to have knowledge of
the 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 can have fore-knowledge of the status through a heartbeat mechanism.
Although, there was already an H.323 endpoint registration mechanism, the Server Groups 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 to
8.0(1). 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. Release 7.0(2) 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 Release
7.0(1).
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 the Release 7.0(1) 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 Server Groups in CUSP proxy servers work the same way.
• Only endpoints defined in a Server Group may have heartbeats sent to them.
The srv.xml configuration file was used in the 7.0(1) release 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.
Release 8.0(1) 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 Heartbeating, you get the dynamic routing capability for Unified CVP to
preemptively monitor the status of endpoints. This feature only covers outbound calls from Unified CVP.
To cover the inbound calls to Unified CVP, the CUSP proxy server can send similar heartbeats to Unified
CVP, which can respond with status responses.
4-15
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Server Groups
Server Group Heartbeat Settings
The Server Group heartbeat default setting sets the ping up/down interval between any two pings; it is
not the setting between pings to the same endpoint. The Server Group does not wake up at a specific
interval and ping all elements because this approach would introduce a seesaw effect on CPU usage.
Also, it takes more resources when the system has to ping many end points. For example, for 3 total
elements across all groups, to proactively ping each element at 30 second intervals, you have to set the
ping interval at 10 seconds.
It is less deterministic for reactive mode since elements that are currently down can fluctuate so the ping
interval fluctuates with it.
Note • Heartbeat Behavior Settings for Server Groups. To turn off pinging when the element is up, set
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
will indicate the other side is alive and reachable. A 200 OK is usually returned, but proxy servers
like the Cisco Unified Presence Server (CUP Server) or Cisco Unified SIP Proxy Server (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, which is fine as well.
By default, Server Group heartbeats are performed 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 being down
completely, that is for both UDP and TCP transports. When the element is up again, it is allowed to be
routable for both UDP and TCP.
Note TLS transport is not supported.
Duplicate Server Group Elements are excluded for heartbeating since the heartbeating is already
established for that element.
Note Refer to the Configuration and Administration Guide for Cisco Unified Customer Voice Portal for
typical configurations for the Server Groups feature. Document available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_g
uides_list.html.
Static Routes Validation
The hostname or IP address of a static route is validated at startup and configuration deployment time
with a DNS lookup resolution. If the hostname does not resolve to an A record or an SRV record, then
the route is disabled and a notice is printed in the Unified CVP error log. The calls will not be routable
to this route in this state. If the host is in the local SRV Server Groups configuration as an SRV name,
then the host will not undergo this check, because it resolves to a local SRV name. IP addresses always
pass this validation.
4-16
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Gatekeeper
Design Considerations
Observe the following design considerations when implementing Server Groups:
• When you are using the Local SRV configuration, that configuration does not work with the DNS
SRV configuration. However, elements may be declared as A record hostnames instead of IP
addresses, and resolved through a DNS server lookup or in the OS etc host file.
• If you are using the CUP proxy, typically the SRV cluster name (such as proxy-servers.cisco.com)
will need to be defined in the service parameters section of the proxy configuration. Otherwise a 404
not found rejection may result. The CUSP proxy has a similar configuration in the CLI.
Diagnostics
The CVP log file has traces which show endpoint status events. Refer to the Unified CVP System CLI
instructions in the Configuration and Administration Guide for Cisco Unified Customer Voice Portal,
available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_g
uides_list.html
Gatekeeper
An H.323 gatekeeper is used when using H.323 in any of the ICM-integrated deployment models except
Model #4 (VRU Only with NIC Controlled Routing), which does not use Unified CVP for call control
at all. Additionally, if SIP is used as the call control protocol, the gatekeeper is not required. An
originating gateway can perform all of its H.323 call routing by using VoIP dial-peers that contain static
IP addresses, whereas the Unified CVP H.323 Service must always perform a gatekeeper Remote Access
Service (RAS) lookup to route calls.
Note In one particular situation, when using the VBAdmin SetTransferLabel option, the H.323 Service
ignores the IP address returned from the gatekeeper and instead routes the IVR call leg back to the
originating gateway from which the call arrived. This feature ensures that no WAN bandwidth is used
during IVR treatment or queuing. A gatekeeper is still required in this situation because the H.323
Service has to perform the gatekeeper lookup function to obtain possible alternate endpoints in the event
that the attempt to transfer the call to the originating gateway fails.
Unified CVP can use one of the following types of gatekeeper high-availability mechanisms:
• Gatekeeper Redundancy Using HSRP, page 4-16
• Gatekeeper Redundancy Using Alternate Gatekeeper, page 4-17
Only HSRP and alternate gatekeeper are supported by Unified CVP. Alternate gatekeeper support was
introduced in Unified CVP 3.1 SR1.
Gatekeeper Redundancy Using HSRP
HSRP is a Cisco proprietary router redundancy protocol that allows two or more gatekeepers to share
the same IP address in an active/standby fashion. Using HSRP, two gatekeepers work together to present
the appearance of a single virtual IP address on the LAN.
4-17
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Gatekeeper
The gatekeepers share the same IP and MAC addresses. Therefore, if one of the gatekeepers fails, the
hosts on the LAN are able to continue forwarding packets to a consistent IP and MAC address. The
process of transferring the routing responsibilities from one device to another is transparent to the user.
The H.323 endpoints (such as the Unified CVP H.323 Service, Cisco Unified Communications Manager,
and gateways) register to a virtual IP address that represents the HSRP gatekeeper pair.
If one gatekeeper fails, its partner assumes primary control. The major disadvantage of HSRP is that both
gatekeepers in the HSRP failover pair must reside on the same IP subnet or VLAN, therefore they
generally cannot be separated geographically. Gatekeepers using HSRP for redundancy also do not share
any state information. Therefore, when a failover occurs, all of the devices must re-register with the
gatekeeper from scratch.
As of Unified CVP 3.1 SR1, HSRP is no longer recommended. Instead gatekeeper clustering and
alternate gatekeeper configuration on Unified CVP is the preferred method of gatekeeper redundancy.
Gatekeeper Redundancy Using Alternate Gatekeeper
The Unified CVP H.323 Service can be configured with a list of alternate gatekeepers (as many as
needed; there is no limit). When the H.323 Service starts, it attempts to register to the first gatekeeper in
the list. If the registration is not successful, it tries the remaining gatekeepers sequentially in the list until
a successful registration occurs.
The H.323 Service stays registered to that gatekeeper until either of the following events occurs:
• That gatekeeper has some type of failure. The H.323 Service recognizes a gatekeeper failure in the
following ways:
–
The periodic RAS Registration Request (RRQ) to the gatekeeper times out or is rejected.
–
An Admission Request (ARQ) on a transfer times out.
–
The gatekeeper pro-actively tells the H.323 Service to unregister, such as when the
administrator does a shutdown on the gatekeeper configuration.
• The user does another setGK from VBAdmin. This causes the H.323 Service to register with the first
gatekeeper in the list, if that gatekeeper is available; otherwise, it once again does a sequential
attempt.
Gatekeeper clustering is not required in order to use Unified CVP alternate gatekeeper. It is possible to
have two gatekeepers identically configured and also configure Unified CVP with alternate gatekeepers
to provide redundancy.
The Unified CVP H.323 Service does not support gatekeeper clustering messages, but there is no reason
that the gatekeepers cannot be part of a GUP cluster. In this way, other H.323 endpoints that natively
support clustering (such as Cisco Unified Communications Manager and Cisco IOS gateways) can take
advantage of the benefits of gatekeeper clustering. Unified CVP simply ignores clustering messages,
such as when one of the gatekeepers in the cluster becomes overloaded or when Unified CVP registers
with the gatekeeper.
Because Unified CVP does not automatically learn the other members of the gatekeeper cluster when it
registers to the gatekeeper, it is necessary to define the gatekeeper cluster members statically in Unified
CVP. Unified CVP uses one or more of the gatekeepers in the cluster as the alternate gatekeepers in its
list and detects failure according to the rules mentioned earlier in this section.
4-18
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Gatekeeper
Configuration
This section covers the following topics:
• HSRP Configuration, page 4-18
• Alternate Gatekeeper, page 4-18
HSRP Configuration
On the primary gatekeeper, enter these commands:
interface ethernet 0
ip address 10.0.1.98 255.255.255.0
! Unique IP address for this GK
standby 1 ip 10.0.1.100
! Member of standby group 1, sharing virtual address 10.0.1.100
standby 1 preempt
! Claim active role when it has higher priority.
standby 1 priority 110
! Priority is 110.
On the backup gatekeeper, enter these commands:
interface ethernet 0
ip address 10.0.1.99 255.255.255.0
standby 1 ip 10.0.1.100
standby 1 preempt
standby 1 priority 100
On both gatekeepers, enter identical gatekeeper configurations. For example:
gatekeeper
! Enter gatekeeper configuration mode.
zone local gk-sj cisco.com 10.0.1.100
! Define local zone using HSRP virtual address as gatekeeper RAS address.
For more information, refer to the latest version of the Configuration and Administration Guide for
Cisco Unified Customer Voice Portal (CVP), available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configurati
on_guides_list.html
Alternate Gatekeeper
Configure alternate gatekeepers using Unified CVP VBAdmin, as shown in the following examples:
set GK "10.0.1.100, 10.0.2.100, 10.0.3.100"
This example sets up three gatekeepers to which the H.323 Service could possible register. In
each case, the H.323 Service registers to the first local zone that is configured in that gatekeeper.
It also uses the default RAS port 1719.
setGK "10.0.1.100:zone1:1718, 10.0.2.100"
This example causes the H.323 Service to attempt to register first to gatekeeper 10.0.1.100 on
port 1718 with local zone zone1. If that gatekeeper fails, the H.323 Service subsequently
attempts to register to 10.0.2.100 on port 1719, with the first local zone defined on that
gatekeeper.
4-19
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Unified CVP H.323 Service
Call Disposition
The call dispositions presented in this section apply to both HSRP and alternate gatekeeper.
A gatekeeper can fail in any of the following ways:
• The primary gatekeeper fails
–
Some calls in progress may not be transferred during the period that the endpoints are
re-registering to the backup gatekeeper. After the failed transfer, an error is returned to the ICM.
If the ICM script is coded to return an error (an END node does this) and survivability is
configured on the gateway, the call is default-routed.
–
New calls arriving at the incoming gateway and Unified CVP are serviced correctly, although it
is possible that some of the calls might invoke survivability during the period that the endpoints
are re-registering to the backup gatekeeper.
• All gatekeepers fail
–
The Unified CVP H.323 Service goes out of service.
–
Calls in progress are not transferred. After the failed transfer, an error is returned to the ICM.
If the ICM script is coded to return an error (an END node does this) and survivability is
configured on the gateway, the call is default-routed.
–
New calls arriving at the gateway are default-routed if survivability is configured on the
gateway.
• The primary gatekeeper degrades but does not fail
–
There are two conditions that usually cause this behavior: low memory due to memory leaks or
excessive debug levels causing CPU overload.
–
In this situation, call processing behavior is unpredictable due to the fact that there might be no
clean failover to the backup gatekeeper. If survivability is configured on the gateway, calls are
default-routed.
Unified CVP H.323 Service
When multiple Unified CVP Call Servers (Call Servers) are used for redundancy and scalability
purposes in Unified CVP, Cisco recommends using a gatekeeper for load balancing and failover services.
The H.323 Service is the component of the Call Server that processes H.323 messages and registers with
the gatekeeper.
While it is possible for the ingress PSTN gateways to send H.323 calls to the H.323 Service using
dial-peers with the specific IP address of the Call Server, doing so results in delays to callers during a
failure scenario. In this scenario, a dial-peer is statically configured on the ingress gateways to
load-balance across Unified CVP servers, or in a prioritized fashion so that the primary server is always
used under normal conditions. When the H.323 Service is no longer reachable for whatever reason, the
dial-peer will attempt to send the call to the failed server and wait for a timeout to occur before
proceeding to the next dial-peer configured, and this process occurs for each new call.
When a gatekeeper is used instead, the gateway dial-peer simply points to the gatekeeper, and the
gatekeeper is responsible for determining which Call Servers are active and it load balances across them.
The gatekeeper's registration process enables it to know which servers are available and does not suffer
from the same time-outs as dial-peers. Therefore, Cisco recommends using a gatekeeper instead of static
Cisco IOS dial-peers for redundancy and load balancing.
4-20
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Unified CVP H.323 Service
Configuration
Unified CVP H.323 configuration for high availability is performed primarily on the ingress gateways,
but it is also necessary to configure the H.323 Service to register to the gatekeeper.
Configuring High Availability for New Calls
The gatekeeper knows which Call Servers are in service or out of service. It is therefore important to let
a gatekeeper route incoming calls to a Call Server. By default, Unified CVP H.323 Services register to
the gatekeeper with a technology prefix (tech-prefix) of 2#. The Unified CVP H.323 Service must
register with a tech-prefix, and it is not possible to configure the H.323 Service without a tech-prefix.
A technology prefix is a way for the gatekeeper to categorize registering endpoints by functionality. In
general, no additional configuration is needed on the gatekeeper for incoming calls. The H.323 Service
registers to the gatekeeper with 2#, and the originating gateway prepends a 2# to the incoming Dialed
Number Identification Service (DNIS) digits. The gatekeeper automatically knows how to match the
gateway request to an available Call Server. On the gatekeeper, the command show gatekeeper
gw-type-prefix displays the route plan that the gatekeeper uses to route calls.
On the originating gateways, define the dial-peer for the Call Servers as follows:
dial-peer voice 11111 voip
session target ras
tech-prefix 2#
The command session target ras instructs the gateway to send the call to its gatekeeper. The command
tech-prefix 2# instructs the gateway to prepend 2# to the DNIS number when sending the call to the
gatekeeper.
Configuring High Availability for Calls in Progress
In the event that a Call Server fails with calls in progress, it is possible to salvage all calls if certain
gateway configuration steps have been taken. A Call Server can fail in one of the following ways:
• The server can crash.
• The process can crash.
• The process can hang.
• There can be a network outage.
The configuration discussed in this section protects against all of these situations. However, the
following two situations cannot be protected against:
• Someone stops the process with calls in progress. This situation occurs when a system administrator
forgets to put the Call Server out-of-service first to allow calls in progress to finish before stopping
the process.
• The Call Server exceeds the recommended call rate. Although there is a throttle for the absolute
number of calls allowed in the Call Server, there is no throttle for call rate. In general, exceeding
5 calls per second (cps) for an extended period of time causes the Call Server to have erratic and
unpredictable behavior. This situation can be prevented by proper sizing of the Unified CVP system.
For call survivability, configure the originating gateways as described in the latest version of the
Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configurati
on_guides_list.html
4-21
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Unified CVP IVR Service
The survivability.tcl script itself 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 Call Server involved anywhere in those models.
Additional Cisco IOS Gateway Configuration
The command in the following example disables the TCP timeout for H.225 signaling on the gateway:
voice service voip
h323
no h225 timeout keepalive
This action allows the gateway to lose connectivity with the Call Server or Cisco Unified
Communications Manager but still retain active calls. If you do no t use this command, calls that are still
active that are otherwise unaffected by the failure (that is, the RTP stream is still streaming between the
endpoints) will be disconnected when the TCP session times out.
The following commands specify the RTP media timeout:
ip rtcp report interval 2000
gateway
timer receive-rtcp 4
When the gateway detects that RTCP messages have not been received in the specified interval, the call
is disconnected.
Call Disposition
If the Unified CVP H.323 Service fails, the following conditions apply:
• Calls in progress
If the Unified CVP H.323 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 H.323
Service. If the caller has not hung up 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
New calls are directed by the gatekeeper 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 Unified CVP Standalone and NIC-routing models.)
Unified CVP IVR Service
With Unified CVP 3.1 and earlier, the IVR Service (previously called the Application Server) was
treated independently of the H.323 Service (previously called the Voice Browser) and VoiceXML
gateways. High availability was achieved by configuring the Unified CVP Voice Browser and VoiceXML
4-22
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
Unified CVP IVR Service
gateways with a list of application server IP addresses and/or using the Content Services Switch (CSS).
With Unified CVP 4.0 and later releases, the IVR Service is tightly coupled with the SIP Service or
H.323 Service. If the IVR Service goes out of service, the H.323 or SIP Service will be taken out of
service as well so that no further calls are accepted by the Unified CVP Call Server.
Configuration
No additional configuration is needed in order to tell the H.323 or SIP Service which IVR Service to use.
By default, the H.323 and 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 Server's 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 it when determining which Call Server to use.
When H.323 is used, the VoiceXML gateway examines the source IP address of the incoming call from
the Call Server. This IP address is then used as the address for the Call Server’s 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
Unlike Unified CVP 3.1 and earlier releases, with Unified CVP 4.0 and later releases you do not 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 a CSS or backup Call Server configuration
because receiving a call from the Call Server means that the server is up and operational.
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
more information, refer to the latest version of the Configuration and Administration Guide for Cisco
Unified Customer Voice Portal (CVP), available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configurati
on_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 by survivability on the originating
gateway. (Survivability does not apply in NIC-routing models.)
• New calls are directed to an in-service Unified CVP IVR Service.
4-23
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
VoiceXML Gateway
VoiceXML Gateway
The VoiceXML gateway parses and renders VoiceXML documents obtained from one or several sources:
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, and/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, page 7-6. For a discussion of the benefits and drawbacks of each codec, refer to Voice Traffic,
page 9-2.
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
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 gatekeeper for H.323, the
SIP proxy for SIP, and/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, separate the Send to VRU node 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 could also be used, but
that method is effective only if there is an 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
Refer to 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
4-24
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 4 Designing Unified CVP for High Availability
VoiceXML Gateway
Centralized VoiceXML Gateways
In this configuration, the VoiceXML gateways reside in the same data center as the Unified CVP Call
Server.
H.323 VoiceXML Gateways
On the gatekeeper, configure a zone prefix list that contains the H.323 IDs of all VoiceXML gateways at
the data center. For example, assume that there are three VoiceXML gateways in the data center with
H.323 IDs of VoiceXMLgw1, VoiceXMLgw2, and VoiceXMLgw3, and that the ICM label for the
Network VRU is 5551000. In this example, the gatekeeper distributes calls in essentially a round-robin
scheme among all three VoiceXML gateways, provided they are all in service:
zone prefix gkzone-name 5551000* gw-priority 10 VoiceXMLgw1 VoiceXMLgw2 VoiceXMLgw3
SIP VoiceXML Gateways
If you are using Cisco Unified Presence Server: On the SIP proxy server, configure a static route for the
Network VRU label for each gateway. If the VRU label is 5551000, the static rou