Cisco Customer Voice Portal (CVP) Solution Reference Network Design (SRND)

Cisco Customer Voice Portal (CVP) Solution Reference Network Design (SRND)
Customer Voice Portal (CVP) Release 3.1 March 2006
Corporate 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 526-4100
Text Part Number: OL-8408-02
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. CCSP, CCVP, the Cisco Square Bridge logo, Follow Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0601R) Cisco Customer Voice Portal (CVP) Solution Reference Network Design (SRND) 2006 Cisco Systems, Inc. All rights reserved.
CONTENTS
Preface
xiii xiii xiii xiii
Purpose Audience
Revision History
Document Organization xiv Part I: General Information xiv Part II: Deployment Models and Sizing Part III: Reference Material xiv Conventions
xv
xiv
Obtaining Documentation xv Cisco.com xv Product Documentation DVD xv Ordering Documentation xvi Documentation Feedback
xvi
Cisco Product Security Overview xvi Reporting Security Problems in Cisco Products
xvii
Obtaining Technical Assistance xvii Cisco Technical Support & Documentation Website Submitting a Service Request xviii Definitions of Service Request Severity xviii Obtaining Additional Publications and Information
1
xix
xvii
PART
High Level Architecture

1
CHA PTER
Introduction
1-1 1-1
What is the Cisco Customer Voice Portal? What is VoiceXML?

2
1-2
CHA PTER
CVP Components
2-1 2-1
Typical CVP Deployment
CVP Solution Components 2-2 CVP Call Server 2-3 Cisco Ingress and VXML Gateway
2-3
Cisco Customer Voice Portal (CVP) Solution Reference Network Design (SRND) OL-8408-02
iii
Contents
Cisco Gatekeeper 2-4 CVP VoiceXML Server 2-4 CVP VoiceXML Studio 2-5 Standalone Distributed Diagnostics and Services Network (SDDSN) 2-5 Cisco Content Services Switch (CSS) 2-5 Cisco PSTN Gateway (PGW) Softswitch 2-5 Third Party Media Server 2-6 Third Party Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server IPCC Enterprise and Intelligent Contact Management (ICM) 2-7 Cisco CallManager 2-7
2
2-6
PART
Deployment Models and Sizing

3
CHA PTER
Deployment Models
3-1
Model #1, Standalone Self Service 3-1 Customer Requirements 3-2 Caller Experience 3-2 Characteristics 3-2 Components 3-2 Protocol Level Call Flow 3-2 Transfers 3-4 Geographic Distribution Alternatives 3-4 Collocated VoiceXML Servers and Gateways 3-4 Gateways at the Branch, Centralized VoiceXML Servers (non-collocated) Model #2, CVP Call Control 3-5 Customer Requirements 3-5 Caller Experience 3-5 Characteristics 3-5 Components 3-6 Protocol Level Call Flow 3-6 Ingress Gateway New Call Flow 3-6 ICM Transfers a Call to a Target 3-6 ICM Transfers a Call to a Second Target Via Blind Network Transfer Transfers 3-7 Distributed: Ingress and/or Egress Gateway at the branch 3-8 Network Traffic 3-8 Survivability 3-8 Model #3a, CVP Call Control with Queue and Collect Customer Requirements 3-9
3-9
3-4
3-7
iv
OL-8408-02
Contents
Caller Experience 3-9 Characteristics 3-9 Components 3-10 Protocol Level Call Flow 3-10 Ingress Gateway new Call Flow 3-10 Establishment of VRU Leg to VXML Gateway 3-11 ICM Transfers the Call to a Target 3-11 ICM Transfers a Call to a Second Target Via Blind Network Transfer Transfers 3-13 Distributed: Ingress/VXML Gateway at branch 3-13 Model #3b, CVP Call Control with Queue and Self Service 3-14 Customer Requirements 3-14 Caller Experience 3-14 Characteristics 3-15 Components 3-15 Protocol Level Call Flow 3-15 Transfers 3-16 Distributed: Ingress/VXML Gateway and VoiceXML Server at branch Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service Customer Requirements 3-17 Caller Experience 3-17 Characteristics 3-17 Components 3-17 Protocol Level Call Flow 3-18
4
3-12
3-16 3-17
CHA PTER
Sizing
4-1 4-1 4-2 4-3
Sizing Overview CVP Call Server
CVP VoiceXML Server
Gateway 4-3 Choice of Gateway 4-3 Gateway Sizing 4-4 Using MGCP Gateways 4-6 Gatekeeper
3
4-6
PART
CVP Solution Design Best Practices
Contents
CHA PTER
Designing CVP for High Availability Overview

5-1 5-2
5-1
Layer 2 Switch
Originating Gateway 5-3 Configuration 5-3 Call Disposition 5-4 Gatekeeper 5-4 HSRP 5-4 Alternate Gatekeeper Configuration 5-5 HSRP 5-5 Alternate Gatekeeper Call Disposition 5-6
5-5
5-6
CVP Voice Browser 5-6 Configuration 5-7 Configuring High Availability for New Calls 5-7 Configuring High Availability for Calls in Progress Call Disposition 5-8 CVP Application Server 5-8 Configuration 5-8 Call Disposition 5-9
5-7
VoiceXML Gateway 5-10 Configuration 5-10 Centralized VoiceXML gateways 5-10 Distributed VoiceXML gateways (ingress gateway and VoiceXML same gateway) 5-10 Distributed VoiceXML gateways (ingress gateway and VoiceXML different gateway) 5-10 Alternate Endpoints 5-11 Call Disposition 5-12 Hardware Configuration for High Availability on the Voice Gateways 5-12 Content Services Switch (CSS) Configuration 5-13 Call Disposition 5-13
5-12
Media Server 5-14 Configuration when Using CVP Microapplications 5-14 Call Disposition when Using CVP Microapplications 5-14 Configuration when using CVP VoiceXML Studio scripting 5-15 CVP VoiceXML Server 5-15 Configuration 5-15
vi
OL-8408-02
Contents
Standalone Self Service Deployments Deployments using ICM 5-15 Call Disposition 5-16
5-15
Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server Configuration 5-17 Standalone Self Service Deployments 5-17 Deployments Using ICM 5-17 Call Disposition 5-18 Cisco CallManager 5-18 Configuration 5-18 Call Disposition 5-18 Intelligent Contact Management (ICM) Configuration 5-19 Call Disposition 5-19
5-19
5-17
Standalone Distributed Diagnostics and Services Network (SDDSN) Configuration 5-20 Call Disposition 5-20
6
5-19
CHA PTER
Call Survivability in Distributed Deployments Gatekeeper implications

6-2
6-1
CAC implications 6-2 Cisco CallManager as an egress Gateway 6-4 Cisco CallManager as an ingress Gateway 6-5 Multiple Cisco CallManager Clusters 6-5 RSVP
6-5
H.323 Gatekeeper Call Routing implications in a distributed branch CVP model (Centralized CallManager model) 6-5 Multiple Cisco CallManager Clusters 6-6
7
CHA PTER
Call Transfer Options
7-1
Release Trunk Transfers 7-1 Takeback-N-Transfer (TNT) 7-2 Hook flash and Wink 7-2 Two B Channel Transfer (TBCT) 7-3 ICM Managed Transfers VoiceXML Transfers
7-3 7-4
Intelligent Network (IN) Release Trunk Transfers

7-4
vii
Contents
CHA PTER
Network Level Considerations (The IP Infrastructure) Bandwidth Provisioning and QoS Considerations 8-1 CVP Network Architecture Overview 8-2 Voice Traffic 8-2 Call Control Traffic 8-2 H.323 8-2 GED-125 8-3 MRCP 8-3 ICM Central Controller to CVP VRU PG 8-3 Data Traffic 8-4 Bandwidth Sizing 8-4 VoiceXML Documents 8-4 Media File Retrieval 8-5 H.323 Signaling 8-5 ASR/TTS 8-5 Voice Traffic 8-6 Call Admission Control RSVP 8-6 QoS
8-7 8-7 8-8 8-6
8-1
Blocking initial G.711 Media Burst Network Security using Firewalls

9
CHA PTER
Interacting with ICM
9-1
NetworkVRU Types 9-1 About ICM NetworkVRUs 9-2 CVP as Service Node IVR to ICM (Type 5) 9-2 CVP as Intelligent Peripheral IVR to ICM based on Correlation ID mechanism (Type 3,7) 9-3 CVP as Intelligent Peripheral IVR to ICM based on Translation Route ID mechanism (Type 8,2) NetworkVRU Types and CVP Deployment Models 9-4 Model #1. Standalone Self-Service 9-5 Model #2. CVP with ICM-Controlled Switching 9-5 Model #3a. DTMF Menu, Prompt and Collect 9-5 Model #3b. ASR/TTS and/or complex IVR application 9-6 Model #4. IVR/Queuing via ICM with NIC-controlled routing 9-6 Model #4a. IVR/Queuing via ICM with NIC-controlled routing 9-6 Model #4b. IVR/Queuing via ICM with NIC-controlled pre-routing 9-7 Hosted Implementations 9-7 About Hosted Implementations
9-7
9-4
viii
OL-8408-02
Contents
How CVP Fits Into Hosted Environments 9-8 CVP Placement and Call Routing in a Hosted environment NetworkVRU Type in a Hosted environment 9-10 Using Third Party VRUs
10
9-9
Cisco CallManager and ACD Originated Calls - Deployment Models and Sizing Implications
9-12
9-11
CHA PTER
Cisco CallManager Originated Calls - Deployment Models and Sizing Implications Why these Cisco CallManager Originated Calls Are Different Call Flows (customer) 10-2 ICM Outbound with Transfer to IVR Internal Help Desk 10-2 Warm Consultative Transfer 10-2
10-2 10-1
10-1
Call Flows (protocol) 10-3 Model #1, Standalone Self Service 10-3 Model #2, CVP Call Control 10-3 Model #3a, CVP Call Control with Queue and Collect 10-4 Model #3b, CVP Call Control with Queue and Self Service 10-6 Deployment Implications 10-6 ICM Configuration 10-6 Hosted Implementations 10-6 Cisco CallManager Configuration Network Level 10-7 Sizing 10-7 CVP Call Servers 10-7 Gateways 10-7 MTP Resources 10-8
11
10-7
CHA PTER
Using the GKTMP NIC The ICM GKTMP NIC
11-1 11-1
The Cisco Gatekeeper External Interface

11-1
Typical Applications of GKTMP with CVP 11-2 Protocol Level Call Flow 11-3 Pre-Routing of incoming calls, call context passing not required 11-3 Pre-Routing of incoming calls, call context passing is required 11-4 Routing of post-ICM calls 11-4 Deployment Implications 11-4 Pre-Routing of incoming calls, call context passing not required 11-5 Pre-Routing of incoming calls, call context passing is required 11-5
ix
Contents
Routing of post-ICM calls Other implications 11-6

12
11-5
CHA PTER
Gateway Options PSTN Gateway
12-1 12-1 12-2 12-2
VoiceXML Gateway with DTMF or ASR/TTS TDM Interfaces

13
VoiceXML & PSTN Gateway with DTMF or ASR/TTS

12-2
CHA PTER
Design Implications for VoiceXML Server What is VoiceXML over HTTP? Multilanguage Support
13-2 13-1
13-1
Differences in the Supported Web Application Servers Where to Install CVP Studio
14
13-3
13-2
CHA PTER
Media File Options
14-1 14-1 14-1
Deployment and Ongoing Management Best Practices for Prompt Management Configuring Caching on IOS Branch office implications
15
14-2 14-2
Bandwidth Calculation for Prompt Retrieval

14-2
CHA PTER
Licensing
15-1
CVP Licensing 15-1 Regular Port Licenses 15-1 Regular Server Licenses 15-2 Redundant Licenses 15-2 License Enforcement 15-3 ASR/TTS Licensing 15-3 Gateway Licensing
16
15-4
CHA PTER
Reporting and Monitoring
16-1 16-1
Real Time Health Monitoring of CVP Components Statistical Monitoring of CVP Components End to End Tracking of Individual Calls Formal Reporting Based on ICM Data
16-2 16-3 16-2
Formal Reporting Based on CVP VoiceXML Server Data

16-3
OL-8408-02
Contents
GL O S S A R Y
xi
Contents
xii
OL-8408-02
Preface
Purpose
This document provides design considerations and guidelines for deploying enterprise network solutions that includes the Cisco Customer Voice Portal (CVP). This document builds on ideas and concepts presented in the Cisco IP Contact Center (IPCC) Enterprise Edition Solution Reference Network Design (SRND), which is available online at http://cisco.com/go/srnd
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 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 IPCC SRND. To review those terms and concepts, refer to the documentation at the preceding URL.
Revision History
Unless stated otherwise, the information in this document applies specifically to Cisco CVP Releases 3.1. This document may be updated at any time without notice. You can obtain the latest version of this document online at http://cisco.com/go/srnd 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.
Revision Date November, 2005 March, 2006
Comments Initial release of this document. Updated for Cisco CVP release 3.1(0)
xiii
Preface Document Organization
Document Organization
This document assumes that you are already familiar with basic contact center terms and concepts and with Cisco IP Contact Center (IPCC) solutions. Before using this CVP guide, you should review the design ideas and concepts presented in the latest version of the Cisco IP Contact Center (IPCC) Enterprise Edition Solution Reference Network Design (SRND), which is available online at http://cisco.com/go/srnd This document is divided into three parts:

Part I: General Information, page xiv Part II: Deployment Models and Sizing, page xivg Part III: Reference Material, page xiv
Part I: General Information

Part I discusses the CVP product and solution in general terms, and provides background material about how the product works and how it interacts with callers and other devices. The intent in this section is to cover information which you are likely to need in pre-sales discussions with your customers.
Part II: Deployment Models and Sizing

Part II lays out a set of deployment models which categorize the different ways that customers use the CVP product. Each deployment model is discussed in great detail, covering the following points:

Customer Requirements: what sorts of customers gravitate toward this model? Caller Experience: what do callers experience when they dial in to systems of this model? Characteristics: what features does this model support? What are its salient distinctions from other models? Components: which CVP product and solution components are required in this model, and which components can be added in order to enhance the features it offers? Protocol Level Call Flow: exactly what does the message flow among components look like? Transfers: what kinds of transfers are supported among CVP call legs and agent destinations? Geographic Distribution implications: what factors need to be considered when the model is used in a branch office or distributed deployment, as opposed to one that is centralized?
Armed with this detailed information it should be possible to identify the deployment model which best suits your customers needs. This part then includes instructions on how to determine how many gateways and servers of various types need to be ordered. This section is known as sizing, and is distinct from licensing, which appears in Part III.
Part III: Reference Material

Part III presents a number of detailed topics to generalize and expand on the information presented in Part II. This section is intended to help you design your IP network infrastructure, dial plan, and integration with other Cisco and non-Cisco components in order to support your CVP deployment. It
xiv
OL-8408-02
Preface Conventions
also describes certain less common call flows which do not fit neatly into the named deployment models from Part II, as well as a detailed discussion of how the CVP design supports high availability in the case of component and network link failure.
Conventions
This document uses the following conventions: Convention Italic font Screen font Blue font Description Arguments for which you supply values, book titles, and items selected for emphasis appear in italic font. Expression Language examples and code appear in screen font. Hypertext links to the section referenced in the blue font
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation at this URL: http://www.cisco.com/techsupport You can access the Cisco website at this URL: http://www.cisco.com You can access international Cisco websites at this URL: http://www.cisco.com/public/countries_languages.shtml
Product Documentation DVD

The Product Documentation DVD is a comprehensive library of technical product documentation on a portable medium. The DVD enables you to access multiple versions of installation, configuration, and command guides for Cisco hardware and software products. With the DVD, you have access to the same HTML documentation that is found on the Cisco website without being connected to the Internet. Certain products also have .PDF versions of the documentation available. The Product Documentation DVD is available as a single unit or as a subscription. Registered Cisco.com users (Cisco direct customers) can order a Product Documentation DVD (product number DOC-DOCDVD= or DOC-DOCDVD=SUB) from Cisco Marketplace at this URL: http://www.cisco.com/go/marketplace/
xv
Preface Documentation Feedback
Ordering Documentation
Registered Cisco.com users may order Cisco documentation at the Product Documentation Store in the Cisco Marketplace at this URL: http://www.cisco.com/go/marketplace/ Nonregistered Cisco.com users can order technical documentation from 8:00 a.m. to 5:00 p.m. (0800 to 1700) PDT by calling 1 866 463-3487 in the United States and Canada, or elsewhere by calling 011 408 519-5055. You can also order documentation by e-mail at tech-doc-store-mkpl@external.cisco.com or by fax at 1 408 519-5001 in the United States and Canada, or elsewhere at 011 408 519-5001.
Documentation Feedback
You can rate and provide feedback about Cisco technical documents by completing the online feedback form that appears with the technical documents on Cisco.com. You can submit comments about Cisco documentation by using the response card (if present) behind the front cover of your document or by writing to the following address: Cisco Systems Attn: Customer Document Ordering 170 West Tasman Drive San Jose, CA 95134-9883 We appreciate your comments.
Cisco Product Security Overview

Cisco provides a free online Security Vulnerability Policy portal at this URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html From this site, you will find information about how to:

Report security vulnerabilities in Cisco products. Obtain assistance with security incidents that involve Cisco products. Register to receive security information from Cisco.
A current list of security advisories, security notices, and security responses for Cisco products is available at this URL: http://www.cisco.com/go/psirt To see security advisories, security notices, and security responses as they are updated in real time, you can subscribe to the Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed. Information about how to subscribe to the PSIRT RSS feed is found at this URL: http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
xvi
OL-8408-02
Preface Obtaining Technical Assistance
Reporting Security Problems in Cisco Products

Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you have identified a vulnerability in a Cisco product, contact PSIRT:
For Emergencies only security-alert@cisco.com An emergency is either a condition in which a system is under active attack or a condition for which a severe and urgent security vulnerability should be reported. All other conditions are considered nonemergencies.
For Nonemergencies psirt@cisco.com
In an emergency, you can also reach PSIRT by telephone:

1 877 228-7302 1 408 525-6532
Tip
We encourage you to use Pretty Good Privacy (PGP) or a compatible product (for example, GnuPG) to encrypt any sensitive information that you send to Cisco. PSIRT can work with information that has been encrypted with PGP versions 2.x through 9.x. Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one linked in the Contact Summary section of the Security Vulnerability Policy page at this URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html The link on this page has the current PGP key ID in use. If you do not have or use PGP, contact PSIRT at the aforementioned e-mail addresses or phone numbers before sending any sensitive material to find other means of encrypting the data.
Obtaining Technical Assistance

Cisco Technical Support provides 24-hour-a-day award-winning technical assistance. The Cisco Technical Support & Documentation website on Cisco.com features extensive online support resources. In addition, if you have a valid Cisco service contract, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not have a valid Cisco service contract, contact your reseller.
Cisco Technical Support & Documentation Website

The Cisco Technical Support & Documentation website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, at this URL: http://www.cisco.com/techsupport
xvii
Preface Obtaining Technical Assistance
Access to all tools on the Cisco Technical Support & Documentation website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL: http://tools.cisco.com/RPF/register/register.do
Note
Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support & Documentation website by clicking the Tools & Resources link under Documentation & Tools. Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.
Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco engineer. The TAC Service Request Tool is located at this URL: http://www.cisco.com/techsupport/servicerequest For S1 or S2 service requests, or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly. To open a service request by telephone, use one of the following numbers: Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227) EMEA: +32 2 704 55 55 USA: 1 800 553-2447 For a complete list of Cisco TAC contacts, go to this URL: http://www.cisco.com/techsupport/contacts
Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity definitions. Severity 1 (S1)An existing network is down, or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation. Severity 2 (S2)Operation of an existing network is severely degraded, or significant aspects of your business operations are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
xviii
OL-8408-02
Preface Obtaining Additional Publications and Information
Severity 3 (S3)Operational performance of the network is impaired, while most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels. Severity 4 (S4)You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
The Cisco Product Quick Reference Guide is a handy, compact reference tool that includes brief product overviews, key features, sample part numbers, and abbreviated technical specifications for many Cisco products that are sold through channel partners. It is updated twice a year and includes the latest Cisco offerings. To order and find out more about the Cisco Product Quick Reference Guide, go to this URL: http://www.cisco.com/go/guide
Cisco Marketplace provides a variety of Cisco books, reference guides, documentation, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL: http://www.cisco.com/go/marketplace/
Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL: http://www.ciscopress.com
Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL: http://www.cisco.com/packet
iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL: http://www.cisco.com/go/iqmagazine or view the digital edition at this URL: http://ciscoiq.texterity.com/ciscoiq/sample/
Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL: http://www.cisco.com/ipj
xix
Preface Obtaining Additional Publications and Information
Networking products offered by Cisco Systems, as well as customer support services, can be obtained at this URL: http://www.cisco.com/en/US/products/index.html
Networking Professionals Connection is an interactive website for networking professionals to share questions, suggestions, and information about networking products and technologies with Cisco experts and other networking professionals. Join a discussion at this URL: http://www.cisco.com/discuss/networking
World-class networking training is available from Cisco. You can view current offerings at this URL: http://www.cisco.com/en/US/learning/index.html
xx
OL-8408-02
A R T
High Level Architecture
C H A P T E R
Introduction
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 customers integration options with automatic speech recognition (ASR) and text-to-speech (TTS) solutions. Over the past few years there has been a dramatic shift in using VoiceXML technology to support the next generation of IVR applications. The major goal of VoiceXML is to provide a standards-based way of incorporating the advantages of web-based development and content delivery into voice-enabled business applications such as ASR and TTS.
What is the Cisco Customer Voice Portal?

The Cisco Customer Voice Portal (CVP) is a web-based platform that provides carrier-class interactive voice response (IVR) and IP switching services on Voice over IP (VoIP) networks. The CVP feature set includes:

IP-based call switching: CVP can transfer calls over an IP network while maintaining call control for call treatment or subsequent transfers over the IP network. IP-based takeback and transfer (TNT): CVP can take back a transferred call for further IVR treatment or transfer it back to the PSTN. IP-based IVR services: CVP can perform the classic prompt-and-collect functions such as, "Press 1 for sales, 2 for service," and so forth. IP-based queuing: Calls can be "parked" on CVP for prompting, music on hold, and so forth, while waiting for a call center agent to become available. Compatibility with other Cisco call routing and VoIP products: Specifically, Hosted IPCC or Intelligent Contact Manager (ICM), Cisco Gatekeeper, Cisco gateways, and Cisco IP Contact Center (IPCC). Compatibility with the public switched telephone network (PSTN): Calls can be moved onto an IP-based network for CVP treatment and then moved back out to a PSTN for further call routing to a call center. Carrier-class platform: CVP's reliability, redundancy, and scalability enable it to work with service-provider and large enterprise networks. IP-based voice-enabled IVR services: CVP provides for sophisticated self-service applications (including speech-enabled applications), such as banking, brokerage, and airline reservations.
1-1
Chapter 1 What is VoiceXML?
Introduction
The CVP platform (VoiceXML server component) serves up scripted VoiceXML pages to the Cisco IOS voice browser. These pages are invoked using CVP's External VoiceXML feature in the Cisco Intelligent Contact Management (ICM) software or in CVP VoiceXML Standalone deployments, directly upon request from the gateway. CVP VoiceXML is supported on most of the gateways listed in this document (see Chapter 12, Gateway Options), but the performance specifications differ from one gateway to another.
What is VoiceXML?
Voice eXtensible Markup Language, or VoiceXML, is a language similar to HTML that brings the full power of web development and content delivery to interactive voice response (IVR) applications. VoiceXML is 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.
1-2
OL-8408-02
C H A P T E R
CVP Components
This chapter describes the major components of the Cisco Customer Voice Portal:

Typical CVP Deployment, page 2-1 CVP Solution Components, page 2-2

Figure 2-1 illustrates the various components in a typical full-featured CVP deployment. It does not show redundant components.
2-1
Chapter 2 CVP Solution Components
CVP Components
Figure 2-1
Call Center IP IP
Data Center
SCCP
CallManager
M
H323 RAS Gatekeeper

V
H323 CVP Call Control JTAPI
INGRESS Gateway
VXML CVP VXML servers VXML GED-125
V HTTP CSS
VXML
CVP VB
VXML Gateway with IOS VB
ICM Enterprise Edition
TDM ACD
HTTP
CVP AS Media servers
MRCP ASR/TTS
CVP Solution Components

The Cisco Customer Voice Portal (CVP) consists of the following components:

CVP Call Server, page 2-3 Cisco Ingress and VXML Gateway, page 2-3 Cisco Gatekeeper, page 2-4 CVP VoiceXML Server, page 2-4 CVP VoiceXML Studio, page 2-5 Standalone Distributed Diagnostics and Services Network (SDDSN), page 2-5 Cisco Content Services Switch (CSS), page 2-5 Cisco PSTN Gateway (PGW) Softswitch, page 2-5 Third Party Media Server, page 2-6 Third Party Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server, page 2-6 IPCC Enterprise and Intelligent Contact Management (ICM), page 2-7
2-2
143479
SDDSN Alarms/Events from VBs and App
OL-8408-02
Chapter 2
CVP Components CVP Solution Components
Cisco CallManager, page 2-7
Depending on the particular deployment model in use, some of the above components might not be required. Once deployed, CVP provides an integrated self-service, queuing, and switching solution. The following sections discuss each of these components in more detail. For the most current information on a particular product, refer to the specific product documentation available online at: http://www.cisco.com/
Note
This design guide focuses mainly on CVP components and deployments. For the most current, in-depth technical information on the other products listed above, refer to the latest versions of the additional design guides available at http://www.cisco.com/go/srnd. The following sections present an overview of each of these components, and give a general discussion about how each component interacts with the rest of the system.
CVP Call Server

The CVP Call Server is the central component in an ICM-integrated CVP implementation. It is located logically between the gateway and ICMs VRU PG. It is made up of two parts: the CVP Voice Browser and the CVP App Server. The name CVP Voice Browser is historical. As of CVP 3.x and ICM 7.0(0), it is no longer used as a voice browser. Its main purpose is to manage the H.323 signaling between the ingress/egress gateways, VXML gateways, gatekeepers, and CallManager. The CVP App Server is the interface between CVP and ICM. It manages the GED-125 interface with ICM on one side, and on the other side it exchanges VoiceXML instructions with the CVP Voice Browser for call control purposes, and with the VXML gateway for caller treatment purposes. It is also responsible for interpreting the Microapp requests from ICM and converting them into VoiceXML pages which the VXML gateways voice browser can execute. In earlier releases of CVP, it was not unusual to physically place the two CVP Call Server processes on different machines. However over time it was learned that there is no real advantage to doing so, and that it created unnecessary troubleshooting difficulties. The best practice now is to always place both processes in the same machine. Throughout this document we do not distinguish between the two processes which run on a CVP Call Server, since it is rarely significant to the discussion. The only exception is when we discuss High Availability Design, where it is important to understand how messages flow between these processes individually.
Cisco Ingress and VXML Gateway

Calls arrive at the gateway or router from one of two sources: the PSTN or the IP network. The gateway is responsible for performing the following functions:

Converting TDM voice signals to Voice over IP (VoIP), if necessary Connecting and reconnecting calls to VoIP terminating destinations Executing voice treatment and switching instructions in the form of VoiceXML documents
The gateway interacts with the CVP Call Server in two ways. In deployment models which integrate with ICM (see Chapter 3, Deployment Models), the gateway exchanges H.323 call control instructions with the CVP Call Server. When it is performing these call control activities, it is known as an ingress
2-3
CVP Components
gateway. In all deployment models, the gateway might also be executing VoiceXML operations via its built-in IOS Voice Browser software. A gateway which performs VoiceXML operations is known as a VXML gateway. As an ingress gateway, the arrival of a new call causes an H.323 call setup operation to occur between the gateway and the CVP Call Server. As a VXML gateway, the arrival of a new call invokes a flash-resident VoiceXML application and begins making requests to either the CVP VoiceXML Server or the CVP Call Server for VoiceXML pages to execute, depending on the deployment model in use. Supported gateways include the Cisco 2800 Series, 3700 Series, 3800 Series, 5350XM, 5400 HPX, and the 5400 XM. The AS5850 ERSC and the Cisco Catalyst 6500 Communication Media Module (CMM) is also supported as an ingress/egress gateway only. For the most current list of supported gateways, refer to the latest version of the CVP 3.0 Bill of Materials (BOM), available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
Cisco Gatekeeper
The gatekeeper is a network element used by the gateway for call transfers. It is an optional component in certain deployments; however, in practice most installations incorporate a gatekeeper for dial plan configuration and bandwidth management. When the gateway receives instructions from the CVP Call Server to transfer a call, it first matches the destination number with its dial peers. If the matched dial peer specifies gatekeeper lookup (that is, session-target ras), the gateway will query the gatekeeper with the transfer destination label. The gatekeeper, in turn, replies with an IP address to which the gateway will transfer the call. As of CVP 3.1 SR1, two gatekeeper failover mechanisms are supported: Hot Standby Router Protocol (HSRP), and Alternate Gatekeepers. For more information on H.323 gatekeepers, refer to the Cisco gatekeeper product documentation available online at Cisco.com.
CVP VoiceXML Server

The CVP VoiceXML Server delivers external VoiceXML documents to the gateway. Customers write voice applications using the CVP Studio, described below, and deploy them to the CVP VoiceXML Server. As calls invoke external VoiceXML, the CVP VoiceXML Server builds VoiceXML pages dynamically according to the contents of the deployed application. The CVP VoiceXML Server interacts only with the gateway, but the gateway requests the VoiceXML document from the CVP VoiceXML Server upon command from the CVP Call Server. In a CVP Standalone Self Service model configuration, in which the gateway and CVP VoiceXML Server are deployed (without requiring CVP Call Server for IP switching and/or IPCC), the gateway requests VoiceXML from the CVP VoiceXML Server as soon as it receives an appropriately designated new call. Multiple CVP VoiceXML Servers might be used in a given deployment for scalability. In such cases, configure them all identically, and use a Cisco Content Services Switch (CSS) to balance the load across them.
2-4
OL-8408-02
Chapter 2
CVP VoiceXML Studio

The CVP VoiceXML Studio is an Integrated Development Editor that is based on the open-source Eclipse framework. It provides a graphical user interface for designing complex IVR scripts, as well as a palate containing a rich set of standard scripting elements. The palate can be expanded to include reusable custom elements which the customer or partner can write, or which might be obtained off-the-shelf from third party vendors. Such extensions are often used to provide direct integration with back-end systems in the corporate infrastructure. CVP VoiceXML Studio is a software product that can run on any Windows XP or 2000 machine. However, since the license is associated with the IP address of the machine it is running on, customers typically designate one or more data center servers for that purpose.
Standalone Distributed Diagnostics and Services Network (SDDSN)

The Standalone Distributed Diagnostics and Services Network (SDDSN) is a component that provides alarm reporting for CVP through the following mechanisms:

SNMP traps CiscoWorks2000 Syslog, which receives log messages and permits queries on the logs Microsoft Windows Remote Access Service (RAS) and Hosted IPCC or Intelligent Contact Management (ICM) Event Management System (Cisco Remote Monitoring Suite), traditionally named Cisco Phone Home
SDDSN must reside on a separate server from any CVP or ICM component. For the most current information on the hardware requirements for the SDDSN, refer to the latest version of the CVP 3.1 Bill of Materials (BOM), available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
Cisco Content Services Switch (CSS)

An optional Content Services Switch (CSS) provides a high-end failover solution. For example, you can use a pair of Cisco 11503 Content Services Switches to provide high availability and load balancing. The gateway requests VoiceXML documents, prerecorded prompts, grammar files, and ASR/TTS treatment from back-end servers. In the CVP failover solution with the CSS, the gateway is the client while CVP application servers, CVP VoiceXML servers, ASR/TTS servers, and HTTP media servers are the back-end servers, all of which are configured as services in the CSS. While CSS is an optional component, it is important to understand the tradeoffs involved in deciding whether or not to use it. This is discussed in the section on CVP High Availability Design (see Chapter 5, Designing CVP for High Availability)
Cisco PSTN Gateway (PGW) Softswitch

The Cisco PGW Softswitch is a flexible multiprotocol Media Gateway Controller (MGC) that provides a bridge between the legacy public switched telephone network (PSTN) and IP networks. It supports either a simple Signaling System 7 (SS7) interconnection or intelligent call control and routing functions.
2-5
CVP Components
The Cisco PGW Softswitch provides a consistent, unified interconnection that can handle dial-up services, MGCP, Session Initiation Protocol (SIP), and H.323, as well as future standards. The PGW enables service providers to deploy and operate multiple network solutions while maintaining a stable connection to the PSTN.
Third Party Media Server

The media server is an optional network component which can provide prerecorded audio files, external VoiceXML documents, or external ASR grammars to the gateway. Because some of these files can be stored in local flash memory on the gateways, the media server can be an optional component. However, in practice, most installations use a centralized media server to simplify distribution of prerecorded customer prompt updates. Media server functionality can also include a caching engine. The gateways themselves, however, can also do prompt caching when configured for caching. Typical media servers used are Microsoft IIS and Apache, both of which are HTTP-based. For the most current information on media servers, refer to the latest version of the CVP 3.1 Bill of Materials (BOM), available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
Third Party Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server
Prompts to the caller can utilize prerecorded voice prompts or can be generated with TTS via a voice synthesizing engine (the TTS server). In response to the prompt, the caller can be asked to enter DTMF input or voice input. When the caller provides voice input, the speech recognition engine tries to match that input to a set of acceptable responses. VoiceXML and the World Wide Web Consortium (W3C) provide a rich feature set to support the ASR grammars. The simplest to implement and support is inline grammars, by which the set of acceptable customer responses is passed to the gateway. Another form is external grammars, by which the ICM passes a pointer to an external grammar source. The CVP VoiceXML Server adds this pointer to the VoiceXML document that it sends to the gateway, which then loads the grammar and uses it to check ASR input from the caller. In this case, the customer is responsible for creating the grammar file. A third type of grammar is the built-in grammar. For a complete explanation of grammar formats, consult the W3C website at http://www.w3.org/TR/speech-grammar/ The text for TTS is passed directly from the CVP VoiceXML Server to the gateway. This action is referred to as inline TTS in this document. The actual speech recognition and speech synthesis are performed by a separate server that interfaces directly to the VXML gateway via the Media Resource Control Protocol (MRCP). Currently, ScanSoft, Nuance, and IBM are the supported ASR/TTS engines. These ASR/TTS engines also support (with limitations) voice recognition and synthesis for multiple languages. For the latest information on supported languages and limitations of these ASR/TTS engines, refer to the following websites:
Nuance http://www.nuance.com
Scansoft http://www.nuance.com
2-6
OL-8408-02
Chapter 2
IBM http://www-306.ibm.com/software/voice/
Note that these are third party products, which the customer or partner must purchase directly with the vendor. The customer also receives technical support directly from the vendor. That does not, however, mean that the vendors latest software version can be used. CVP is carefully tested with specific versions of each vendors product, and Cisco TAC will not support CVP customers who use different ASR/TTS versions than those which have been tested with Cisco CVP. It is important to check the CVP 3.1 Bill of Materials (BOM), available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
IPCC Enterprise and Intelligent Contact Management (ICM)

IPCC Enterprise or Intelligent Contact Management (ICM) is a required component when advanced call control (IP switching, transfers to agents, and so forth) is required in CVP. The Hosted versions of these products might also be used for this purpose. ICM provides call-center agent management capabilities and call scripting capabilities. Variable storage capability and database access through the IPCC or ICM application gateways are also powerful tools. A CVP application can take advantage of these capabilities because CVP applications can be called from within a IPCC or ICM script in a non-standalone CVP deployment model. The CVP Call Server maintains a GED-125 Service Control Interface connection to the IPCC or ICM. GED-125 is a "third-party control" protocol in which a single socket connection is used to control many telephone calls. From the IPCC or ICM's point of view, the CVP Call Server is a voice response unit (VRU) connected to the IPCC or ICM, just as all other GED-125 VRUs are connected. CVP is simply a VRU peripheral to the IPCC or ICM.
Cisco CallManager
Cisco CallManager is an optional component in the CVP solution. Its use in the solution depends on the type of call center being deployed. Pure TDM-based call centers using ACDs, for example, typically do not use Cisco CallManager (except when migrating to IPCC), nor do strictly self-service applications using the CVP Standalone Self Service deployment model. Cisco CallManager generally is used as part of the Cisco IPCC solution, in which call center agents are part of an IP solution using Cisco IP phones, or when migrating from TDM ACDs. Only specific versions of Cisco CallManager are compatible with CVP solutions. It is important to check the CVP 3.1 Bill of Materials (BOM), available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
2-7
CVP Components
2-8
OL-8408-02
A R T
Deployment Models and Sizing
C H A P T E R
Deployment Models
This chapter covers following five substantially different deployment models for CVP customers:

Model #1, Standalone Self Service, page 3-1 Model #2, CVP Call Control, page 3-5 Model #3a, CVP Call Control with Queue and Collect, page 3-9 Model #3b, CVP Call Control with Queue and Self Service, page 3-14 Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service, page 3-17
Each model begins by listing the types of customer requirements and the expected caller experience which would lead a customer to that particular model. Salient characteristics of the model are presented, mentioning at a high level what makes each model different from the others, and any important constraints or caveats that the reader needs to know about. Next, we list the CVP product and solution components which might or must be present in that model. These descriptive sections are followed by a detailed specification of the protocol level message flow between components, and a list of the types of transfers which are supported (refer to Chapter 7, Call Transfer Optionsfor detailed information about these types of transfers). Each model ends finally with a section describing how it can or must be adapted if it is deployed in a geographically distributed fashion (A.K.A. branch office deployment). All of these models can be deployed with CVP's standard set of high availability features. However, we have chosen not to discuss the design or effects of high availability here, in order to keep the discussion focused. That topic is covered in Chapter 5, Designing CVP for High Availability.
Model #1, Standalone Self Service

This section covers the following topics:

Customer Requirements, page 3-2 Caller Experience, page 3-2 Characteristics, page 3-2 Components, page 3-2 Protocol Level Call Flow, page 3-2 Transfers, page 3-4 Geographic Distribution Alternatives, page 3-4
3-1
Chapter 3 Model #1, Standalone Self Service
Deployment Models
Customer Requirements
The customer wants a standalone IVR for automated self service and call handling.
Caller Experience
The caller dials either a local phone number or a centralized phone number, communicates with an IVR, and then optionally transfers to a destination.
Characteristics
This deployment model provides IVR services only. Intelligent contact center integration is not included, though it is possible to transfer the call to an arbitrary destination, without call context, and without queuing. This model requires VoiceXML Servers and gateways, but does not include the CVP Call Server or any ICM components. IVR applications support either DTMF- only or ASR and TTS.
Components
Required components:

Ingress/VXML Gateways VoiceXML Servers VoiceXML Studio
Optional components:

ASR and TTS Servers Media Servers Content Services Switches
Protocol Level Call Flow

The steps involved in handling a call in a CVP standalone IVR deployment are describe below. Typically, the inbound call activates an IVR application that plays pre-recorded prompts and TTS with caller input via DTMF and/or speech recognition. The call might simply comprise IVR dialogue or might additionally involve one or more subsequent transfers. The flow described here assumes the use a Content Services Switch (CSS) for failover and load balancing purposes. Note that the CSS is optional; please see Chapter 5, Designing CVP for High Availability to better understand the benefits of deploying a CSS.
1. 2. 3. 4.
Call arrives to ingress gateway via TDM/SIP/H.323. Gateway performs normal inbound pots/voip dial-peer matching. Selected dial-peer invokes CVP self-service TCL script. TCL script invokes CVP standalone bootstrap VoiceXML Document which performs an HTTP request to the configured CSS VIP address for the primary VXML server. CSS selects an available VXML server to process the call. CSS also creates a cookie to ensure that subsequent HTTP requests for the call are directed to the same VXML server.
3-2
OL-8408-02
Chapter 3
Deployment Models Model #1, Standalone Self Service
5. 6. 7. 8.
VXML server runs the application specified in the HTTP URL. VXML server returns a dynamically generated VXML doc to the gateway via the CSS. Gateway parses and renders VXML doc. For spoken output, the gateway either retrieves and plays back pre-recorded audio files referenced in the VXML documentation, or streams media from a TTS server via an MRCP session:
a.
Pre-recorded Audio
Gateway looks in local cache for the requested audio file. If the audio file exists in cache
and has not expired, gateway renders from cache. Alternatively, if the file cannot be retrieved from cache or has expired, gateway makes an HTTP request to the destination defined by the URL of the audio source in the VXML doc. Note that mechanisms other than HTTP might be used, such as tftp, rtsp, flash, etc. For more information, reference Cisco IOS TCL IVR and VoiceXML Application Guide http://www.cisco.com/application/pdf/en/us/guest/products/ps6242/c1696/ccmigration_09 186a008045e24d.pdf
The CSS is configured to select an available media server for the specified URL. Once
selected, the CSS sends an HTTP redirect back to the gateway with the IP address of media server. The gateway then retrieves the media directly.
b. TTS Gateway establishes an MRCP session to the TTS server configured on the gateway, using
the CSS to determine the actual physical server. Note that the TTS server address can be overridden by populating the VXML property com.cisco.tts-server.
TTS server sends RTP packets back to the Gateway directly, bypassing the CSS. Gateway
plays TTS to the caller.

9.
Caller input can be captured either by DTMF detection on the gateway or via DTMF/utterance recognition on the ASR server. When an ASR server is used, the gateway establishes an MRCP connection to the ASR server configured on the gateway using the CSS to determine the actual physical server. Note that the ASR server address can be overridden by populating the VXML property com.cisco.asr-server. The caller's speech is streamed over RTP directly from the gateway to the ASR server. the caller input to the VXML server via the CSS. Using the cookie saved earlier, the original VXML server will be (and must be) selected to handle the request because it has retained context for the call.
10. As defined in the VoiceXML document, gateway submits an HTTP request containing the results of
11. The IVR dialogue continues with repeated iterations from Step 6. on page 3- 3 to Step 10. on page 3-
3.
12. The application on the VXML server might access back-end systems for personalized data to
incorporate into the VoiceXML documents that it sends back to the gateway.
13. As part of the self-service application, transferring the caller to another destination might be
necessary.
14. In the case of a VXML Bridged Transfer the outcome of the transferred call leg is submitted back
to the VXML server when the transfer completes either normally or because of an error. The VXML session is resumed and further iterations of IVR call treatment and transfers can be performed.
3-3
Chapter 3 Model #1, Standalone Self Service
Deployment Models
Transfers
The following types of transfer are supported in this model.

VXML 2.0 Bridged Transfer VXML 2.0 Blind Transfer Release Trunk Transfer (Hook Flash and TBCT)
The VoiceXML transfers are invoked using the VoiceXML Studios transfer element. Release Trunk Transfers are invoked by providing specially formatted return values in VoiceXML Studios subdialog_return element.
Geographic Distribution Alternatives

Collocated VoiceXML Servers and Gateways
All gateways and servers either are centralized or are all replicated at branch offices with no centralized control. If ASR servers are used, they must be collocated with the gateway. Pros of collocation:

WAN outage does not impact self service application ASR is permitted with centralized ASR servers
Cons of collocation:

No centralized administration or reporting Extra VoiceXML Servers required when using replicated branch offices Deployment of applications to multiple VoiceXML servers
Gateways at the Branch, Centralized VoiceXML Servers (non-collocated)

Pros of non-collocation:

Centralized administration and reporting Local phone numbers VoiceXML Server capacity can be shared among branch offices
Cons of non-collocation:

Limited branch survivability ASR requires a local ASR server at each branch WAN bandwidth must be sized for additional VoiceXML over HTTP traffic
3-4
OL-8408-02
Chapter 3
Deployment Models Model #2, CVP Call Control
Model #2, CVP Call Control


Customer Requirements, page 3-5 Caller Experience, page 3-5 Characteristics, page 3-5 Components, page 3-6 Protocol Level Call Flow, page 3-6 Transfers, page 3-7 Distributed: Ingress and/or Egress Gateway at the branch, page 3-8
This model has the following customer requirements:

TDM migration to IP: Customer has a TDM ACD network, and wants to exploit the benefits and flexibility of routing calls over an IP network among those existing ACDs without tromboning. Customer wants to use the IP infrastructure to save costs, such as Takeback and Transfer charges, tie line charges, and PSTN network dip charges. Customer wants the advantages of pre-routing within an enterprise infrastructure without resorting to a service provider. Customer wants a cradle to grave view of all calls in the contact center.
Caller Experience
The caller dials either a local or a centralized phone number and is intelligently routed to a businessappropriate service. The caller might be subsequently transferred to one or more other services, with call context preserved.
Characteristics
This deployment model is a call-switching-only solution and does not insert any IVR capability into the network. This model requires ICM in order to provide the intelligent call routing, but does not provide for any queuing other than what is already provided by the existing ACDs. Calls can be transferred among agents and other devices without loss of call context information and without tromboning through those devices. In addition, this model facilitates migration of existing TDM peripherals to IP, since a Child IPCC Enterprise can take the place of any traditional ACD.
Note
The Child IPCC deployment was added in the ICM 7.0(0) release. For more information on this deployment, refer to the Cisco IPCC Gateway Deployment Guide at: http://www.cisco.com/en/US/products/sw/custcosw/ps1001/tsd_products_support_series_home.html
3-5
Chapter 3 Model #2, CVP Call Control
Deployment Models
Components

Ingress and egress gateways Gatekeepers CVP Call Servers ICM

Note
This call flow refers to a target as the destination of the transferred call leg. This target could be an IPCC Enterprise agent, an ACD with its own queuing capabilities, or anything else that can take a callers call.
Ingress Gateway New Call Flow

1. 2. 3. 4. 5.
Call arrives to ingress gateway via TDM/SIP/H.323. Gateway performs normal inbound pots/voip dial-peer matching Ingress gateway makes an H.323 RAS request to the gatekeeper to find the IP address of an appropriate CVP Call Server for that dialed number. Gateway sends an H.225 call setup to the CVP Call Server. For a brief period of time, a G.711 bearer stream exists between the ingress gateway and the CVP Call Server. CVP Call Server sends a New Call message to ICM via the VRU PG. ICM starts a routing script based on dialed number and other criteria.
ICM Transfers a Call to a Target

1. 2.
ICM routing script selects a target. ICM sends the targets label to the CVP Call Server. The label might or might not be prefixed with "DTMF", "TBCT", or "HF".
a. If the label contains no prefix, then the transfer is conducted through H.323 signaling. The CVP
Call Server consults the gatekeeper to translate the label to the IP address of an appropriate Cisco CallManager or other H.323 endpoint. The CVP Call Server then sends an H.225 call setup to the selected endpoint, and makes an Empty Capability Set (ECS) request to the ingress gateway to redirect. Through the media stream is redirected, the H.225 signaling path continues to pass through the CVP Call Server.
b. In the case of DTMF (used for TNT), the CVP Call Server sends an H.323 message to the
ingress gateway requesting that it outpulse the remainder of the label (which usually begins with "*8") to the carrier. The carrier pulls the call away from the ingress gateway and delivers it to the specified destination. Both the signaling and media connections to the CVP Call Server are terminated.
3-6
OL-8408-02
Chapter 3
Deployment Models Model #2, CVP Call Control
c. In the case of hook flash the CVP Call Server sends an H.323 message to the ingress gateway
requesting that it generates a hook flash, and then outpulses the remainder of the label to the carrier, PBX, or other TDM peer to which the gateway is connected. The call is disconnected from the ingress gateway, pulled back into the connected TDM network and delivered to the specified destination.
d. In the case of TBCT, the CVP Call Server instructs the Survivability.tcl script running on the
ingress gateway to issue a 2-B Channel Transfer to the specified target. The carrier pulls the call away from the ingress gateway and delivers it to the specified destination.
3.
If the H.323 target returns a busy or connect failure status, or if the target rings for a period of time which exceeds the CVP Call Servers RNATimeout setting, the CVP Call Server cancels the transfer request and sends a transfer failure indication to ICM. This causes a Router Requery operation; the ICM routing script recovers control and has the opportunity to select a different target or take other remedial action. (Note: Router Requery is only available for transfers which use H.323 signaling; see ICM Managed Transfers, page 7-3.) The call arrives at the H.323 endpoint. Caller speaks to the agent. We assume now that the agent needs to blind-transfer the call to a second agent.
4. 5.
ICM Transfers a Call to a Second Target Via Blind Network Transfer

1. 2. 3. 4.
ACD issues a Route Request to ICM. ICM starts a new routing script which contains a Select node, Label node, or other non-queuing node that results in the immediate selection of a label. ICM sends an agent label to the CVP Call Server. The CVP Call Server disconnects the transferred call leg from the current H.323 endpoint and connects the call to the new endpoint in exactly the same way as described earlier when the call was transferred to the first endpoint. Caller speaks to the second agent. We assume now that the caller is satisfied and hangs up. Ingress gateway sends an H.225 release to the CVP Call Server. CVP Call Server sends an H.225 release to the Cisco CallManager to disconnect the agent. CVP Call Server sends a Disconnect message to ICM.
5. 6. 7. 8.
Transfers
The following types of transfers are supported:

akeback-N-Transfer (TNT) Hook flash and Wink wo B Channel Transfer (TBCT) ICM Managed Transfers
Since this model does not include any Cisco-provided VRU, the transfer target will often be another VRU rather than an ACD or agent. However, this is not relevant to the protocol level call flow shown above, since in any case the VRU is simply another endpoint.
3-7
Chapter 3 Model #2, CVP Call Control
Deployment Models
Distributed: Ingress and/or Egress Gateway at the branch

In this deployment model, branch-located ingress gateways are typically used to allow callers access using local phone numbers rather than centralized or non-geographic numbers, this being especially important in international deployments spanning multiple countries. Egress gateways are located at branches either for localized PSTN breakout or for integration of decentralized TDM platforms into the CVP switching solution. Apart from the gateways all other CVP components are centrally located and WAN links provide data connectivity from each branch location to the central data center.
Network Traffic
Two kinds of traffic flows over the WAN: signaling and media. The signaling is H.323 between the ingress/egress gateways and the centralized gatekeepers and CVP Call Servers, and possibly SCCP between the Cisco CallManager phones and the centralized Cisco CallManagers. The media comprises RTP traffic between:

The ingress gateways and the centralized CVP Call Servers (briefly at the start of each new call only) The ingress gateways and centralized or remote IP phones The ingress gateways and egress gateways located in different sites.
If the customer requirements permit, dial plans and routing priorities can be configured such that callers who ingress at one branch are connected by preference to agents who are located at the same branch. In these cases, the RTP traffic flows directly from ingress gateway to IP phone, and does not need to traverse the WAN. (Signaling and data may traverse the WAN.) WAN links are typically provisioned with a minimal amount of bandwidth. In order to conserve that bandwidth, use G.729 encoding for any RTP traffic which traverses the WAN s. (However, the initial brief setup to the CVP Call Server must use G.711, because the CVP Call Server only supports that codec.)
Survivability
Branch reliability becomes somewhat more of an issue than centralized reliability because WANs are typically less reliable than LAN links. Therefore, provide mechanisms which are local to the branch to gracefully handle calls which are impacted by loss of a WAN link to the central site. This topic is discussed in detail in Chapter 6, Call Survivability in Distributed Deployments.
3-8
OL-8408-02
Chapter 3
Deployment Models Model #3a, CVP Call Control with Queue and Collect
Model #3a, CVP Call Control with Queue and Collect


Customer Requirements, page 3-9 Caller Experience, page 3-9 Characteristics, page 3-9 Components, page 3-10 Protocol Level Call Flow, page 3-10 Transfers, page 3-13 Distributed: Ingress/VXML Gateway at branch, page 3-13
Customer requirements include everything in Model #2:

TDM migration to IP: Customer has a TDM ACD network, and wants to exploit the benefits and flexibility of routing calls over an IP network among those existing ACDs without tromboning. Customer wants to use the IP infrastructure to save costs, such as Takeback and Transfer charges, tie line charges, and PSTN network dip charges. Customer wants the advantages of pre-routing within an enterprise infrastructure without resorting to a service provider. Customer wants a cradle to grave view of all calls in the contact center.
as well as:
The ability to bring network level prompting and queuing into the enterprise.
This deployment also allows the customer to leverage ICM scripting knowledge to write simple IVR applications integrated with the routing script logic.
Caller Experience
The caller dials a local or centralized phone number. The caller receives a welcome prompt, an initial menu, and perhaps a simple data entry dialogue to collect an account number. Based on the callers input, the call might be queued for a contact center agent, receiving music or announcements while on hold. Eventually the caller is connected to an available agent, after which the caller might be returned to queue and/or transferred to a different target, such as voice mail, another agent, or IVR menu. All call context information is maintained for the life of the call.
Characteristics
All scripting is done using the ICM Script Editor, with ICM Network VRU Scripts forming the building blocks of the IVR application. Each script invokes the appropriate CVP Micro-application for the required operation. Most implementations use DTMF data entry and recorded. wav files rather than ASR and TTS.
3-9
Chapter 3 Model #3a, CVP Call Control with Queue and Collect
Deployment Models
Transfers to agents can involve queuing, and subsequent transfers might involve further IVR dialog as well. Agent to agent calls can be blind-transferred without tromboning, but warm transfers might require tromboning through the ACD. Call context is maintained throughout the call.
Components

Ingress gateways VXML gateways Gatekeepers CVP Call Servers ICM, or IPCC Enterprise or Hosted

Dedicated media servers Content Services Switches
Rarely used:
ASR/TTS services

Ingress Gateway new Call Flow
1. 2.
Call arrives to ingress gateway via TDM/SIP/H.323. Gateway performs normal inbound pots/voip dial-peer matching Ingress gateway optionally makes an H.323 RAS request to the gatekeeper (static dial-peer targets might be configured instead) to find the IP address of an appropriate CVP Call Server for that dialed number. Gateway sends an H.225 call setup to the CVP Call Server, and the CVP Call Server immediately responds with an H.225 connect. At this point the gateway answers the incoming call leg. For 100ms or so, a G.711 RTP stream exists between the ingress gateway and the CVP Call Server. This short term media burst sends only a few RTP packets to the CVP Call Server from the gateway before it is torn down as the call is transferred to the VXML gateway. This should be considered negligible and does not impact network design. Gateway access lists can be configured if necessary to prevent this stream from being established. CVP Call Server sends a New Call message to ICM via the VRU PG. ICM starts a routing script based on dialed number and other criteria. We assume now that the script begins with a simple menu.
3.
4. 5.
3-10
OL-8408-02
Chapter 3
Establishment of VRU Leg to VXML Gateway

1.
The ICM script executes a Send To VRU script node which results in a Connect message containing the VRU access number and a unique Correlation ID being sent to the CVP Call Server. The label is known as the "VRU Transfer Label". CVP Call Server consults that gatekeeper to translate the label to the IP address of an appropriate VXML gateway. (This gatekeeper consultation is mandatory as the CVP Call Server cannot transfer H.323 calls without being configured to use a gatekeeper) CVP Call Server sends an H.225 call setup to the selected VXML gateway, and requests the ingress gateway to redirect the media stream to the VXML gateway. Note that the destination number comprises the VRU transfer label with the Correlation ID appended. The H.323 call arrives at the VXML gateway which performs normal inbound VoIP dial-peer matching. Selected dial-peer invokes CVP TCL script. TCL script invokes CVP VXML bootstrap document, which performs an HTTP request to the configured CVP Call Server for the gateway (or via a CSS if present in the solution, see Chapter 5, Designing CVP for High Availability). The CVP Call Server strips the Correlation ID from the end of the dialed number and sends a Request-Instruction message to the ICM, which correlates this VRU call leg with the script that invoked the Send To VRU operation. The ICM script resumes and the IVR dialogue commences. The ICM sends a Run External Script to the CVP Call Server specifying the CVP microapp to be executed. to the VXML gateway.
2.
3.
4. 5. 6.
7.
8. 9.
10. CVP Call Server sends a VoiceXML Document containing the prompt or DTMF input instructions 11. VXML gateway voice browser executes the VoiceXML Document. 12. In executing the VoiceXML Document, the VXML gateway could optionally make an HTTP request
to retrieve media files from the Media Server.

13. VXML gateway sends an HTTP Call Result to the CVP Call Server. 14. CVP Call Server sends a RunScriptResult message to ICM. 15. ICM routing script continues by queuing the call for an appropriate skill group. We assume that no
agents are currently available.

16. The ICM routing script enters a RunExternalScript node to play a music file. 17. ICM sends a RunScriptRequest message to the CVP Call Server. 18. CVP Call Server sends a VoiceXML Document containing instructions to the VXML gateway to
play a music file.

19. VXML gateway voice browser executes the VoiceXML Document. 20. In executing the VoiceXML Document, the VXML gateway retrieves the required media file from
local cache or the configured media server if necessary.
ICM Transfers the Call to a Target

1.
While the music is playing an agent becomes available. ICM sends an agent label to the CVP Call Server.
3-11
Chapter 3 Model #3a, CVP Call Control with Queue and Collect
Deployment Models
2.
The CVP Call Server disconnects the current transferred call leg to the VXML Gateway and re-establishes the media channels for the incoming call leg from the ingress gateway to the CVP Call Server. The CVP Call Server sends an Empty Capability Set message to the ingress gateway and the media channels are disconnected pending setup of the new transferred call leg to the agent. The CVP Call Server consults the gatekeeper to translate the agent label to an appropriate destination IP address. This is a Cisco CallManager in the example scenario here but could alternatively be an egress gateway which is front-ending an ACD or TDM voice network. If the gatekeeper cannot return a destination IP address in response to the ARQ or the call setup fails to the primary and all possible alternate endpoints returned by the gatekeeper, an event report is sent to the ICM indicating connect failure. The ICM Router requery mechanism is invoked in order that the script might resume and perform further IVR treatment or provide alternative transfer destinations. Router requery is also performed if the call setup attempt results in destination busy or the called number does not answer within the CVP Call Servers predefined RNATimeout period. Note that RNATimeout is a system-wide setting for each CVP Call Server. The CVP Call Server issues an H.225 Setup to the target device and requests the ingress gateway to establish the media stream to the target device. Caller speaks to the agent.
3. 4.
5.
6. 7.
ICM Transfers a Call to a Second Target Via Blind Network Transfer

1. 2. 3. 4. 5. 6. 7.
We assume now that the agent needs to blind-transfer the call to a second skill group. We also assume that there are currently no agents available in that skill group. The agent, via his ACD or CTI desktop application makes a post-route request to ICM. ICM starts a new routing script, and executes another Queue node. On successfully queuing the call ICM executes a Run External Script node to return the caller to the VRU and present queuing messages and music while waiting in queue. ICM sends the VRU Transfer Label to the CVP Call Server along with a unique Correlation ID. The CVP Call Server commences another Empty Capability Set transfer to reconnect the caller to the VXML gateway. The CVP Call Server disconnects the current transferred call leg to the Cisco CallManager and re-establishes the media channels for the incoming call leg from the ingress gateway to the CVP Call Server. The CVP Call Server sends an Empty Capability Set message to the ingress gateway and the media channels are disconnected pending setup of the new transferred call leg to the VXML gateway. CVP Call Server consults that gatekeeper to translate the label to the IP address of an appropriate VXML gateway. gateway to redirect the media stream to the VXML gateway.
8. 9.
10. CVP Call Server sends an H.225 Setup to the selected VXML gateway, and requests the ingress 11. The VXML gateway starts a TCL/VXML application as described already for the VRU leg, which
sends an HTTP New Call message to the CVP Call Server (optionally via a CSS - see High Availability Design section).
12. The CVP Call Server sends a Request Instruction message containing the call's Correlation ID to
ICM via the VRU PG.
3-12
OL-8408-02
Chapter 3
13. The ICM routing script resumes execution with a RunExternalScript node to play the queuing
messages/music.
14. ICM sends a RunScriptRequest message to the CVP Call Server. 15. CVP Call Server sends a VoiceXML Document containing instructions to play the specified media
file.
16. VXML gateway voice browser executes the VoiceXML Document, retrieving media files from the
Media Server as necessary.

17. VXML gateway sends an HTTP Call Result to the CVP Call Server. 18. CVP Call Server sends a RunScriptResult message to ICM. 19. While the music is playing, an agent in the second skill group becomes available. ICM sends an
agent label to the CVP Call Server.

20. The CVP Call Server disconnects the transferred call leg to the VXML gateway and connects the
call to the new agent in exactly the same way as described earlier when the call was transferred to the first agent.
21. Caller speaks to the second agent. We assume now that the caller is satisfied and hangs up. 22. Ingress gateway sends an H.225 release to the CVP Call Server. 23. CVP Call Server sends an H.225 release to the Cisco CallManager to disconnect the agent. 24. CVP Call Server sends a Disconnect message to ICM.
Transfers
The following types of transfer are supported:

For agent to agent transfers, only blind transfers are supported when the agents are hosted on TDM ACD's. For IPCC agents, warm transfers are also supported. However, note that in this case the H.323 signaling is daisy-chained through the Cisco CallManager once the warm transfer has been completed by the agent. From the customers perspective, this means that the original callers line appearance remains on the first agents desktop application until the caller eventually hangs up. It also means that auto-answer will not function properly for the first agent, since she still appears to be talking to the caller.
Distributed: Ingress/VXML 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 CallManager site supporting both ACD agent and non-agent phones. This model also implies that the PSTN gateway is used not only for ingress of CVP calls, but also for ingress/egress of CVP related calls for that site. In circumstances where the VXML 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 VXML resource, as the CVP Call Server settransferlabel mechanism only applies to co-resident VXML and voice gateway configurations.
3-13
Chapter 3 Model #3b, CVP Call Control with Queue and Self Service
Deployment Models
Model #3b, CVP Call Control with Queue and Self Service

Customer Requirements, page 3-14 Caller Experience, page 3-14 Characteristics, page 3-15 Components, page 3-15 Protocol Level Call Flow, page 3-15 Transfers, page 3-16 Distributed: Ingress/VXML Gateway and VoiceXML Server at branch, page 3-16
Customer requirements include everything in Model #3a:

TDM migration to IP: Customer has a TDM ACD network, and wants to exploit the benefits and flexibility of routing calls over an IP network among those existing ACDs without tromboning. Customer wants to use the IP infrastructure to save costs, such as Takeback and Transfer charges, tie line charges, and PSTN network dip charges. Customer wants the advantages of pre-routing within an enterprise infrastructure without resorting to a service provider. Customer wants a cradle to grave view of all calls in the contact center. The ability to bring network level prompting and queuing into the enterprise.
as well as:

a need to support substantially more complex self service applications, which might or might not include ASR and TTS. The customer has an existing services oriented architecture environment for his web infrastructure, and wants to make use of it for self service.
Caller Experience
Caller dials a local or centralized phone number. The caller interacts with a complex self service application, and might choose to transfer to an agent. The caller might wait in queue, listening to music or messages. Eventually the caller speaks to an agent, after which the caller might be returned to queue and/or transferred to a different target, such as voice mail, another agent, or back into a self service application. All call context information is maintained for the life of the call.
3-14
OL-8408-02
Chapter 3
Deployment Models Model #3b, CVP Call Control with Queue and Self Service
Characteristics
The self-service scripting is developed primarily in VoiceXML Studio, though the initial invocation and possibly some amount of scripting might also be developed in the ICM Script Editor in order to link a number of self-service modules into an overall IVR service. The ICM script coordinates the interaction at a high level and integrates the IVR aspects of the call with the call routing business rules. ASR and TTS are often used in this model.
Components

Ingress gateways VXML gateways Gatekeepers CVP Call Servers CVP VoiceXML Servers (or other VXML application server) ICM or IPCC Enterprise or Hosted

Media servers Content Services Switches ASR/TTS MRCP servers

From a caller experience perspective, this model differs from Model 3a in only one respect: rather than beginning with a basic prompt and collect interaction, the caller enters a complex self service application. Everything else remains the same. At a protocol level, the entire message flow is the same, except that the ICM RunExternalScript node which invokes the prompting and collecting now invokes something more complex. Thus, Step 10. on page 3- 11 in the call flow above changes from "CVP Call Server sends a VoiceXML Document containing the prompt or DTMF input instructions to the VXML gateway" to the following steps:
1.
CVP Call Server sends a VoiceXML Document containing an embedded "subdialog" element, containing a URL for the VoiceXML Server application. This URL is built dynamically by the CVP Call Server using values set in CVP ECC variables by the ICM script. Optionally, data can be passed to the VXML subdialog either via URL or VXML parameters; the content of which is determined by the ToExtVXML ECC variables set in the ICM script. When the gateway voice browser executes this VoiceXML Document, it sends the embedded HTTP request to the VoiceXML Server. The VoiceXML Server invokes the requested application, and responds with a VoiceXML Document of its own, containing the first instructions comprising the self-service application. The gateway voice browser executes the VoiceXML Document, fetching and playing prompts as necessary from the Media Server.
2. 3. 4.
3-15
Chapter 3 Model #3b, CVP Call Control with Queue and Self Service
Deployment Models
5.
We assume that the application uses ASR to input information from the caller, and TTS to play text-based messages. The gateway voice browser sends a set of grammars and a request to the ASR server to recognize spoken input, as well as TTS requests to synthesize speech. The MRCP ASR/TTS server synthesizes the spoken message and plays it via an RTP stream back to the gateway. It also listens via an RTP stream in the other direction for utterances which match the specified grammars. The MRCP server responds to the gateway voice browser with a list of words which it recognized. The gateway voice browser sends a resulting HTTP request to the VoiceXML Server. The VoiceXML Server continues executing its script, serving additional Voice XML documents. Steps 2 through 8 are repeated as necessary. gateway voice browser containing a "subdialog return" element and optional data for delivery back to ICM.
6.
7. 8. 9.
10. Eventually the VoiceXML Server script terminates, and sends a VoiceXML Document to the
11. The gateway voice browser sends the resulting information in an HTTP request to the CVP Call
Server.
12. The CVP Call Server sends a RunScriptResult message to ICM. 13. ICM continues its routing script.
Transfers
Transfers are performed as detailed previously for model 3a:

Although the CVP VXML self-service applications could theoretically be scripted to perform their own transfers, these should not be used in this model and are not supported. The ICM, having passed control to an external CVP VXML application, expects to resume control of the call once the application has completed. If a transfer is required then the destination number, if determined by the self-service application, wants be returned to ICM via the FromExtVXML ECC variables which can be set on the subdialog-return script element. For agent to agent transfers, only blind transfers are supported when the agents are hosted on TDM ACDs. For IPCC agents, warm transfers are also supported. However, it should be noted that in this case the H.323 signaling is daisy-chained through the Cisco CallManager once the warm transfer has been completed by the agent. From the customers perspective, this means that the original callers line appearance remains on the first agents desktop application until the caller eventually hangs up. It also means that auto-answer will not function properly for the first agent, since she still appears to be talking to the caller.
Distributed: Ingress/VXML Gateway and VoiceXML Server at branch

When this model is extended to a distributed gateway architecture, all the points mentioned in model 3a must be considered. In addition, since the CVP VoiceXML Server and ASR/TTS are now involved, we must also consider the points described in model 1.
3-16
OL-8408-02
Chapter 3
Deployment Models Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service
For example, the VoiceXML Server might be either centralized or located at the branch, and ASR is not supported unless the ASR servers can be co-located with the VXML gateways wherever they are placed. Finally, if the solution involves internal IP calls from the branch to the central office or to another branch office, these calls are not currently supported with ASR.
Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service

Customer Requirements, page 3-17 Caller Experience, page 3-17 Characteristics, page 3-17 Components, page 3-17 Protocol Level Call Flow, page 3-18
The customer has an existing PGW (PSTN Gateway) or TDM Intelligent Network for call control, and wants to use CVP as a network IVR or network self-service platform.
Caller Experience
Caller experience can be any of those described in models Model #2, CVP Call Control, page 3-5, Model #3a, CVP Call Control with Queue and Collect, page 3-9 or Model #3b, CVP Call Control with Queue and Self Service, page 3-14.
Characteristics
This model is characterized by the fact that all call control is performed through the NIC. CVP is only involved for the purpose of doing VRU treatment (ie.,queueing, collecting caller-input, or self service). Self service applications can be simple or complex, involving DTMF and/or ASR/TTS, and calls can be queued and transferred to agents. Blind network transfers are possible, subject to availability in the particular call control platform to which the NIC is connected. Note that PGW deployments connecting to ICM via the Generic SS7 NIC fall into this category, Models 2 and 3 apply when the PGW delivers H.323 calls to the CVP Call Server.
Components

Ingress/VXML gateways CVP Call Servers ICM
3-17
Chapter 3 Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service
Deployment Models

CVP VoiceXML Servers Media Servers ASR/TTS Servers Content Services Switch

In this deployment model the call control is performed by a voice network switching platform connected to the ICM typically via an SS7 or CRSP NIC. The steps involved in handling a typical inbound call are described below. In this scenario, the call receives initial IVR treatment, possibly involving queuing messages, and is transferred to a final destination.
1. 2. 3.
A call is delivered to the voice network switching platform. The switching platform sends a new call indication to the ICM. The ICM identifies the call from the dialed number and selects a routing script to process the call. The script is executed and the call is sent to the VRU for call treatment using a translation route or label plus Correlation ID depending on the ICM VRU type being used in this deployment. The selection of VRU type is determined by placement of the VRU at NAM or CICM level and the ability of the switching platform to support use of a Correlation ID. The connect-to-VRU message is sent from the ICM to the switching platform. The switching platform connects the incoming call to the voice gateway. Call arrives at the ingress gateway via a TDM connection. The gateway performs normal inbound pots dial-peer matching. (Note that in the case of the PGW being used in this deployment model this step involves delivery of an H.323 call to a VXML gateway and matching of a VoIP dial-peer) Selected dial-peer invokes CVP TCL script. TCL script invokes CVP VXML bootstrap document, which performs an HTTP request to the configured CSS VIP address for the primary CVP Call Server. CSS selects an available CVP Call Server to process the call. The CSS is only used for the initial http request to the CVP Call Server as subsequent requests from the gateway use the IP address of the CVP Call Server explicitly. call leg with the script that performed the Send/Translation Route to VRU operation.
4. 5. 6.
7. 8. 9.
10. The CVP Call Server sends a Request-Instruction message to the ICM, which correlates this VRU 11. The ICM script resumes and the IVR dialogue commences. 12. The ICM sends a Run External Script to the CVP Call Server specifying the CVP microapp to be
executed.
13. The CVP Call Server sends a dynamically generated VoiceXML Document to the voice gateway. 14. The gateway parses and renders the VoiceXML document. 15. This document might contain either VXML elements for speech output and caller input, or it might
invoke a sub-dialogue with a destination URL that references another VXML server, typically a CVP VoiceXML Server, in order to incorporate self service modules into the overall dialogue.
16. In the latter case, the IVR dialogue continues between the gateway and the VXML server as defined
in Model #3b (see Model #3b, CVP Call Control with Queue and Self Service, page 3-14).
3-18
OL-8408-02
Chapter 3
Deployment Models Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service
17. On completion of the self-service operations defined in the VoiceXML Document, the gateway
sends another http request to the CVP Call Server containing the results.
18. The CVP Call Server forwards the outcome to ICM using a Run Script Results message. 19. Further Run External Script nodes are executed in the ICM script until the IVR dialogue is
completed.
20. At this point the call might either be terminated or transferred to a call center agent or other
destination.
21. To terminate the call, the ICM sends a disconnect message to the switching platform. 22. Alternatively, to transfer the call to another destination, the ICM sends a connect message to the
switching platform which will result in disconnection of the VRU call leg from the voice/VXML gateway and connection of a new transferred leg to the selected target.
23. Subsequently, depending on the capability set of the switching platform and the ability of the
destination to perform a route request to ICM, the caller could be returned to CVP for further IVR treatment and queuing.
3-19
Chapter 3 Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service
Deployment Models
3-20
OL-8408-02
C H A P T E R
Sizing
This chapter discusses how to determine how many physical machines to order, and, in the case of gateways and gatekeepers, what kind to order. This chapter covers the following topics:

Sizing Overview, page 4-1 CVP Call Server, page 4-2 CVP VoiceXML Server, page 4-3 Gateway, page 4-3 Gatekeeper, page 4-6
Sizing Overview
As a basis for this exercise, first determine the customers contact center profile in terms of the number of calls which are in each state, worst case. In other words, if you were to observe the contact center at its busiest instant in the busiest hour, how many calls would you find are in each of the following states:

Self Service calls which are either executing applications using the CVP VoiceXML Server; Queue and Collect calls which are in queue for an agent, or which are executing prompt and collect type self service applications; and Talking calls which are connected to agents or to third party TDM VRU applications.
In counting the number of calls which are in the Talking state, count only calls which are using CVP or gateway resources. To determine whether a Talking call is using resources, you must consider how the call gets transferred to that VRU or agent. If the call was transferred via VoIP, it continues to use an ingress gateway port and it continues to use a CVP resource, because CVP continues to monitor the call and provides the ability to retrieve it and re-deliver it at a later time. The same is true of calls which are tromboned to a TDM target, using both an incoming and an outgoing TDM port on the same gateway or on a different gateway (ie., toll bypass). Calls which are transferred to VRUs or agents in this manner should be counted as Talking calls. However, if the call was transferred via *8 TnT, hook flash, TBCT, or an ICM NIC, neither the gateway nor CVP play any role in the call. Both components have reclaimed their resources. Such calls should not be counted as Talking calls.
4-1
Chapter 4 CVP Call Server
Sizing
Finally, include in the overall call counts those calls that have been transferred back into CVP for queuing or self-service, via either blind or warm methods. Because these calls usually do not amount to more than 5% or 10% of the overall call volume, it is easy to overlook them. You will also notice that the definitions of these call states differ somewhat from the similar definitions used for port licensing purposes (see Chapter 15, Licensing). The use of ASR or TTS has nothing to do with delineating which calls are in which state, whereas it does for licensing purposes. Similarly, the call state determination has nothing to do with whether the agents are IPCC agents or ACD agents, nor does it matter whether the customer intends to use CVPs ability to retrieve and re-deliver the call to another agent or back into self service. In addition to the overall snapshot profile of calls in the contact center, one more piece of information is required:
Busiest period call arrival rate, in terms of calls per second
You will need this information on a contact-center-wide basis. You can use statistical means to arrive at this number, because you will never be able to identify a true maximum arrival rate. Except in fairly small implementations, this is seldom the critical factor in determining sizing. Armed with the above data, you can now begin sizing each component in the network. This section first considers the CVP products Call Server and VoiceXML Server, followed by the gateways, gatekeepers and content switches. Note that this section deals entirely with the number and type of physical components required to support the customers system. It does not include any redundancy. For an understanding of how to extend these numbers to support higher reliability, please see Chapter 5, Designing CVP for High Availability.
Note
Unless otherwise noted, this entire Component Sizing chapter applies to all deployment models, including Model #1, Standalone Self-Service.
CVP Call Server

Note
The CVP Call Server is not used in Model #1, Standalone Self-Service. This section does not apply to such deployments. CVP Call Servers are sized according to the number of call legs they can handle, in addition to their maximum call arrival rate. A call might have up to two legs: one for call control activity (switch leg), and one for VRU activity (VRU leg). Each CVP Call Server can handle 400 call legs. Therefore, the number of calls each CVP Call Server can handle depends on the percentage of calls which are using two call legs. In the case of Deployment Model #3, CVP with ICM-Controlled Switching, all cases use only a switch leg. Therefore, each CVP Call Server can handle the full 400 calls. In the case of Deployment Model #4, IVR/Queuing via ICM with NIC-controlled routing, all calls use only a VRU leg. Each CVP Call Server can therefore again handle the full 400 calls. In Models #3a and #3b, the capacity depends on the percentage of calls which are in talking state. Each CVP Call Server is further limited to a 3 CPS call arrival rate. However, Model #4 is exempt from this limitation because the CVP Call Server in this model does not perform any H.323 processing. Specifically, the number of CVP Call Servers required is:
(2*Self Service + 2*Queue and Collect + Talking) / 400, rounded up
or
4-2
OL-8408-02
Chapter 4
Sizing CVP VoiceXML Server
call arrival rate / 3, rounded up (except in Model#4)
whichever is larger.
CVP VoiceXML Server

CVP VoiceXML Server sizing is simple. One VoiceXML Server can handle up to 500 calls. If you are using CVP VoiceXML Server, you should size those machines according to this formula:
calls / 500, rounded up
where calls refers to the number of calls which are actually in CVP VoiceXML Server self-service applications at that busy moment snapshot in time.
Gateway

Choice of Gateway, page 4-3 Gateway Sizing, page 4-4 Using MGCP Gateways, page 4-6
Choice of Gateway
CVP uses gateways for two purposes: TDM ingress and VoiceXML rendering. Any Cisco gateway which is supported by CVP can usually be used for either purpose or both. However, depending on your Deployment Model, you might need only one or the other:

Model #1, Standalone Self-Service: All calls use both ingress and VoiceXML Model #2, CVP with ICM-Controlled Switching: All calls use ingress only Model #3a, DTMF Menu, Prompt and Collect: All calls use ingress, some calls use VoiceXML Model #3b, ASR/TTS and/or complex IVR application: All calls use ingress, some calls use VoiceXML Model #4, IVR/Queuing via ICM with NIC-controlled routing: All calls use VoiceXML only
In cases where both ingress and VoiceXML are required, you can choose to run both functions on the same gateways, or you can choose to designate some gateways for ingress and others for VoiceXML. Following are some guidelines for determining whether they should be combined or split:

In classical branch office deployments, where the call needs to be queued at the branch where it arrived, ingress and VoiceXML functions must always be combined. In cases where a large number of non-CVP PSTN connections will share the gateways, it is recommended to dedicated Ingress for that purpose, and use separate VXML gateways. AS5850eRSC and Cisco Catalyst 6500 Communication Media Module (CMM) can be used for ingress only; they cannot be used for VoiceXML. VXML-only gateways are less costly, since they do not require DSP farms or TDM cards. Use a spreadsheet to determine which way you obtain the best price.
4-3
Chapter 4 Gateway
Sizing
With relatively low call volume, it is usually better to combine them for redundancy purposes. Two combined gateways are better than one of each, since the loss of one gateway still allows calls to be processed, though at a lower capacity.
The next decision is whether to use ISR gateways (2xxx or 3xxx) or the AS5xxx gateways. Guidelines state that ISR gateways should only be used in branch office sites, whereas AS5xxxx gateways should be used in centralized data center sites. Sometimes it is difficult to determine what constitutes a branch office, and therefore which gateway should be used. The following guidelines might help:
The classical definition of branch offices, for which you should use ISR gateways, includes:
Multiple sites where TDM calls will be arriving from the PSTN Those sites are separated from the data centers where most of the CVP equipment lie You will be placing only one gateway at each site
If you have sites where you will be stacking multiple gateways for any reason, then those sites are data center sites and should use 5xxx gateways. Anything which does not fit these two descriptions: use your best judgement.
Finally, note that IP-IP Gateway functionality is not a supported configuration with CVP. None of the deployment models described in Chapter 3, Deployment Models require this functionality, but some customers have very complex call flows which do not clearly fit those models, and some customers want to integrate with non-Cisco VoIP in a way where IP-IP gateway might be helpful.
Note
Refer to technical specifications for the AS5xxx series gateways at: http://www.cisco.com/en/US/products/hw/iad/index.html and for the Integrated Service Routers (ISRs) at: http://www.cisco.com/en/US/products/hw/routers/index.html.
Gateway Sizing
Individual Cisco gateways can handle different call capacities depending on whether they are doing ingress only, VoiceXML only, or a combination of the two. Gateways doing VoiceXML activities also have different call capacities depending on whether or not they are supporting ASR or TTS activities. In general, gateways performing ingress only can be sized according to the number of TDM cables that can be physically connected. For gateways which are combined or VXML-only, it is important to ensure that the overall CPU usage will be less than 70% on average. The factors affecting CPU usage are:

Calls per second (cps) Maximum concurrent calls Maximum concurrent VoiceXML sessions
Before sizing the voice gateways, use the IPCC Resource Calculator to determine the maximum number of trunks (DS0s) and VoiceXML IVR ports needed to support the entire solution. For almost all CVP deployment models, sizing is based on the Maximum concurrent VoiceXML sessions & VoIP calls, described in Table 4-1.
4-4
OL-8408-02
Chapter 4
Sizing Gateway
Table 4-1
Cisco Voice Gateway VXML Session Support
Voice Gateway and Dedicated VXML Sever VXML Platform Cisco 2801 Cisco 2811 Cisco 2821 Cisco 2851 Cisco 3725 Cisco 3745 Cisco 3825 Cisco3845 AS5400HPX AS5350XM AS5400XM VXML and DTMF 7 30 48 60 68 100 120 150 96 240 240 VXML and VXML and ASR/TTS DTMF 6 24 36 56 50 80 96 144 90 192 192 6 24 36 56 50 77 96 144 90 192 192 VXML and ASR/TTS 4 20 30 48 38 60 72 96 72 192 192 Memory Recommended 256MB 256MB 256MB 512MB 512MB 512MB 512MB 512MB 512MB Default Default
These numbers assume that the only activities running on these gateways are VoiceXML with basic routing and connectivity. If you intend to run additional applications, such as fax, security, normal business calls, etc., the capacity numbers presented here should be prorated accordingly. These figures apply to IOS version 12.4 (mainline). Also, note that if you run VXML on one of the 28/37/3800 gateways, additional licenses, FL-VXML-1 or FL-VXML-12 are required. Table 4-2 should also be consulted in order to ensure that the concurrent call load and call arrival rates do not exceed these rated capacities.
Table 4-2 Maximum Calls on a Platform
Platform 2801 2811 2821 2851 3725 3745 3825 3845 AS5400HPX AS5350XM AS5400XM
Maximum Calls per Second 1 1 1.2 2 2 4 4 8 7 20 20
Maximum VoIP Calls 32 80 128 192 192 384 384 540 384 192 648
4-5
Chapter 4 Gatekeeper
Sizing
In addition to these capacities, also consider how much DRAM and flash memory to order. The capacity which comes with the machine by default is usually sufficient for most purposes. However, if your application requires large numbers of distinct .wav files (as with complex self service applications), or if your application has unusually large .wav files (as with extended voice messages or music files), you might want to increase the amount of DRAM in order to accommodate more cache space. .Wav files are recorded at 8kb per second. Additionally, if you plan to use the flash memory itself rather than a media server to house media files, you might want to expand your flash memory order. The use of DRAM for prompt caching is discussed in detail in Chapter 14, Media File Options.
Using MGCP Gateways

Cisco Customer Voice Portal requires the deployment of H.323 voice gateways. However, customers might require the deployment of MGCP 0.1 Voice Gateways with Cisco CallManager-based IPC deployments. These requirements could be survivability, overlap sending, or simplified deployment. There are three design considerations to deploy Cisco Customer Voice Portal in this environment:

Design and Plan a phased migration of each MGCP voice gateway to H.323. Implement both MGCP 0.1 and H.323. There are some considerations with this option. First, only one signaling protocol might be assigned to a PTSN interface module. This means you need dedicated PSTN interfaces/modules to each CVP and to Cisco CallManager. If calls are being sent over the Wide Area Network, you must examine you Call Admission design. Optimally, have a single call admission control mechanism for all calls as well as the dialplan.
Deploy a second H.323 voice gateway at each CVP location. This means you need additional PSTN lines. If calls are being sent over the Wide Area Network (WAN), you must examine your Call Admission design. Optimally, have a single call admission control mechanism for all calls as well as the dialplan.
Gatekeeper
Gatekeepers are required components in all deployments except Model #1, Standalone Self-Service, and Model #4, NIC-based Call Control with CVP Queue, Collect and Self-Service. A gatekeeper is an H.323 entity on a LAN that provides address translation and control access to the LAN for H.323 terminals and gateways. The gatekeeper can provide other services to the H.323 terminals and gateways, such as bandwidth management and locating gateways. Generally, when you need to add a gatekeeper for the CVP design, you should use the Cisco 2811 for smaller deployments, the Cisco 3825 for medium deployments, and the Cisco 3845 or 7301 for larger deployments. Again, CPU utilization is the determining factor when sizing gatekeepers. Memory usage is seldom a critical factor, unless you are also using the same gatekeepers to register very large numbers of endpoints outside of the CVP implementation. The factors that affect CPU utilization are:

The overall number calls the gatekeeper has to support The length of time the gatekeeper has to monitor the call The number of H.323 endpoints registering with the gatekeeper The call arrival rate
4-6
OL-8408-02
Chapter 4
Sizing Gatekeeper
However in almost all cases the call arrival rate will be the determining factor in CVP implementations. Please see Table 4-3.
Table 4-3 Maximum Call Per Second on Router
Router 7301 72XX 3845 3825 3745 3725 2851 2821 2811
Max Calls per Second 100 80 70 60 50 40 30 20 10
Note
The 5xxx routers cannot be used as gatekeepers. Also, note that gatekeeper functionality should not be combined on the same router as gateway functionality, except in non-redundant lab environments (and a more expensive IOS feature set is required in this case as well). For the most current information about the Cisco integrated services routers, refer to the latest product documentation available at the following sites:
Cisco 2800 Series http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2800/
Cisco 3800 Series http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/3800/
Cisco 7301 http://www.cisco.com/univercd/cc/td/doc/product/core/7301/
4-7
Sizing
4-8
OL-8408-02
A R T
CVP Solution Design Best Practices
C H A P T E R
Designing CVP for High Availability

This chapter describes a best-practices Customer Voice Portal (CVP) solution high-availability system design. The chapter covers the following topics:

Overview, page 5-1 Layer 2 Switch, page 5-2 Originating Gateway, page 5-3 Gatekeeper, page 5-4 CVP Voice Browser, page 5-6 CVP Application Server, page 5-8 VoiceXML Gateway, page 5-10 Content Services Switch (CSS), page 5-12 Media Server, page 5-14 CVP VoiceXML Server, page 5-15 Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server, page 5-17 Cisco CallManager, page 5-18 Intelligent Contact Management (ICM), page 5-19 Standalone Distributed Diagnostics and Services Network (SDDSN), page 5-19
Overview
This design provides the highest level of failure protection. Your solution may vary depending upon the customers business needs, including:

Tolerance for call failure Budget Topological considerations
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
5-1
Chapter 5 Layer 2 Switch
are and which design characteristics you choose for the various CVP components, including the network infrastructure. A good CVP design is tolerant of most failures (defined later in this chapter), but sometimes not all failures can be made transparent to the caller. CVP is a sophisticated solution designed for mission-critical call centers. The success of any CVP deployment requires a team with experience in data and voice internetworking, system administration, and CVP application configuration. Before implementing 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 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 IP Telephony Solution Reference Network Design (SRND), available at: http://www.cisco.com/go/srnd For assistance in planning and designing your CVP solution, consult your Cisco or certified Partner Systems Engineer (SE). A note about the CVP Call Server component: throughout this document we have been treating this device as a single component, because there has not been a need to examine it in any more depth than that. When discussing CVP high availability however, it is important to understand that there are actually two parts to this component: the CVP Voice Browser and the CVP Application Server. The CVP Voice Browser is responsible for H.323 processing, and the CVP Application Server is responsible for the interface to ICM, as well as for the conversion of CVP Microapplications to VoiceXML pages and vice versa. CVP's high availability design treats these two parts as independent processes, allowing calls to be handled by one CVP Call Server's Voice Browser and another CVP Call Server's Application Server at the same time. We will cover this in detail as we discuss these components later in this chapter.
Layer 2 Switch
The figure below shows a high-level physical design layout for a fault-tolerant CVP system. Each component in the 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 5-1 Redundant CVP System
In , two Layer 2 switches comprise a single VLAN. There are two reasons for this design:
5-2
OL-8408-02
Chapter 5
Designing CVP for High Availability Originating Gateway
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. A Content Services Switch (CSS) and 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 Later 2 switches fails, one CSS is still functional.
Note
NIC teaming is not supported in the CVP solution. Gateway/Gatekeeper NIC redundancy is discussed in the next section.
Originating Gateway
The function of the originating gateway in a CVP solution is to accept calls from the PSTN and direct them to CVP for treatment. This section covers the following topics:

Configuration, page 5-3 Call Disposition, page 5-6
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 IPCC Enterprise Solution Reference Network Design (SRND), available at http://www.cisco.com/go/srnd In addition, consider the following CVP-specific issues when designing gateways for high availability in a CVP solution:
When used in ICM-integrated models, the originating gateway communicates with CVP using the H.323 protocol. Therefore, unlike many Cisco CallManager deployments where the gateway and Cisco CallManager typically communicate via MGCP, the originating gateway must be configured for H.323 when communicating with CVP in ICM-integrated CVP deployments. The H.323 protocol, unlike MGCP, has no inherent provisions for call survivability. Further details are discussed in CVP Voice Browser, page 5-6. When configuring the gateway for H.323, it is best to bind the H.323 interface to the virtual loopback interface, as illustrated in the following configuration example:
interface Loopback0 ip address 22.22.22.12 255.255.255.255 h323-gateway voip interface h323-gateway voip id Dir_GK ipaddr 200.1.1.120 1719 <<<<<<< GK Info h323-gateway voip h323-id paris h323-gateway voip bind srcaddr 22.22.22.12
This configuration makes H.323 independent of the gateway physical interfaces. In this way, if one NIC card fails, the other NIC card can start processing H.323 traffic.
5-3
As shown in the Redundant CVP System diagram, each gateway NIC card is connected to a different physical switch to provide redundancy in the event that one switch or interface fails. One of the switches must additionally be configured with a second VLAN to which one of the NIC cards must be connected. The loopback interface virtually ties together the two gateway NIC cards which are now residing in two different VLANs.
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 to a T1/E1 at an alternate gateway, provided the PSTN switch has its trunks and dial plan configured to do so.
Gatekeeper
An H.323 gatekeeper is always required in all ICM-integrated deployment models except Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service, which does not use CVP for call control at all. The CVP Voice Browser requires the use of a gatekeeper, and a CVP Voice Browser is used in all of these other models. Note, however, that a gatekeeper is an optional (although recommended) component for call routing by the originating gateway in those deployments; an originating gateway can perform all of its H.323 call routing by using VoIP dial-peers that contain static IP addresses, whereas the CVP Voice Browser 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 Voice Browser ignores the IP address result returned from the gatekeeper, and instead routes the IVR call leg back to the same originating gateway from which the call arrived. This feature ensures that no WAN bandwidth is incurred during IVR treatment/queuing. A gatekeeper is still required in this situation because the Voice Browser needs 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. Gatekeepers can use one of three types of high-availability mechanisms:

HSRP, page 5-4 Alternate Gatekeeper, page 5-5 Gatekeeper Clustering
Only HSRP and alternate gatekeeper are supported by CVP. Alternate gatekeeper support was introduced in CVP 3.1 SR1.
HSRP
HSRP is a Cisco proprietary routing protocol that provides backup to a gatekeeper in the event of failure. Using HSRP, two gatekeepers work together to present the appearance of a single virtual router on the LAN. 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.
5-4
OL-8408-02
Chapter 5
Designing CVP for High Availability Gatekeeper
The H.323 endpoints (such as the CVP Voice Browser, Cisco CallManager, 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 LAN segment, and therefore they generally cannot be separated geographically. When there are multiple data centers, position an HSRP pair at each data center. It may also be possible to provide a high-speed VLAN connection between the two data centers and split the HSRP pair between the data centers.
Alternate Gatekeeper
Unlike with HSRP, when there are multiple data centers, only one gatekeeper needs to positioned at each data center when using alternate gatekeeper. The CVP Voice Browser can be configured with a list of alternate gatekeepers (as many as needed as there is no limit). When the Voice Browser starts up, it attempts to register to the first gatekeeper in the list. If the registration is not successful, it proceeds to try the remainder of the gatekeepers sequentially in the list until a successful registration occurs. The VB stays registered to that gatekeeper until either:
That gatekeeper has some type of failure. The VB recognizes a gatekeeper failure in the following ways:
The periodic RAS RRQ (registration request) to the gatekeeper times out or is rejected. An ARQ (admission request) on a transfer times out. The gatekeeper pro-actively tells the VB to unregister, such as when the administrator does a
shutdown on the gatekeeper configuration.
The user does another setGK from VBAdmin. This causes the VB to register with the first gatekeeper in the list, if that gatekeeper is available, otherwise it once again does a sequential attempt.
Although the CVP Voice Browser does not specifically support GUP clustering, there is no reason that the alternate gatekeepers cannot be defined as part of a GUP cluster. In this way, other H323 endpoints that do support clustering (such as Cisco Call Manager and IOS gateways) can take advantage of the benefits of gatekeeper clustering. CVP simply ignores clustering messages, such as when one of the gatekeepers in the cluster becomes overloaded. 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 in the preceding bullets.
Configuration

HSRP, page 5-5 Alternate Gatekeeper, page 5-6
HSRP
Configure the HSRP gatekeepers according to the instructions in the latest version of the CVP Configuration and Administration Guide, available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
5-5
Chapter 5 CVP Voice Browser
Alternate Gatekeeper
Using CVP Voice Browser VBAdmin: Examples:
1.
set GK "10.86.129.33, 10.86.129.34, 10.86.129.35" This sets up 3 gatekeepers to which the VB could possible register. In each case, the VB registers to the first local zone that is configured in that gatekeeper. It also uses the default RAS port 1719.
2.
setGK "10.86.129.33:zonename1:1718, 10.86.129.34" This causes the VB to first attempt to register to gatekeeper 10.86.129.33 on port 1718 with local zone "zonename1". If that gatekeeper fails, the VB subsequently attempts to register to 10.86.129.34 on port 1719 with the first local zone defined on that gatekeeper.
Call Disposition
A gatekeeper can fail in any of the following ways. The call dispositions below apply to both HSRP and Alternate Gatekeeper.
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 CVP are serviced correctly, although it is
possible that some of the calls may invoke survivability during the period that the endpoints are re-registering to the backup gatekeeper.
All gatekeepers fail.

The CVP Voice Browsers 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 may be no
clean failover to the backup gatekeeper. If survivability is configured on the gateway, calls are default-routed.
CVP Voice Browser

There are two components in a CVP Call Server: Voice Browser and Application Server. Each has its own set of high-availability characteristics. In general, every data center that houses CVP call servers should follow the N+1 redundancy rule. For example, if the data center requires five call server boxes, install at least six.
5-6
OL-8408-02
Chapter 5
Designing CVP for High Availability CVP Voice Browser
Configuration
CVP Voice Browser high availability is configured on the originating gateways.
Configuring High Availability for New Calls

A gatekeeper knows which CVP Voice Browsers are in service and out of service. It is therefore important to let a gatekeeper route incoming calls to a CVP Voice Browser. By default, CVP Voice Browsers register to the gatekeeper with a technology prefix (tech-prefix) of 2#. 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 Voice Browser 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 Voice Browser. 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 CVP Voice Browsers as follows:
dial-peer voice 11111 voip session target ras (Tells the gateway to do a gatekeeper lookup to route the incoming call.) tech-prefix 2# (Tells the gateway to prepend 2# to the incoming DNIS string before passing it to the CVP Voice Browser. The CVP Voice Browser will strip the 2# before sending the request to the ICM.)
Configuring High Availability for Calls in Progress

In the event that a CVP Voice Browser fails with calls in progress, it is possible to salvage all calls provided certain gateway configuration steps have been taken. A Voice Browser can fail in one of several ways:

The server can crash The process can crash The process can hang An Ethernet cable can become disconnected.
The configuration discussed in this section protects against all of these situations. However, there are two situations that cannot be protected against:
Someone stops the process with calls in progress. This situation occurs when a system administrator forgets to put the Voice Browser out-of-service first to allow calls in progress to finish before stopping the process. The Voice Browser exceeds the recommended call rate. Although there is a throttle for the absolute number of calls allowed in the Voice Browser, there is no throttle for call rate. In general, exceeding 5 calls per second (cps) for an extended period of time causes the Voice Browser to have erratic and unpredictable behavior. This situation can be prevented by proper sizing of the CVP systems.
For call survivability, configure the originating gateways as described in the latest version of the CVP Configuration and Administration Guide, available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
5-7
Chapter 5 CVP Application Server
In the event of most downstream failures (including a CVP Voice Browser failure), the call is default-routed by the originating gateway. Note that survivability is not applicable in the CVP Standalone and NIC-routing models because there is no CVP Voice Browser involved anywhere in those models. On the originating gateways, also configure the following commands:
voice service voip h323 no h225 timeout keepalive hp rtcp report interval 3000 gateway timer receive-rtcp 3
Call Disposition
If the CVP Voice Browser fails, the following conditions apply:
Calls in Progress If the CVP Voice Browser fails after the caller has been transferred, (transfers include transfer to an IP phone, VoiceXML gateway, or other egress gateway), the call continues normally until a subsequent transfer activity (if applicable) is required from the CVP Voice Browser. 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 the CVP Standalone and NIC-routing models.)
New Calls New calls are directed by the gatekeeper to an alternate CVP Voice Browser. If no Voice Browsers are available, the call is default-routed to an alternate location by survivability. (Survivability does not apply in CVP Standalone and NIC Routing models)
CVP Application Server

High availability for the CVP Application Server is configured on the CVP Application Server itself, the CVP Voice Browsers, the VoiceXML gateways, and the Content Services Switch (CSS).
Configuration
A CVP Voice Browser selects an application server for the switch leg of the call. Configure the CVP Voice Browser as described in the latest version of the CVP Configuration and Administration Guide. One important addition to note is that the Voice Browser immediately reverts to using an application server earlier in the list if one becomes available. Although there is no limit to the number of application servers in the list, it is best to list only two. Otherwise, in some instances the caller has to wait for each application server in the list to time-out before being default-routed by survivability. (Survivability does not apply in the CVP Standalone and NIC Routing models.) For example, if the data center has three CVP servers (A, B, and C), then the application server lists could be configured as follows on the Voice Browsers:
Voice Browser A: setAppServerList localhost, B
5-8
OL-8408-02
Chapter 5
Designing CVP for High Availability CVP Application Server
Voice Browser B: setAppServerList localhost, C Voice Browser C: setAppServerList localhost, A
On the AppAdmin Call Definitions page in the Application Server, provisions must be made for overflow calls from a failed application server. Use the following best-practice recommendation:
Maximum number of calls allowed: 425 CVP Call Server capacity is limited to 400 simultaneous calls regardless of CPU or memory resources on the server, but it is prudent to allow for some overlap between calls which are terminating and new calls which are starting up. Note that in the most common Deployment Models, #3a and #3b, a call that is receiving IVR treatment counts as two calls: one call in the 100-port group and one call in the 200-port group.
100-port group: 400 200-port group: 400
It is generally best to make the 100-port and 200-port group values equal to accommodate any ratio of IVR treatment and transferred calls. The VoiceXML gateway sends HTTP requests to a CVP Application Server to obtain a VoiceXML document. It uses the following VoiceXML gateway configuration parameters to locate a server when not using a CSS. Note that the backup server is invoked only if the primary server is not accessible, and if this is not a load-balancing mechanism. Additionally, every call first attempts to access the primary before failing over to the backup.
hp host isn-vxml <ip-address-of-primary-application-server> hp host isn-vxml-backup <ip-address-of-secondary-application-server>
The VoiceXML gateway also uses the following VoiceXML gateway configuration parameters to locate a server when using a CSS. Because the CSS almost always locates an application server on the first request, a backup server is rarely invoked but should always be configured.
ip host isn-vxml <ip-address-of-CSS-VIP-for-app-server> ip host isn-vxml-backup <ip-address-of-CSS-VIP-for-app-server>
There are several files in flash memory on the gateway that are also involved with high availability: handoff.tcl, recovery.vxml, and several .wav files. Use Trivial File Transfer Protocol (TFTP) to load the proper files into flash memory according to instructions found in the latest version of the CVP 3.1 Configuration and Administration Guide. The CSS, if used, provides load balancing and failover for CVP Application Servers (as well as some other components, which are discussed later). Configure the CSS according to the instructions in the latest version of the CVP Configuration and Administration Guide.
Call Disposition
If the CVP Application Server 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 the CVP Standalone and NIC Routing models.) New calls are directed to an in-service CVP Application Server.
5-9
Chapter 5 VoiceXML Gateway
VoiceXML Gateway
The VoiceXML Gateway parses and renders VoiceXML documents obtained from one of several sources: the CVP Application Servers, the CVP VoiceXML Servers, or some other external VoiceXML source. Rendering a VoiceXML document means 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.
Configuration
High availability configuration for VoiceXML gateways is controlled by the gatekeeper and/or the CVP Voice Browser depending on the geographic location of the VXML gateways (centralized or distributed).
Centralized VoiceXML gateways

This refers to the case where VoiceXML gateways reside in the same data center as the CVP Call Server. 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 type-7 Network VRU is 9999999. 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 9999999* gw-priority 10 VoiceXMLgw1 VoiceXMLgw2 VoiceXMLgw3
Distributed VoiceXML gateways (ingress gateway and VoiceXML same gateway)

This refers to the case where the gateway that processes the incoming call from the PSTN is geographically separated from the CVP servers and the VoiceXML gateway that is used is the same as the ingress gateway. This is done to keep the media stream at the edge and not consume bandwidth on the WAN. Use the SetTransferLabel in VBAdmin (not gatekeeper zone prefixes) to control the selection of the VXML gateway.
Distributed VoiceXML gateways (ingress gateway and VoiceXML different gateway)

This refers to the case where the gateway that processes the incoming call from the PSTN is geographically separated from the CVP servers and the VoiceXML gateway that is used is different than the ingress gateway but located as the same site as the ingress gateway. This is done to keep the media stream at the edge and not consume bandwidth on the WAN and to optimize VoiceXML gateway sizing when it is appropriate to separate ingress and VXML gateways. In this case, setTransferLabel cannot be used, since one does not want the IVR leg of the call to go back to the ingress gateway. Additionally, it is also impractical to configure gatekeeper zone prefixes to control the call routing since one would need to configure separate network VRUs and labels in ICM for each remote site. Instead, use VBAdmin SetSigDigits functionality. Using this method, the CVP Voice Browser strips leading significant digit(s) from the incoming DNIS. The value that is stripped is saved and prepended with a # sign before subsequent transfers for the call occur. The VoiceXML gateway at the remote site should register to the gatekeeper with the same tech-prefix as the leading significant digit(s) that were stripped from the DNIS. The gatekeeper then routes the IVR leg of the call to the correct VoiceXML gateway. If using a Call Manager, remember that
5-10
OL-8408-02
Chapter 5
Designing CVP for High Availability VoiceXML Gateway
CVP indiscriminately prepends the sigdigits value to all transfers, including those to Call Manager. It is therefore necessary when using Call Manager in this scenario to define a gatekeeper-controlled trunk for each of the VoiceXML gateway tech-prefixes and to add zone prefix configuration to the gatekeeper for the Call Manager agents. Example:
Ingress gateway: dial-peer voice NNNN voip tech-prefix 2# (gets the call to CVP) Apply a translation-rule to the incoming DNIS to prepend the value 3. Assuming DNIS is 8002324444, the final DNIS routed to CVP is 2#38002324444 VBAdmin: setTechPrefix 2# (default) setSigDigits 1 (strip one digit from the DNIS after stipping the 2# tech prefix) VXML gateway: Register to gatekeeper with tech-prefix 3# Call Manager (if used): Create a separate gatekeeper-controlled trunk corresponding to each of the tech-prefixes used by the VXML gateways. Gatekeeper (only if using Call Manager): Define zone prefixes to appropriately route calls to Call Manager agents.
Call arrives at CVP with DNIS 2#38002324444 CVP first strips the tech-prefix (2#), leaving 38002324444 CVP then strips one digit (3) from the beginning of the DNIS, leaving 8002324444. 8002324444 is passed to ICM for call routing. When it is time to transfer, assume ICM returns the label 99999998877. CVP prepends 3#, giving 3#99999998877. This value is then passed to the gatekeeper for address resolution. Gatekeeper resolves this label to the VoiceXML gateway which registered as 3#. VoiceXML gateway should strip the 3# on the way in, leaving 99999998877 for the destination phone address.
Alternate Endpoints
In all the cases described above, provide alternate endpoints for each of the VoiceXML gateways in case the VoiceXML gateway rejects the incoming request (perhaps due to configuration error or overload):
endpoint alt-ep h323id VoiceXMLgw1 ip-address-VoiceXMLgw2 endpoint alt-ep h323id VoiceXMLgw2 ip-address-VoiceXMLgw3 endpoint alt-ep h323id VoiceXMLgw3 ip-address-VoiceXMLgw1
In the event that a CVP Voice Browser is unable to connect to a VoiceXML gateway, an error is returned to 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 the CVP Standalone and NIC Routing 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 CVP Voice Browser 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.
5-11
Chapter 5 Content Services Switch (CSS)
Call Disposition
If the VoiceXML Gateway fails, the following conditions apply to the call disposition:

Calls in progress are default-routed to an alternate location by survivability on the ingress gateway. (Survivability does not apply in CVP Standalone and NIC Routing models.) New calls find an alternate VoiceXML gateway.
Hardware Configuration for High Availability on the Voice Gateways

The individual hardware components have the following high-availability options:

Redundant power supplies and on-hand spares Separate components for higher availability Dedicated components, which have fewer interaction issues
Example 1: Separate PSTN Gateway and VoiceXML Gateway A PSTN gateway and a separate VoiceXML gateway provide greater availability than a combine PSTN and VoiceXML gateway. Example 2: Duplicate Components for Higher Availability

Two 8-T1 PSTN gateways provide greater availability than one 16-T1 PSTN gateway. Two 96-port VoiceXML servers provide greater availability than one 192-port VoiceXML server. Larger designs can use N+1 spares for higher availability.
Example 3: Geographic Redundancy for Higher Availability Geographical redundancy and high availability can be achieved by purchasing duplicate hardware for Side A and Side B.
Content Services Switch (CSS)

The VoiceXML gateway is the only box in the CVP solution that makes requests to the CSS. When the VoiceXML gateway needs to make a request for media, ASR/TTS or VoiceXML, it looks in its configuration to see to where it should make the request. When a CSS is used, the IP address that is configured on the VoiceXML gateway is a virtual IP address that points to a service configured on the CSS. There are four types of services that the VoiceXML gateway client can request from the CSS:

Media Server ASR/TTS CVP VoiceXML Server CVP Application Server
If the primary CSS that is servicing these requests should fail, the client VoiceXML gateway must still be able to obtain media and VoiceXML from the servers.
5-12
OL-8408-02
Chapter 5
Designing CVP for High Availability Content Services Switch (CSS)
Configuration
You can configure high availability for the CSS by using the Virtual IP (VIP) Redundancy method, as described in the latest version of the CVP Configuration and Administration Guide. Also refer to the latest version of the CSS Redundancy Configuration Guide, available at: http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/css_750/redundgd/index.htm Essentially, a master/backup pair of CSSs functions very much like an HSRP gatekeeper pair. They must reside on the same VLAN and exchange heartbeats using Virtual Router Redundancy Protocol (VRRP), a protocol very similar to HSRP. If the primary CSS fails, the backup CSS recognizes the failure within three seconds and begins processing client requests to its configured virtual IP addresses. The configuration of the master and backup CSSs must always be kept in syncronization.
Call Disposition
If the master CSS fails, then the following conditions apply to the call disposition:
Calls in progress encounter various behaviors, depending on the type of service the VoiceXML gateway client requested:
Media server requests are unaffected. The VoiceXML gateway has a very short-lived interaction
with the CSS for audio files. Upon receiving a media server request from the gateway, the CSS simply provides an HTTP redirect IP address for the VoiceXML gateway. At that point, the gateway fetches the audio file directly from the media server, bypassing any further interaction with the CSS. Additionally, media file requests to the CSS are very infrequent because the VoiceXML gateway caches previously retrieved media files.
CVP Application Server requests are unaffected. Only the initial VoiceXML document request
to a CVP Application Server uses the CSS. The CSS first picks a CVP Application Server to service the request. The first document passes through the CSS on its return to the VoiceXML gateway. However, subsequent VoiceXML requests are made directly from the VoiceXML gateway client to the CVP Application Server. If the CSS fails during the very brief period that the first VoiceXML document is being returned, the VoiceXML gateway simply retries the request. If the backup (now primary) CSS selects the same CVP Application Server as the previous one, there is an error due to a duplicate call instance. In that case, the caller is default-routed by survivability on the originating gateway. (Survivability does not apply in the CVP Standalone model.)
ASR/TTS requests typically fails but might be recoverable. When the VoiceXML gateway first
makes an ASR/TTS request to the CSS, a TCP connection is opened from the VoiceXML gateway to the Media Resource Control Protocol (MRCP) server. That TCP connection goes through the CSS and persists until the caller disconnects or is transferred to an agent. If the primary CSS fails, that TCP connection is terminated. The VoiceXML gateway returns an error code that you could write a script to work around. The worst-case scenario is that the caller is default-routed to an alternate location by survivability on the originating gateway. (Survivability does not apply in the CVP Standalone model.)
CVP VoiceXML Server requests may fail. The VoiceXML Gateway is "sticky" to a particular
CVP VoiceXML Server for the duration of the VoiceXML session. It uses CSS cookies to provide that stickiness. If the CSS fails, the backup CSS has no knowledge of the cookie. Subsequent requests in the session might go to the correct CVP VoiceXML Server, but there is no guarantee. The VoiceXML gateway returns an error code that you could write a script to work
5-13
Chapter 5 Media Server
around. The worst-case scenario is that the caller is default-routed to an alternate location by survivability on the originating gateway. (Survivability does not apply in the CVP Standalone model.)
New calls are directed transparently to the VIPs on the backup CSS, and service is unaffected.
Media Server
Audio files can be stored locally in flash memory on the VoiceXML gateway or on an HTTP/TFTP file server. By definition, audio files stored locally are highly available. However, HTTP/TFTP file servers provide the advantage of centralized administration of audio files.
Configuration when Using CVP Microapplications

The VoiceXML gateway sends HTTP requests to an HTTP media server to obtain audio files. It uses the following VoiceXML gateway configuration parameters to locate a server when not using a CSS. Note that the backup server is invoked only if the primary server is not accessible, and this is not a load-balancing mechanism. Once failover occurs, all calls continue to use the backup server until that server becomes inaccessible. Note that media-server is not a fixed name. It simply needs to match whatever name was assigned to the mediaserver ECC variable in the ICM script.
ip host mediaserver <ip-address-of-primary-media-server> ip host mediaserver-backup <ip-address-of-secondary-media-server>
The VoiceXML gateway also uses the following VoiceXML gateway configuration parameters to locate a server when using a CSS. Because the CSS almost always locates a media server on the first request, a backup server is rarely invoked but should always be configured. The CSS, if used, provides load-balancing and failover for HTTP media servers.
ip host mediaserver <ip-address-of-CSS-VIP-for-media-server> iip host mediaserver-backup <ip-address-of-CSS-VIP-for-media-server>
Configure the CSS according to the instructions in the latest version of the CVP Configuration and Administration Guide, available at: http://www.cisco.com/univercd/cc/td/doc/product/icm/isn/cvp31/cvp31doc/
Call Disposition when Using CVP Microapplications

If the media server fails, the following conditions apply to the call disposition:
Calls in progress should recover automatically. The high-availability configuration techniques described above should make the failure transparent to the caller. If the media request does fail, use scripting techniques to work around the error (for example, retry the request, transfer to an agent or label, or use TTS). New calls are directed transparently to the backup media server, and service is not affected. If the media server is located across the WAN from the VXML gateway and the WAN dies, the gateway continues to use prompts from gateway cache until such time that the requested prompt becomes stale, at which time the gateway attempts to re-fetch the media and the call fails if survivability is not enabled. If survivability is enabled, the call are default-routed.
5-14
OL-8408-02
Chapter 5
Designing CVP for High Availability CVP VoiceXML Server
Configuration when using CVP VoiceXML Studio scripting

When scripting in CVP VoiceXML Studio, unlike with ICM scripting, there is no concept of -backup for media files. The best the script writer can do is to point Properties->AudioSettings->Default Audio Path URI in the application to a single media server or the CSS VIP address for a farm of media servers.
CVP VoiceXML Server

The VoiceXML gateway makes HTTP requests to the CVP VoiceXML Server to obtain VoiceXML documents.
Configuration
The CVP VoiceXML Server high-availability configuration and behavior differ between Standalone deployments and deployments which are integrated with ICM, as described in the following sections.
Standalone Self Service Deployments

For instructions on configuring primary and backup CVP VoiceXML Servers, refer to section CVP VoiceXML Server Standalone Solution in the latest version of the CVP Configuration and Administration Guide, available at http://www.cisco.com/univercd/cc/td/doc/product/icm/isn/cvp31/cvp31doc/ Specifically, it is the CVPPrimaryVXMLServer and CVPBackupVXMLServer gateway parameters that control the high availability characteristics of VoiceXML server. If VoiceXML server load balancing and more robust failover capabilities are desired, a CSS may be used. To configure the CSS for CVP VoiceXML Server, refer to Appendix D, section "CVP VoiceXML Server Configuration" at the preceding link. Load balancing can also be achieved without a CSS by varying the primary and backup CVP VoiceXML Server configurations across multiple gateways.
Deployments using ICM

For instructions on configuring the CVP VoiceXML Server in an ICM-integrated deployment, refer to section "CVP VoiceXML Server with ICM" in the latest version of the CVP Configuration and Administration Guide. In the ICM script, first attempt to connect to VoiceXML Server A (172.21.5.32). If the application fails out the X-path of the VoiceXML Server ICM script node, VoiceXML Server B (172.20.1.32) should be tried. These IP addresses can also represent VoiceXML Server VIP's on the CSS. Note the optional time check in the script to see how long the caller had been in the IVR when the application failed. If the caller had been in the IVR a significant amount of time, it may seem rather odd to the caller to restart them from the beginning of the application.
5-15
Chapter 5 CVP VoiceXML Server
Figure 5-2
ICM Deployment Script
Call Disposition
If the CVP VoiceXML Server fails, the following conditions apply to the call disposition:
Calls in progress in a Standalone deployment are disconnected. Calls in progress in an ICM-integrated deployment can be recovered using scripting techniques to work around the error as shown in the script above (for example, retry the request, transfer to an agent or label, or force an error with an END script node to invoke survivability on the originating gateway). New calls are directed transparently to an alternate CVP VoiceXML Server. Note that without a CSS, callers may experience a delay at the beginning of the call waiting for the system to timeout while trying to connect to the primary VoiceXML server.
5-16
OL-8408-02
Chapter 5
Designing CVP for High Availability Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server
Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Server

The VoiceXML gateway sends MRCP requests to the ASR/TTS servers in order to perform voice recognition and text-to-speech instructions that are defined in a VoiceXML document.
Configuration
The ASR/TTS high-availability configuration and behavior differ between Standalone and ICM-integrated deployments, as described in the following sections.
Standalone Self Service Deployments

A CSS is required in Standalone deployments to provide failover capabilities for ASR/TTS. For instructions on configuring the ASR/TTS Server in a Standalone deployment, refer to section "ASR, TTS and Media Server Redundancy for Cisco CVP VoiceXML Server Applications" in the latest version of the CVP Configuration and Administration Guide, available at: http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml For instructions on configuring the CSS for ASR/TTS, see Appendix D in the latest version of the CVP Configuration and Administration Guide at the above link.
Deployments Using ICM

The VoiceXML gateway uses gateway configuration parameters to locate an ASR/TTS server both when using a CSS and when not using a CSS. Note that the backup server is invoked only if the primary server is not accessible, and if this is not a load-balancing mechanism. Once failover occurs, all calls continue to use the backup server until that server becomes inaccessible. The hostnames (such as asr-en-us) are fixed and cannot be modified. The only portion that may be modified is the locale. In the following example, there is a set of primary and backup English ASR/TTS servers and a set of Spanish servers. Configure the CSS, if used, according to Appendix D in the latest version of the CVP Configuration and Administration Guide, available at http://www.cisco.com/univercd/cc/td/doc/product/icm/isn/cvp31/cvp31doc/ When a CSS is used, the IP addresses mentioned the following example would be the virtual IP address for the ASR/TTS service on the CSS.
ip ip ip ip ip ip ip ip host host host host host host host host asr-en-us <ip-address-of-primary-English-ASR-server> asr-en-us-backup <ip-address-of-secondary-English-ASR-server> tts-en-us <ip-address-of-primary-English-TTS-server> tts-en-us-backup <ip-address-of-secondary-English-TTS-server> asr-es-es <ip-address-of-primary-Spanish-ASR-server> asr-es-es-backup <ip-address-of-secondary-Spanish-ASR-server> tts-es-es <ip-address-of-primary-Spanish-TTS-server> tts-es-es-backup <ip-address-of-secondary-Spanish-TTS-server>
5-17
Chapter 5 Cisco CallManager
Call Disposition
If the ASR/TTS MRCP server fails, the following conditions apply to the call disposition:
Calls in progress in Standalone deployments are disconnected. Calls in progress in ICM-integrated deployments can be recovered using scripting techniques to work around the error (for example, retry the request, transfer to an agent or label, switch to prerecorded prompts and DTMF-only input for the remainder of the call, or label or force an error with an END script node to invoke survivability on the originating gateway). New calls in Standalone or ICM-integrated deployments are directed transparently to an alternate ASR/TTS server if a CSS is being used. New calls in ICM-integrated deployments are directed transparently to an alternate ASR/TTS server if "-backup" gateway hostnames have been used.
Cisco CallManager
CVP transfers callers to IPCC Enterprise agent phones or desktops using the H.323 protocol. The CVP Voice Browser gets an agent label from the ICM and queries the gatekeeper with the label. The gatekeeper then returns an IP address of one Cisco CallManager in the cluster, and the CVP Voice Browser calls that IP address and connects the caller to the agent. The CVP Voice Browser proxies the signaling channel, so it remains in the call signaling loop after the transfer is completed. However, the RTP stream flows directly from the originating gateway to the phone. This fact becomes very significant in discussions of high availability.
Configuration
For the most current information on providing Cisco CallManager for high availability, refer to the latest version of the Cisco IPCC Solution Reference Network Design (SRND), available at http://www.cisco.com/go/srnd In addition, configure the originating gateway parameters according to the guidelines in the section on Configuring High Availability for Calls in Progress, page 5-7.
Call Disposition
If the Cisco CallManager process fails on the server that is either hosting the call or hosting the phone, the following conditions apply to the call disposition:
Calls in progress are preserved. Skinny Client Control Protocol (SCCP) phones have the ability to preserve calls even when they detect the loss of their Cisco CallManager. The caller-and-agent conversation continues until either the caller or agent goes on-hook. The CVP Voice Browser recognizes that Cisco CallManager has failed, assumes the call should be preserved, and maintains the signaling channel to the originating gateway. In this way, the originating gateway has no knowledge that Cisco CallManager has failed. Note that additional activities in the call (such as hold, transfer, or conference) are not possible. Once the parties go on-hook, the phone then re-homes to another Cisco CallManager server. When the agent goes on-hook, Real-Time Control Protocol (RTCP) packets ceases transmitting to the originating gateway, which causes the gateway to disconnect the caller 9 to 18 seconds after the agent goes on-hook. If survivability has been
5-18
OL-8408-02
Chapter 5
Designing CVP for High Availability Intelligent Contact Management (ICM)
configured on the gateway and the caller is waiting for some additional activity (the agent might think caller is being blind-transferred to another destination), the caller is default-routed to an alternate location.
New calls are directed to an alternate Cisco CallManager server in the cluster.
Intelligent Contact Management (ICM)

Cisco Intelligent Contact Management (ICM) software provides enterprise-wide distribution of multichannel contacts (inbound/outbound telephone calls, Web collaboration requests, email messages, and chat requests) across geographically separated contact centers. ICM software is an open standards-based solution whose capabilities include routing, queuing, monitoring, and fault tolerance.
Configuration
For the most current information on configuring ICM for high availability, refer to the latest version of the Cisco IPCC Enterprise Solution Reference Network Design (SRND), available at http://www.cisco.com/go/srnd
Call Disposition
There are many components in Cisco ICM, and call disposition varies depending on the component that fails. Although there are a few exceptions, the following conditions apply to the call disposition:

If the Voice Response Unit (VRU) Peripheral Gateway (PG) or any component on the VRU PG fails, calls in progress are default-routed by survivability on the originating gateway. If the Logger fails, calls in progress are unaffected. If the primary router fails, calls in progress are unaffected. If both the side A and side B routers fail, calls in progress are default-routed by survivability on the originating gateway. New calls are directed to the backup ICM component.
Standalone Distributed Diagnostics and Services Network (SDDSN)

SDDSN is a component that provides alarm reporting for CVP using a variety of mechanisms. The CVP Voice Browser and Application Server send process state information to SDDSN, which in turn generates alarms that can be distributed to one of several alarm tracking mechanisms. Common alarm tracking mechanisms include Cisco ICM Alarm Tracker, CiscoWorks2000, and Hewlett-Packard OpenView. Note that alarms are limited to CVP process-level alarms and interface alarms (that is, are the processes up and in service, can the Voice Browser contact a gatekeeper, can the Application Server contact the ICM, and so forth). Call-level alarms and server characteristics (memory and CPU) are not monitored.
5-19
Chapter 5 Standalone Distributed Diagnostics and Services Network (SDDSN)
Configuration
For the most current information on configuring SDDSN for high availability, refer to the latest version of the CVP Configuration and Administration Guide, available at: http://www.cisco.com/univercd/cc/td/doc/product/icm/isn/cvp31/cvp31doc/
Call Disposition
If the primary SDDSN server fails, CVP begins transmitting alarm data to the backup SDDSN server if one is configured. The following conditions also apply to call disposition:

Calls in progress are unaffected. New calls are unaffected.
5-20
OL-8408-02
C H A P T E R
Call Survivability in Distributed Deployments

In distributed deployments, design 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 CallManager site supporting both ACD agent and non-agent phones. This deployment also implies that the PSTN gateway is used not only for ingress of CVP calls, but ingress/egress of the regular non-ACD phone calls. Branch reliability becomes somewhat more of an issue than it is in a centralized CVP model, because WAN's are typically less reliable than LAN links. Therefore, you must provide mechanisms which 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 CVP and non-CVP related calls. For the Cisco CallManager endpoint phones, this is accomplished via on IOS feature known as Survivable Remote Site Telephony (SRST). Further details specific to SRST can be found in the IP Telephony SRND at: http://www.cisco.com/go/srnd For CVP related calls, survivability is handled using a combination of services from a TCL script (survivability.tcl) and SRST functions. The survivability TCL script is used to monitor the H.225 connection for all calls that ingress through the remote gateway. If a signaling failure occurs with this H.225 link, 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 IOS Gateway configuration. Alternative destinations for this transfer could be another H.323 transfer (including the SRST call agent at the remote site), *x TnT, and hook flash. When transferring to the SRST call agent at the remote site, the most common target is an SRST alias or a Basic ACD hunt group. Further information about these SRST functions can be found at the above link. For further information on configuration and application of these transfer methods, please see Appendix B, Transferring and Queueing calls with Customer Voice Portal of the CVP 3.1 Configuration and Administration guide. This can be found at: http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml This chapter covers the following topics:

Gatekeeper implications, page 6-2 CAC implications, page 6-2 RSVP, page 6-5 H.323 Gatekeeper Call Routing implications in a distributed branch CVP model (Centralized CallManager model), page 6-5
6-1
Chapter 6 Gatekeeper implications
Gatekeeper implications
In a pure TDM environment where CVP is switching calls from an ingress gateway to an egress gateway attached to TDM ACD/IVR, the gatekeeper can handle the Call Admission Control (CAC) functionality. CAC is a term used to describe the mechanism for determining if there is enough bandwidth on a network to place a call. If Cisco CallManager is the egress gateway, gatekeeper CAC can only be used if the ingress CVP gateways and the IP phones are at different sites. Please note that gatekeeper dialplan resolution is still in use. Since Cisco CallManager Locations-based CAC is used between the remote sites of a cluster, gatekeeper typically is used for dial-plan resolution only. Understanding the routing of calls in the dial plan and the gatekeeper resolution is important, as 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 when using this model in a situation where more than one Cisco CallManager Cluster is being used to control the remote sites. For further discussion and understanding of this topic, see H.323 Gatekeeper Call Routing implications in a distributed branch CVP model (Centralized CallManager model), page 6-5.
CAC implications
The two CAC mechanisms used in a CVP environment are Gatekeeper CAC and CallManager Locations CAC. In a completely centralized deployment, CAC is not necessary. CAC is only needed when there is a limited amount of bandwidth between the IP phones or gateways. Connection Admission Control (CAC) needs to be considered from a solution perspective, not just a CVP perspective. This is most evident in the distributed branch office model where there are other voice services, such as Cisco CallManager, sharing the same H.323 gateways with CVP and the amount of bandwidth between the sites is limited. The most important item to consider here is what CAC mechanisms are in place on the network so that a consistent CAC mechanism can be used to account for all the calls managed at that site. A standalone CVP system typically uses Gatekeeper CAC while a Cisco CallManager cluster managing multiple sites will use Cisco CallManager Locations Based CAC. Cisco CallManager keeps track of CAC by identifying devices in certain locations and keeping track of how many calls are active between these locations. Since the Cisco CallManager 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 limit the number of calls allowed. A thorough conceptual understanding of CAC mechanisms is important. These mechanisms are explained in the CAC section of the IPT SRND, which can be found at http://www.cisco.com/go/srnd If considerations are not given to CAC, in a distributed CVP model, three unique methods of CAC could be in use at the same time.

Gatekeepers for CVP If multiple clusters are used, gatekeepers for intercluster Cisco CallManager calls Cisco CallManager Controlled Locations Based Admission Control for remote sites managed by the same cluster
If Cisco CallManager is sending or receiving calls from CVP, and there are CVP gateways & IP Phone Agents collocated at remote sites, it is important to understand the call flows in order to design and configure CAC correctly.
6-2
OL-8408-02
Chapter 6
Call Survivability in Distributed Deployments CAC implications
The gatekeeper and Cisco CallManager do not share bandwidth usage information. Networks shared by both the gatekeeper and IP phones will have 2 separate CAC mechanisms determining if there is enough bandwidth to place a call. Understanding how Cisco CallManager determines an endpoints location is key to designing the CAC properly. Investigating this further, consider the basic call flow of a non-CVP call vs. a CVP call. When a user picks up an IP Phone and makes a call from the remote site to a the central site, Cisco CallManager considers the location definitions of the endpoints and the codec requirements defined in the CallManager Region definitions and decides whether or not to allow the call. Note that the CAC and the codec requirements are controlled between these endpoints by Cisco CallManager as the controlling call agent. CVP itself uses gatekeeper for dialed-number resolution and CAC. However, as previously noted, with multiple branch locations controlled by a single Cisco CallManager cluster, Cisco CallManager does not use gatekeeper for CAC (but LCAC instead). The Cisco CallManager must be aware that CVP delivered calls are coming from a gateway at a specific branch so it can consider these calls in the LCAC mechanism. This requires enabling one CallManager service parameter and ensuring that one other is set to default:

Change the Cluster wide service parameter Accept unknown TCP connections to True. (The default is False) Device Name of gatekeeper trunk that will use port 1720 must remain at the default of blank
Accept Unknown TCP Connection when set to true changes the behavior for inbound for H.323 calls. Cisco CallManager accepts an unknown H.225 TCP connection and wait for the H.323 setup message. Cisco CallManager then extracts the User to User Information Element UUIE. In this case, the element contains the IP address of the originating gateway. Cisco CallManager compares this against its configured gateways. If a match is found, the call is treated as if it originated from the voice gateway and not the CVP Voice Browser. Note that this is NOT how Cisco CallManager traditionally treats a gatekeeper-controlled H.323 call. Typically, all gatekeeper-controlled calls come from Location 0 (Zero). This change ensures the call is not treated as a gatekeeper-controlled call and that Locations Admission control is applied. Note that, in this model, if the Cisco CallManager does not match the gateway signaling address in its list of configured gateways, it rejects the call. Figure 6-1 illustrates the decision tree for H.323 call processing.
6-3
Chapter 6 CAC implications
Figure 6-1
CallManager H323 Signalling Flow Topology
These changes allow for effective and scalable use of H.323 gateways in a Centralized CallManager deployment. In a CVP environment, Cisco CallManager can be an ingress or egress gateway. It is more common for Cisco CallManager to be an egress gateway because typically callers are calling from the PSTN, being queued by CVP, and then switched to Cisco CallManager for handling by an Agent. If the caller is not calling from the PSTN, but instead from an IP Phone, Cisco CallManager is an ingress gateway from the perspective of CVP.
Cisco CallManager as an egress Gateway

CVP normally depends on the gatekeeper for Dial-plan resolution & CAC. In order to deploy Cisco CallManager alongside CVP, Cisco CallManager CAC needs to be used for calls between the ingress CVP gateway and the agent IP phone. The ability for Cisco CallManager to correctly identify the ingress CVP gateway is complicated because the CVP Call Server is the one that is actually making the H.323 call to Cisco CallManager. Therefore, Cisco CallManager sees the call as coming from the centralized CVP Call Server rather than the remote ingress gateway.
6-4
OL-8408-02
Chapter 6
Call Survivability in Distributed Deployments RSVP
The CVP Call Server is able to solve this problem by setting the source signaling inside the H.323 setup to the IP address of the ingress gateway. The Cisco CallManager, upon receiving the setup from CVP, sees the source signaling address and knows that the address is the one that should be used when determining what location the call is coming from. Since the Cisco CallManager has this ingress gateway IP configured, Cisco CallManager will use Locations CAC to deduct bandwidth between the ingress gateway and destination IP phone locations. The CVP Call Server should not be configured as a gateway in Cisco CallManager; instead the CVP Call Server should send calls to Cisco CallManager via a gatekeeper controlled H.323 Trunk.
Cisco CallManager as an ingress Gateway

When an IP Phone initiates a call to CVP, Cisco CallManager is acting as the ingress gateway to CVP. Since the CVP Call Server cannot be configured as a gateway in Cisco CallManager, Cisco CallManager must send the call to CVP via a gatekeeper controlled H.323 Trunk. When a remote phone calls CVP, and is transferred to its local VoiceXML gateway, Cisco CallManager thinks that the call is traversing the WAN since the gatekeeper controlled Trunk is in the hub location and deducts bandwidth to the remote phone even though no WAN bandwidth is in use. Also, the Trunk that is sending calls to CVP needs to have MTP required checked.
Multiple Cisco CallManager Clusters

If a call coming in through a CVP ingress gateway is destined for an IP Phone at a different site registered to a different cluster, the call must be routed through the cluster that is handling CAC for the ingress gateway first, 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 CAC for the ingress gateway is not aware of the call traversing the WAN and does not deduct bandwidth appropriately.
RSVP
Cisco CallManager 5.0 introduces support for RSVP between endpoints within a cluster. RSVP is a protocol used for Call Admission Control (CAC) and is used by the routers in the network to reserve bandwidth for calls. RSVP can be used for delivering calls to IPCC agents in a CallManager cluster. For more information on RSVP, please refer to the Cisco CallManager 5.0 version of the Cisco IP Telephony Solution Reference Network Design (SRND), available at http://www.cisco.com/go/srnd
H.323 Gatekeeper Call Routing implications in a distributed branch CVP model (Centralized CallManager model)
Proper configuration of remote H.323 gateways with a CallManager cluster is important. First consider the H.225 implications of this without the use of gatekeeper. When configuring dial-peer destinations for the IOS Gateways, you must configure a dial-peer pointing to the IP addresses of the Cisco CallManager servers that are processing calls for that gateway. These server IP addresses must be the same servers that are in the redundancy group on the device pool definition for that gateway in the CallManager configuration. If the remote H.323 gateway sends a call to a Cisco CallManager server that is not in the redundancy group for that gateway, the call is rejected.
6-5
Chapter 6 Call Survivability in Distributed Deployments H.323 Gatekeeper Call Routing implications in a distributed branch CVP model (Centralized CallManager model)
Figure 6-2
Dial Peer Configuration
In Figure 6-2, if the Madison gateway sends a call to the.3 server, the call is rejected. While this is simple to understand, with several hundred remote sites it can become challenging to maintain over an extended period of time; anytime the Cisco CallManagers gatekeeper redundancy group might be 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 RAS request to the gatekeeper for an IP address to which to send the call. The gatekeeper automatically responds with one of the Cisco CallManager server addresses defined in the redundancy group for the gatekeeper trunk. If the redundancy group is changed, the Cisco CallManager must be re-registered to the gatekeeper. However, no further configuration is necessary on the remote gateway.
Multiple Cisco CallManager Clusters

When more than one centralized Cisco CallManager cluster are used for the remote sites, additional consideration must be given to routing calls based on agent selection. In a multiple cluster environment, each cluster manages a group of remote sites and tracks the voice calls to those sites within the locations-based CAC mechanism. Using the changes discussed above, Cisco CallManager considers H.323 calls within its locations based CAC 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 LCAC mechanism described above, it is necessary for the remote gateway to be told to signal a call to the Cisco CallManager cluster that owns the location of that remote gateway. However, in an IPCC Enterprise environment, the ICM tracks the availability of agents without consideration to what cluster they are located on. This ability provides great scalability for IPCC Enterprise, but must be accounted for in this type of implementation.
6-6
OL-8408-02
C H A P T E R

Designing for call transfers is one of the major steps required when designing a CVP deployment. There are numerous transfer options that can be used with CVP. The goal of this section is to explain each of the different options and to provide pros, cons, or considerations associated with each. This chapter covers the following topics:

Release Trunk Transfers, page 7-1 ICM Managed Transfers, page 7-3 Intelligent Network (IN) Release Trunk Transfers, page 7-4 VoiceXML Transfers, page 7-4
Release Trunk Transfers

This section deals with types of transfer which release the ingress trunk, thus removing the gateway and CVP from the call control loop. There is no tromboning in these cases. These transfers have the following characteristics:

Release Trunk Transfers can be invoked by the VoiceXML server (standalone model) or via the ICM ICM Network Transfer using CVP as the routing client will not work, since CVP can no longer control the call These transfers are blind, meaning that if the transfer fails for any reason, ICM does not recover control of the call. Router Requery is not supported From an ICM reporting standpoint, Release Trunk Transfers cause the switch leg to terminate, resulting in a TCD record being written to the database for the call, even though the caller is still potentially talking to an agent. This differs from other types of transfer, in which the TCD record does not get finalized until the caller actually hangs up. Since the ingress trunk is released, gateways do not need to be sized to include calls which have been transferred in this way. This differs from other types of transfer, where gateway resources continue to be occupied until the caller hangs up. Since CVP is no longer monitoring the call, CVP Call Servers do not need to be sized to include calls which have been transferred in this way. Additionally, CVP Call Director port licenses are not required.
There are three signaling mechanisms available to trigger a release trunk transfer:

Takeback-N-Transfer (TNT), page 7-2 Hook flash and Wink, page 7-2
7-1
Chapter 7 Release Trunk Transfers
Two B Channel Transfer (TBCT), page 7-3
Takeback-N-Transfer (TNT)
TNT (also known as Transfer Connect) is a transfer mechanism offered by some U.S. PSTN service providers (like AT&T & MCI/Verizon). With this transfer method, inband DTMF tones are outpulsed to the PSTN by CVP. These inband tones act as a signaling mechanism to the PSTN requesting a transfer to be completed. A typical DTMF sequence is *8####, where #### represents a new routing label that the PSTN understands. Upon detection of a TNT DTMF sequence, the PSTN drops the call leg to the ingress gateway port, and then re-routes the caller to a new PSTN location, such as a TDM ACD location. This behavior might be necessary for a customer with existing ACD site(s), but no IVR, who wants to use CVP initially as just an IVR. Over time, the customer might want to transition agents from the TDM ACD(s) to IPCC Enterprise and use CVP as an IVR, queueing point, and transfer pivot point (thus eliminating the need for TNT services). In CVP deployments with the ICM, the DTMF routing label outpulsed could have been an ICM translation routing label to enable passing of call data to another ICM peripheral (like a TDM ACD). In this ICM-routed scenario, CVP views this as a completed call and CVP call control is ended. With TNT, if the transfer to the termination point fails, there is nothing CVP can do to re-route the call. While some TNT services do have the ability to re-route the call back to CVP, CVP sees this call as a new call. TNT transfers are not supported under Deployment Model #1, Standalone Self Service.
Hook flash and Wink

Hook flash and Wink are signaling mechanisms typically associated with a TDM PBX/ACD. Hook flash is only applicable to analog trunks and Wink is only applicable to digital trunks (T-1 or E-1 channel), but otherwise they are similar in function. Both hook flash and Wink send an on-hook/off-hook signal to the PBX/ACD, which responds with dial tone (or the PBX winks back on a digital trunk). This causes the voice gateway to send a string of routing digits to the PBX/ACD. Upon collection of the routing digits, the PBX/ACD transfers the caller to the new termination, which could be an ACD queue or service on that same PBX/ACD. This behavior might be necessary for a customer with an existing ACD, but no IVR, who wants to use CVP initially as an IVR logically installed on the line side of their existing PBX/ACD. Over time, the customer might want to transition agents from the TDM ACD to Cisco IPCC and have the voice gateways connected to the PSTN instead of the line side of the PBX/ACD. In CVP deployments with the ICM, the routing label could have been an ICM translation routing label. This enables passing of call data to the ACD service (and subsequently to the agent in a screen pop). With hook flash and Wink, if the transfer to the termination point fails, there is nothing CVP can do to re-route the call. While some PBX/ACD models do have the ability to re-route the call back to CVP, CVP sees this call as a new call. Hook flash transfer has been problematic in the past, because the PBXs and the gateways have constrained support for this feature. If at all possible, guide customers away from using PBX for ICM switching, and encourage them to terminate all their incoming calls on CVP ingress gateways rather than on their PBX, and allow CVP to route calls to the PBX rather than the other way around. However, if the customer insists on hook flash transfers, here is a list of known caveats at this point in time:
17XX gateway was not tested
7-2
OL-8408-02
Chapter 7
Call Transfer Options ICM Managed Transfers
2XXX/3XXX gateways: Can use Analog FXO or Digital FXO (T1/CAS). This is considered line-side hook flash to the PBX and this worked very well with our lab Avaya Definity G3. Cannot use E&M due to CSCdr96285. You can adjust the hook flash duration with "timing hookflash-out" under the voice-port. This can come in handy when you have a PBX that has a non-configurable hook flash duration. This gives us the ability to adjust it in on the gateway side. 5XXX gateways: Tested with T1/CAS "e&m-fgb dtmf dnis". E&M is considered "trunk-side hookflash" to the PBX, Not all switches support trunk-side hook flash (the Avaya G3 in our lab did not). Additionally, the hook flash duration on the 5XXX is 200 ms. The PBX needs to be configured for this. This option is highly switch dependent and a proof-of-concept with the switch vendor is recommended. In Deployment Model #1, Standalone Self Service, a TCL script is required to produce the hook TCL script is provided with CVP 3.1. In all cases, ANI is not available to the call when it gets to CVP. In some CVP deployment models, the ICM *might* already know the ANI if the call had been pre-routed there. In all cases, DNIS must be hard-configured on the gateway config based on the T1/E1 channel on which the call arrives. The PBX is programmed to route certain DNISes over certain T1 trunks. By virtue of the call arriving to the gateway on that trunk, you can definitively configure its DNIS. The drawback here is that the gateway trunk allocation must be pre-determined. The customer has to know what percentage of calls arrive to which DNISs so that the trunk groups on the gateway can be allocated accordingly. An alternate method that can be used on some PBXs is a "converse on step" whereby DTMF tones indicating DNIS and ANI are sent to the IVR. This method would require a single main ICM routing script do input DNIS digits using a Get Data (GD) Microapp, and then invoked the correct sub-script based on the collected DNIS digits. This method requires close coordination between Cisco, the PBX vendor and the customer, and has not been tested to date.
Two B Channel Transfer (TBCT)

TBCT is an ISDN based release trunk signaling mechanism that is offered by some PSTN service providers. When a TBCT is invoked, the ingress gateway places the initial inbound call on hold briefly while a second call leg (ISDN B Channel) is used to call the termination point. Upon answer by the termination point, the gateway sends ISDN signaling to the PSTN switch to request the transfer be completed and the call bridged through the PSTN switch, and removed from the ingress gateway. Like a TNT transfer, the termination point might be a TDM PBX/ACD connected to the PSTN. This behavior might be necessary for a customer with existing ACD site(s), but no IVR, who wants to use CVP initially as just an IVR. Over time, the customer might want to transition agents from the TDM ACD(s) to Cisco IPCC and use CVP as an IVR, queueing point, and transfer pivot point (thus eliminating the need for TBCT services). If the call to the termination point fails, there is nothing CVP can do to re-route the call.
ICM Managed Transfers

Most CVP customers use ICM Managed transfer. This is what CVP does most naturally: providing gateway-based switching for ICM and IPCC installations. In CVP deployments with the ICM, the ICM provides all call control. VoiceXML call control from the CVP VoiceXML Server is not supported when the ICM is deployed with CVP. ICM Managed transfers transfer the call to a new termination point, which might be any of the following:
A Cisco CallManager phone
7-3
Chapter 7 Intelligent Network (IN) Release Trunk Transfers
n egress port on the same gateway as the ingress port Distant egress gateway, which has a TDM connection to a TDM ACD or PBX (making use of Toll Bypass features) A CVP VXML gateway, for queuing or self service activities
To terminate the call, the voice gateway selects an outgoing pots or voip dial-peer based on the destination specified by ICM. When an ICM VoIP transfer occurs, the ingress voice gateway port is not released. If the termination point is an egress voice gateway, then a second voice gateway port is utilized. CVP continues to monitor the call, and ICM also retains knowledge and call control of the call and can subsequently request for the call to be retrieved from the current termination point and transferred to another termination point from the above list. This type of transfer is used when the CVP is treated as a call treatment platform and queue point for IPCC Enterprise agents. The CVP could also be used to provide call treatment to front end calls to ICM supported TDM ACD locations. This type of transfer allows for calls to be transferred between ICM supported peripherals with full call context and without any tromboning of the voice path. Calls which are transferred in this way have the following characteristics:

ICM Network Transfer using CVP as the routing client functions properly, since CVP continues to control the call. These transfers are supervised, meaning that if the transfer fails for any reason, the ICM routing script does recover control via the Router Requery mechanism. From an ICM reporting standpoint, the switch leg does not terminate until the caller actually hangs up. Thus the TCD record which is written for the switch leg of the call encompasses the entire life of the call, from initial ingress to hang-up. Since the ingress trunk is not released, gateways need to be sized to include calls which have been transferred in this way. Since CVP continues to monitor the call, CVP Call Servers need to be sized to include calls which have been transferred in this way. Additionally, CVP Call Director port licenses are required, except for calls which are connected to CallManager agents.

Customers using Deployment Model #4, IVR/Queuing via ICM with NIC-controlled routing, rely on call switching methods that do not involve CVP. In these situations, all switching instructions are exchanged directly between an ICM Network Interface Controller (NIC) and the PSTN. Examples of such NIC interfaces include SS7 and CRSP. The SS7 NIC is also used as an interface into the PGW, in deployments which involve that device. Thus, PGW deployments perform this type of transfer.
VoiceXML Transfers
VoiceXML call control is only supported in standalone CVP deployments (Deployment Model #1) in which call control is provided by the VoiceXML server. Deployment Model #3b, which also incorporates the VoiceXML Server, does not support VoiceXML call control. In those and all ICM integrated deployments, ICM must make all call control decisions. The VoiceXML Server can invoke 3 different types of transfers releaseable trunk transfers, VoiceXML blind transfers, and VoiceXML bridged transfers. Releaseable trunk transfers result in the incoming call being released from the ingress voice gateway. VoiceXML blind transfers result in the call being bridged
7-4
OL-8408-02
Chapter 7
Call Transfer Options VoiceXML Transfers
to an egress voice gateway or a VoIP endpoint, but the VoiceXML server releases all subsequent call control. VoiceXML bridged transfers result in the call being bridged to an egress voice gateway or a VoIP endpoint, but the VoiceXML server retains call control so that it can return a caller to an IVR application or transfer the caller to another termination point. VoiceXML blind and bridged transfers are invoked using the Transfer element in VoiceXML Studio. VoiceXML Transfers will transfer the call to any dial-peer that is configured in the gateway. Releaseable trunk transfers from the VoiceXML server are invoked using the subdialog_return element VoiceXML Blind Transfers differ from VoiceXML Bridged Transfers in two respects:
VoiceXML blind transfers do not support call progress supervision, whereas Bridged transfers do. This means that if a blind transfer fails, the VoiceXML Server script does not recover control and cannot attempt a different destination or take remedial action. VoiceXML blind transfers cause the VoiceXML Server script to end. Always connect the done exit branch from a Blind transfer node to a subdialog_return and a hangup node. Bridged transfers do not terminate the script. The VoiceXML Server waits until either the ingress or the destination call ends. The script ends only if the ingress call leg hangs up. If the destination call leg hangs up first, the script recovers control and continues with additional self service activity. Note that the VoiceXML Server port license remains in use for the duration of a bridged transfer, even though the script is not actually performing any processing.
7-5
Chapter 7 VoiceXML Transfers
7-6
OL-8408-02
C H A P T E R
Network Level Considerations (The IP Infrastructure)

This chapter presents deployment characteristics and provisioning requirements of the CVP network. Provisioning guidelines are presented for network traffic flows between remote components over the WAN, including recommendations for applying proper Quality of Service (QoS) to WAN traffic flows. For the most current information on network considerations, refer to the sections on deployment models, bandwidth, and QoS presented in the latest version of the Cisco IP Contact Center Enterprise Edition Solution Reference Network Design (SRND) available at http://www.cisco.com/go/srnd This chapter covers the following topics:

Bandwidth Provisioning and QoS Considerations, page 8-1 Bandwidth Sizing, page 8-4 Call Admission Control, page 8-6 QoS, page 8-7 Blocking initial G.711 Media Burst, page 8-7 Network Security using Firewalls, page 8-8
Bandwidth Provisioning and QoS Considerations

In many CVP deployments all components are centralized. Therefore, there is no WAN network traffic to consider. In general, there are only two scenarios when WAN network structure must be considered in a CVP environment:

In a Distributed CVP deployment when the ingress gateways are separated from the CVP servers by a WAN. In a CVP deployments where the caller and the agent are separated over a WAN. The agent can be a TDM ACD agent or an IPCC agent.
Unlike ICM, CVP has a very simple view of QoS:

CVP has no concept of a private WAN network structure. All WAN activity, when required, is conducted on a public converged WAN network structure. CVP does not provide QoS packet marking. QoS, if required, must be provisioned in the IP routers in the network using an IP address and port number. Also, CVP does not use separate IP addresses for high and low priority traffic.
8-1
Chapter 8 Bandwidth Provisioning and QoS Considerations
Adequate bandwidth provisioning is an important component in the success of CVP deployments. Bandwidth guidelines and examples are provided in this chapter to help with provisioning the required bandwidth.
CVP Network Architecture Overview

In a CVP environment, WAN and LAN traffic can be grouped into the following categories:

Voice Traffic, page 8-6 Call Control Traffic, page 8-2 Data Traffic, page 8-4
Voice Traffic
Voice calls (voice carrier stream) consist of Real-Time Transport Protocol (RTP) packets that contain actual voice samples. RTP packets with voice samples are transmitted in the following cases:
Between the ingress PSTN phone gateway or IP Phone and one of the following:
IP phone
The destination phone might or might not be co-located with the ingress gateway or calling IP Phone, and the connection can be over a WAN or LAN.
An egress gateway front-ending a TDM ACD (for legacy ACDs or IVRs)
The egress gateway might or might not be co-located with the ingress gateway, and the connection can be over a WAN or LAN.
VoiceXML gateway performing prompt-and-collect treatment
The VoiceXML gateway will usually be the same gateway as the ingress gateway, but it can be different. In either case, both the ingress and VoiceXML gateways are typically co-located on the same LAN. One exception to this rule is a Distributed CVP deployment with centralized ASR/TTS servers. In that case, the VoiceXML gateways are co-located with the ASR/TTS server across the WAN from the ingress gateway. Because of the bandwidth-intensive nature of this particular configuration, it is not used often. The connection is typically over a LAN, but can be over a WAN.
Between the VoiceXML gateway and the ASR/TTS server. Recognition quality cannot be guaranteed if the VoiceXML gateway and ASR server are separated via a WAN. ASR/TTS Servers must be co-located with the VoiceXML gateway.
Call Control Traffic

There are several types of call control traffic in a CVP solution. Call control functions include those used to set up, maintain, tear down, or redirect calls.
H.323
CVP is currently certified with three types of H.323 endpoints: Cisco IOS voice gateways, Cisco CallManager, and the PGW in either call control mode or signaling mode. H.323 traffic flows between the following endpoints:
8-2
OL-8408-02
Chapter 8
Network Level Considerations (The IP Infrastructure) Bandwidth Provisioning and QoS Considerations
Ingress gateway to/from CVP Voice Browser Here the ingress gateway can be a PGW, Cisco CallManager, or a Cisco IOS gateway. For the most current information on supported models and software versions for each of these components, refer to the latest version of the Cisco Customer Voice Portal (CVP) Bill of Materials (BOM), available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_hom e.html The connection in this case can be over a WAN or LAN.
CVP Voice Browser to/from egress gateway Here the egress gateway can be Cisco CallManager or a Cisco IOS gateway. For the most current information on supported models and software versions for each of these components, refer to the latest version of the Cisco Customer Voice Portal (CVP) Bill of Materials (BOM). The egress gateway is either a VoiceXML gateway used to provide prompt-and-collect treatment to the caller, or it is the target of a transfer to an agent (IPCC or TDM) or a legacy TDM IVR. The connection in this case can be over a WAN or LAN.
GED-125
The CVP Application Server and the ICM VRU PG communicate using the GED-125 protocol. The GED-125 protocol includes:

essages that control the caller experience, such as notification when a call arrives. Instructions to transfer or disconnect the caller Instructions that control the IVR treatment the caller experiences.
Because the VRU PG must always be co-located with the CVP Application Server, the connection is always over a LAN.
MRCP
The VoiceXML gateway communicates with ASR/TTS servers using Media Resource Control Protocol (MRCP) v1.0. This protocol currently works with Real-Time Streaming Protocol (RTSP) to help establish control connections to ASR/TTS servers such as Nuance, Scansoft, and IBM Websphere Voice Server. The connection in this case is always over a LAN.
ICM Central Controller to CVP VRU PG

No tool exists that specifically addresses communications between the ICM Central Controller and the CVP VRU PG. Testing has shown, however, that the tool for calculating bandwidth needed between the ICM Central Controller and the IP IVR PG also produces accurate measurements for CVP if you perform the following substitution in one field: For the field labeled Average number of RUN VRU SCRIPT nodes, substitute the number of ICM script nodes that interact with CVP. Nodes that can interact with CVP are Run External Script, Label, Divert Label, Queue to Skill Group, Queue to Agent, Agent, Release, Send to VRU, and Translation Route to VRU. This bandwidth calculator tool is available (valid Cisco Partner login required) at: http://www.cisco.com/partner/WWChannels/technologies/resources/IPCC_resources.html The connection in this case can be over a WAN or LAN.
8-3
Chapter 8 Bandwidth Sizing
Data Traffic
Data traffic includes VoiceXML documents and prerecorded media files returned as a result of HTTP requests executed by the VoiceXML gateway. Specifically:
The VoiceXML gateway requests media files in an HTTP request to a media file server. The media server response returns the media file in the body of the HTTP message. The VoiceXML gateway then converts the media files to RTP packets and plays them to the caller. The connection in this case can be over a WAN or LAN. The VoiceXML gateway requests VoiceXML documents from either the CVP VoiceXML Server or the CVP Application Server. The connection in this case can be over a WAN or LAN.
This chapter focuses primarily on the types of data flows and bandwidth used between a remote ingress gateway and the components with which it interfaces:

CVP VoiceXML Server CVP Application Server CVP Voice Browser IP phones Media servers Egress gateways ASR/TTS servers.
Guidelines and examples are presented to help estimate required bandwidth and, where applicable, provision QoS for these network segments.
Bandwidth Sizing
As discussed above, most of the bandwidth requirements in a CVP solution occur in a Distributed CVP topology, due primarily to the fact that the ingress/VoiceXML gateway is separated from the servers that provide it with media files, VoiceXML documents, and call control data. For purposes of the following discussion, assume all calls to a branch begin with one minute of IVR treatment followed by a single transfer to an agent that also lasts one minute. Each branch has 20 agents, and each branch handles a busy-hour maximum of 600 calls per hour. The call rate is therefore 0.166 calls per second (cps) per branch. Note that even a slight change in these variables might have a large impact on sizing.
VoiceXML Documents
VoiceXML documents are generated based on voice application scripts written using either ICM scripts or CVP VoiceXML Studio, or both. A VoiceXML document roughly corresponds to a Run External Script node in an ICM script. Each VoiceXML document round-trip between the CVP Application Server and the gateway uses on average 7 kilobytes (kB). Assume that a Run External Script node executes every 3 seconds. Because each call receives an average of one minute of IVR treatment, that is approximately 20 VoiceXML documents per call. The bandwidth usage can then be calculated as follows: 7000 bytes 20 documents 8 bits = 1,120,000 bits per call
8-4
OL-8408-02
Chapter 8
Network Level Considerations (The IP Infrastructure) Bandwidth Sizing
0.166 cps 1,120,000 bits per call = 185.9 kbps per branch One might expect that CVP VoiceXML Server applications produce much more complex VoiceXML documents than do CVP Micro-applications, since the applications themselves are much more complex. However, that does not appear to be the case. CVP VoiceXML Server produces one VoiceXML document each time it encounters a user interaction element (a VoiceXML Element) in the script. It does not attempt to render multiple script elements into one VoiceXML document. Furthermore, CVP VoiceXML Server makes use of a root document, which enables it to factor out common VoiceXML code and error handling into a file which is fetched only once, at the beginning of the application. The bottom line is that you can assume that VoiceXML server pages average about the same as CVP Application Server pages: 7k bytes.
Media File Retrieval

Media files (prompts) can be stored locally in flash memory on each router. This method eliminates bandwidth considerations, but maintainability becomes an issue because a prompt that requires changes must then be replaced on every router. If the prompts are instead stored on an HTTP media server (or an HTTP cache engine), the gateway can locally cache voice prompts once it has initially retrieved the prompts. If configured correctly, the HTTP media server can cache many, if not all, prompts, depending of the number and size of the prompts. The refresh period for the prompts is defined on the HTTP media server. Therefore, the bandwidth utilized would be limited to the initial load of the prompts at each gateway, plus periodic updates after the expiration of the refresh interval. Not caching prompts at the gateway causes significant Cisco IOS performance degradation (as much as 35% to 40%) in addition to the extra bandwidth usage. For the most current information on configuring gateway prompt caching, refer to the latest version of the CVP Configuration and Administration Guide, available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml Assume that there is a total of 50 prompts, with an average size of 50 kB and a refresh interval of 15 minutes. The bandwidth usage would then be: 50 prompts 50,000 bytes per prompt 8 bits per byte = 20,000,000 bits 20,000,000 / 900 secs = 22.2 kbps per branch
H.323 Signaling
Every call that is processed by the branch gateway requires 6000 bytes, plus 1000 bytes for each transferred call to an agent, giving a total of 56,000 bits per call (7000 bytes 8 bits). Thus, the bandwidth required would be 0.166 56 kbps = 9.3 kbps for the WAN link to the remote branch.
ASR/TTS
Centralized ASR currently is not supported in Distributed CVP deployments because ASR/TTS servers must always be co-located with the VoiceXML gateway. Therefore, if you want to use AST/TTS in a Distributed CVP deployment, use one of the following configurations:
Install an ASR/TTS server(s) at every branch. In this model, ASR/TTS uses no additional bandwidth, but you will have significant added maintenance for the many additional servers.
8-5
Chapter 8 Call Admission Control
Install the ASR/TTS servers at a centralized site, and also add a separate VoiceXML gateway at the central site. In this model, there are fewer servers to maintain and there is no bandwidth usage for VoiceXML documents or media files. However, this solution is very bandwidth-intensive for voice.
ASR/TTS cannot use silence suppression and must use the G.711 codec. Assuming one minute of IVR treatment per call using G.711 between the ingress gateway at the branch and the VoiceXML gateway at the central site, the amount of bandwidth required would be: 80 kbps 60 secs = 4,800,000 bits per call 0.166 cps 4,800,000 bits per call = 796.8 kbps per branch Additional queue time increases this value by however much time the caller is in queue.
Note
80 kbps is the rate for G.711, full-duplex, with no VAD, all IP/RTP headers, and no compression.
Voice Traffic
CVP can support G.711 and G.729. For the most current bandwidth information on voice RTP streams, refer to the latest version of the Cisco IP Telephony Solution Reference Network Design (SRND), available at http://www.cisco.com/go/srnd
Call Admission Control

Call Admission Control or CAC is a term used to describe the mechanism for determining if there is ellManager will use Locations CAC to deduct bandwidth between the ingress gateway and destination IP phone locations. See CAC implications, page 6-2 for more information about CAC.
RSVP
Cisco CallManager 5.0 introduces support for RSVP between endpoints within a cluster. RSVP is a protocol used for Call Admission Control (CAC) and is used by the routers in the network to reserve bandwidth for calls. RSVP can be used for delivering calls to IPCC agents in a Cisco CallManager cluster. For more information on RSVP, please refer to the Cisco CallManager 5.0 version of the Cisco IP Telephony Solution Reference Network Design (SRND), available at http://www.cisco.com/go/srnd
8-6
OL-8408-02
Chapter 8
Network Level Considerations (The IP Infrastructure) QoS
QoS
CVP does not currently have the ability to mark the DSCP of IP packets from the CVP Server. If QoS is needed for CVP signaling and data traffic across a WAN, configure network routers for QoS using IP address and ports to classify and mark the traffic as recommended in Table 8-1.
Table 8-1 Recommended Port Usage and QoS Settings
Component Media Server CVP Call Server H.323 CVP Application Server CVP Call Server AppAdmin Remote Message Interface (RMI) port CVP VoiceXML Server Ingress Gateway H.323 VoiceXML Gateway H.323 H.323 Gatekeeper MRCP
Port r TCP 80 TCP 1720 TCP 8000 TCP 40099 TCP 8080 TCP 1720 TCP 1720 UDP 1719 TCP 554
Queue CVP-Data Signaling CVP-Data Default CVP-Data Signaling Signaling Signaling Signaling
PHB AF11* CS3 AF11* BE AF11* CS3 CS3 CS3 CS3
DSCP 10* 24 10* 0 10* 24 24 24 24
Max Latency (round trip) 1 sec 200 ms 1 sec 5 sec 1 sec 200 ms 200 ms 200 ms 200 ms
*The DSCP value for CVP-Data traffic is only a recommendation. The actual DSCP that is used to mark the traffic is your preference. Neither the CVP-Data queue nor the Signaling queue is a priority queue as described in IOS router terminology. The priority queue is used for Voice or other real-time traffic, while call signaling and CVP traffic are reserved a certain amount of bandwidth based on the call volume. Chapter 4, Sizing can help you determine how much bandwidth is needed for your environment.
Blocking initial G.711 Media Burst

When a gateway first receives a call, the gateway signals the CVP Call Server using H.323 in order to hand-off the Call Control responsibilities. In order to establish this initial call, a short media stream is established between the gateway and the CVP Call Server. The media stream is only in one direction, from the gateway to the CVP Call Server. Since this media stream is not accounted for by Cisco CallManager Locations based CAC, it is recommended that the media stream be blocked from traversing bandwidth constrained links in order to not oversubscribe the priority queue for RTP traffic. A sample ACL configuration would look like this:
access-list 100 deny udp host 10.0.0.1 host 10.10.0.100 range 16384 32767 access-list 100 permit ip any any interface serial0/0 ip access-group 100 out
In the preceding example 10.0.0.1 is the voice gateways H.323 bound IP address, and 10.10.0.100 is the CVP Call Server. If there are multiple Call Servers, add one ACL entry for each. The interface serial0/0 is the WAN interface connecting to the central site that is hosting the CVP Call Server.
8-7
Chapter 8 Network Security using Firewalls
Network Security using Firewalls

When configuring network security using firewalls or ACLs, please refer to the following table for information about TCP/UDP ports used by CVP, Voice Gateways & VXML Gateways.
Table 8-2 TCP/UDP ports used by CVP Voice Gateways & VXML Gateways ,
Source & Destination Component Voice Gateway -> Media Server Voice Gateway -> CVP Call Server H.225 Voice Gateway -> CVP Call Server Voice Gateway -> CVP VoiceXML Server Voice Gateway -> MRCP Server CVP Call Server -> Egress Voice Gateway H.225 CVP Call Server -> VoiceXML Gateway H.225 CVP Call Server -> H.323 Gatekeeper
Destination Port TCP 80 TCP 1720 TCP 8000 TCP 8080 TCP 554 TCP 1720 TCP 1720 UDP 1719
8-8
OL-8408-02
C H A P T E R

This chapter discusses ICM from the perspective of its relationship with CVP. In some cases, the choice of deployment model has implications for ICM, and in other cases, certain choices about the ICM configuration carry implications for the CVP deployment. This chapter covers the following topics:

NetworkVRU Types, page 9-1 NetworkVRU Types and CVP Deployment Models, page 9-4 Hosted Implementations, page 9-7 Cisco CallManager and ACD Originated Calls - Deployment Models and Sizing Implications, page 9-11 Using Third Party VRUs, page 9-12
NetworkVRU Types
This section first discusses Network VRU Types for ICM in general; then it discusses them as they relate to CVP deployments in particular. This section covers the following topics:

About ICM NetworkVRUs, page 9-2 CVP as Service Node IVR to ICM (Type 5), page 9-2 CVP as Intelligent Peripheral IVR to ICM based on Correlation ID mechanism (Type 3,7), page 9-3 CVP as Intelligent Peripheral IVR to ICM based on Translation Route ID mechanism (Type 8,2), page 9-4 NetworkVRU Types and CVP Deployment Models, page 9-4 Hosted Implementations, page 9-7
Note
In this document, the words VRU and IVR are used interchangeably.
9-1
Chapter 9 NetworkVRU Types
About ICM NetworkVRUs

This section describes ICM VRU Type Usage for CVP application. ICM perceives calls that need to have IVR session as having two portions: the Switch and the VRU legs. The Switch is the entity that first receives the call from the network/caller. The VRU is the entity to play audio, prompt and collect. CVP can participate either in the Switch role or the VRU role or both from the ICM perspective. In a network deployment, multiple CVP devices can also be deployed to provide the Switch and VRU portion each independently. ICM classifies the VRU system in the network that handles the interactions with the caller in two categories: The VRU operates as an Intelligent Peripheral IVR where the call will be delivered to the VRU for caller interaction, and then the call will be taken away from the VRU by a call control entity. (This is similar to the switch or SSP operation in a legacy PSTN intelligent network. SSP upon receiving instruction from a service control entity temporarily interacts with an intelligent peripheral for media resource invocation, and then resume the call processing toward completion.) The call delivery to VRU can be based on either a Correlation ID or a translation route mechanism, depending on the network capability to pass the call reference identification to the VRU. This is needed since the ICM has to correlate the two legs of the same call together in order to continue to provide instructions to complete the call. In the ICM application, the VRU needs to supply this call reference ID to ICM when the VRU asks for instructions on how to process the incoming call that it receives from the switch. This allows ICM to retrieve the appropriate call context for this same call, which at this stage is to proceed to the IVR portion of the call. Details of these two correlation mechanisms are described below. Correlation ID is used if the network can pass the call reference ID to the VRU. This usually happens when the VRU is located in the network with the switch and the call signaling can carry this information (e.g., Correlation ID information is appended to the dialed digits in the ICM use case). This is usually the case for calls being transferred within the VoIP network. Translation Route ID is used when the VRU is reachable across the PSTN (e.g., the VRU is at the customer premise) and the network cannot carry the call reference ID information in delivering the call to the VRU. A temporary directory number (known as a translation route label) has to be configured in ICM to reach the VRU and the network will route the call normally to the VRU as other directory number routing in the PSTN. When the VRU asks for instructions from ICM, VRU supplies this label (could be a subset of the received digits) and ICM can correlate the two portions of the same call. Normally the PSTN carrier will provision a set of translation route labels to be used for this purpose. In many cases, CVP acts as a Service Node IVR where the call is delivered to the VRU for caller interaction, but the VRU is the call control entity to switch and delivers the call to the final destination once the IVR session is completed. Thus, CVP can manage both legs of the call.
Note
The location of the deployed VRU as an intelligent peripheral IVR can be in the network (N-VRU) or at the customer premises (as such NAM in the network and CICM at the customer premise will also be deployed in this scenario). The corresponding correlation or translation route ID should be used accordingly, as described earlier, depending on the location of the VRU.
CVP as Service Node IVR to ICM (Type 5)

For VRU functions as a Service Node IVR in the network, ICM uses type 5 and type 6 to designate sub-behaviors of the VRU in the service node mode. They are described below.
9-2
OL-8408-02
Chapter 9
Interacting with ICM NetworkVRU Types
Type 5 and type 6 are similar in the sense that the VRU entity functions both as a switch (call control) and the VRU (IVR). However, they differ on how to connect to the VRU. In Type 6, the Switch and the VRU is the same device. Hence, the call is already at the VRU. No Connect/Request Instructions message sequence is needed from the ICM point of view. On the other hand, in Type 5, the Switch and the VRU are different devices although in the same service node viewpoint from the ICM, even though they both interact with ICM through the same PG interface. Therefore, ICM uses a Connect/Request Instructions sequence to complete the IVR call.
Note
In a CVP application, there are two legs of the call: the Switch leg and the VRU leg as perceived by ICM. In the CVP as service node application (i.e., CVP receives the call from the network directly; not pre-routing), CVP will appear to ICM as type 5 since the call control (the CVP) and the VRU device are different. Hence, CVP needs to be configured as VRU type 5 in the ICM/NAM configuration for the Switch leg. The VRU leg requires a different setup depending on the deployment model (e.g., the VRU leg could be type 7 in the comprehensive ICM enterprise deployment model). Refer to CVP 3.1 Configuration and Administration Guide for examples of configuration of CVP as type 5: http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.html Neither Correlation ID nor translation route is needed when CVP acts as type 5 VRU to ICM/NAM. However, a dummy label is sometimes required.
CVP as Intelligent Peripheral IVR to ICM based on Correlation ID mechanism (Type 3,7)
When the VRU functions as an Intelligent Peripheral IVR with Correlation ID mechanism, ICM uses type 3 and type 7 to designate sub-behaviors of the VRU via the PG in the Correlation ID scheme. They are described below. Both type 3 and type 7 VRU are reachable via Correlation ID mechanism. A PG is needed to control the VRU. However, the difference between these two types is on how to release the VRU leg and how to connect the call to the final destination. In Type 3, the switch that delivers the call to the VRU can take the call from the VRU and connect it to a destination/agent. In Type 7, the switch cannot take the call away from the VRU. When the IVR treatment is complete, ICM needs to disconnect/release the VRU leg first before the final connect can be sent to the switch leg to instruct the switch to connect the call to the destination. CVP when used as an Intelligent Peripheral IVR can function with either Type 3 or 7, but it is somewhat more efficient under type 7 since its gets a positive indication from ICM when its VRU leg is no longer needed (as opposed to waiting for the VXML gateway to inform it that the call has been pulled away). Remember that there are two legs of the call: the Switch leg and the VRU leg. Different CVP hardware can be used for each leg, but functionality-wise from the ICM perspective, there will be a CVP via PG acting as VRU type 5 (i.e., service node) along with a potential different CVP via another PG acting as VRU type 7 to complete the IVR application (self service, queuing, etc.) Refer to CVP 3.1 Configuration and Administration Guide for examples of CVP application with VRU Type 3 or Type 7 configuration: http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
9-3
Chapter 9 NetworkVRU Types and CVP Deployment Models
CVP as Intelligent Peripheral IVR to ICM based on Translation Route ID mechanism (Type 8,2)
When the VRU functions as an Intelligent Peripheral IVR with Translation Route mechanism, ICM uses type 8 and type 2 to designate sub-behaviors of the VRU via the PG in the translation route scheme. They are described below. Both type 2 and type 8 VRU are reachable via the Translation Route mechanism. A PG is needed to control the VRU. However, the difference is how to connect the call to the final destination. In Type 8: the switch that delivers the call to the VRU can take the call from the VRU and connect it to a destination/agent. Type 2 is used when the switch does not have the ability to take the call away from the VRU to deliver it to an agent. In that case, when the IVR treatment is complete, ICM sends final connect to the VRU (rather than to the original switch) to connect the call to the destination. The VRU effectively assumes control of the switching responsibilities when it receives the call. This is known as a handoff. Similarly to the Correlation ID case, there are two legs of the call: the Switch leg and the VRU leg. CVP can be used for the switch leg or the VRU leg (e.g., when NIC and NAM/CICM is involved, CVP will be configured as type 2 or type 8 in the VRU leg). Refer to CVP 3.1 Configuration and Administration Guide for examples of CVP application with VRU Type 8 or Type 2 configuration: http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
NetworkVRU Types and CVP Deployment Models

This section describes how NetworkVRU Types relate to the CVP Deployment Models described elsewhere in this document (see Chapter 3, Deployment Models). This section covers the following topics:

Model #1. Standalone Self-Service, page 9-5 Model #2. CVP with ICM-Controlled Switching, page 9-5 Model #3a. DTMF Menu, Prompt and Collect, page 9-5 Model #3b. ASR/TTS and/or complex IVR application, page 9-6 Model #4. IVR/Queuing via ICM with NIC-controlled routing, page 9-6 Model #4a. IVR/Queuing via ICM with NIC-controlled routing, page 9-6 Model #4b. IVR/Queuing via ICM with NIC-controlled pre-routing, page 9-7
In ICM, NetworkVRU is a configuration database entity. It is accessed using the Network VRU Explorer. A NetworkVRU entry has two pieces of information:

Type this is a number from 2 to 8, and corresponds to the types described above Labels this is a list of labels which the ICM can use to transfer a call to the particular NetworkVRU being configured. These labels are only relevant for NetworkVRUs of Types 3 and 7 (i.e., those that use the Correlation ID mechanism to transfer calls), and they are required but never used in the case of Type 5. Each label is made up of two parts:
A digit string, which becomes a DNIS that can be understood by the gatekeeper or by gateway
dial-peers; and
9-4
OL-8408-02
Chapter 9
Interacting with ICM NetworkVRU Types and CVP Deployment Models
A routing client, A.K.A. switch leg peripheral. In other words, each peripheral device which can
act as a switch leg must have its own label, even though the digit strings will likely be the same in all cases. NetworkVRU configuration entries themselves have no value until they are associated with active calls. There are three places in ICM where this association is made:

Advanced tab for a given peripheral in the PG Explorer tool Customer Instance configuration in the ICM Instance Explorer tool On every VRU Script configuration in the VRU Script List tool
Depending on the protocol level call flow, the ICM looks at either the peripheral or the customer instance to determine how to transfer a call to a VRU. Generally speaking, the ICM examines the NetworkVRU which is associated with the switch leg peripheral when the call first arrives on a switch leg, and the NetworkVRU which is associated with the VRU leg peripheral when the call is being transferred to VRU using the Translation Route mechanism. It examines the NetworkVRU which is associated with the Customer Instance when the call is being transferred to the VRU using the Correlation ID mechanism. ICM also examines the NetworkVRU which is associated with the VRU Script every time it encounters a RunExternalScript node in its routing script. If the ICM does not believe the call is currently connected to the designated NetworkVRU, it will not execute the VRU Script. We will now see how this plays out under the various CVP deployment models. Note that much of the discussion which follows is heavily dependent on capabilities which were introduced in ICM/IPCC version 7.0(0). If you are using an older version of ICM, please reference the CVP 3.1 Configuration and Administration Guide: http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
Model #1. Standalone Self-Service

The Standalone Self-Service model does not connect to ICM at all. Since ICM is not involved, the entire concept of NetworkVRU is irrelevant.
Model #2. CVP with ICM-Controlled Switching

In this model, ICM (and therefore CVP) is responsible for call switching only. It does not provide queuing or self service, and therefore there not a VRU leg. A NetworkVRU setting is not required.
Model #3a. DTMF Menu, Prompt and Collect

In this model, CVP devices act as both the switch and the VRU leg, but the call does need to be transferred from the switch leg to the VRU leg before any call treatment (playing .wav files, accepting user input) can take place. Associate all CVP peripherals with a Type 2 NetworkVRU.
Note
prior to ICM 7.0(0) a Type 5 was recommended here. That will still work properly, but new implementations should use Type 2
9-5
Chapter 9 NetworkVRU Types and CVP Deployment Models
Associate all incoming Dialed Numbers with a Customer Instance which is associated with a Type 7 NetworkVRU. (This is sometimes known as a Type 2/7 Configuration.) Finally, all the VRU Scripts that will be executed by this call need to be associated with the same Type 7 NetworkVRU. Though it is not always necessary, as a best practice the ICM routing script should always execute a SendToVRU node prior to the first RunExternalScript node.
Model #3b. ASR/TTS and/or complex IVR application

From a call routing and NetworkVRU perspective, this model is identical to Model #3a (see Model #3a, CVP Call Control with Queue and Collect, page 3-9).
Model #4. IVR/Queuing via ICM with NIC-controlled routing

In this model, the call first arrives at ICM through an ICM NIC interface, not through CVP. At least initially, CVP is not responsible for the switch leg; its only purpose is as a VRU. However, depending on which kind of NIC is being used, it might be required to take over the switch leg once it receives the call. This model actually has two submodels, which we will deal with separately.
Model #4a. IVR/Queuing via ICM with NIC-controlled routing

This submodel assumes a fully functional NIC. That is, the NIC is capable of delivering the call temporarily to a NetworkVRU (i.e., to CVPs VRU leg), and then retrieving the call and delivering it to an agent when that agent is available. It further assumes that if the agent is capable of requesting that the call be re-transferred to another agent, or back into queue or self service, the NIC is capable of retrieving the call from the agent and re-delivering it as requested. We must now consider two variants of this submodel, which dictate whether the Correlation ID or the Translation Route mechanism is used to transfer calls to the VRU. Most NICs (actually, most PSTN networks) are not capable of transferring a call to a particular destination directory number and carrying an arbitrary Correlation ID along with it, which the destination device can pass back to ICM in order to make the Correlation ID transfer mechanism function properly. For most NICs, therefore, the Translation Route mechanism has to be used. There are a few exceptions to this rule, however, in which case the CorrelationID mechanism can be used. The NICs which are capable of transmitting Correlation ID include: CRSP, SS7IN, and TIM. However, as this also depends on the PSTN devices which connect behind the NIC, check with the PSTN carrier whether the Correlation ID can be passed through to the destination. If the NIC is capable of transmitting Correlation ID, the incoming Dialed Numbers must all be associated with a Customer Instance which is associated with a Type 7 NetworkVRU. The Type 7 NetworkVRU must contain labels which are associated to the NIC routing client, and all the VRU Scripts must also be associated with that same Type 7 NetworkVRU. The peripherals need not be associated with any NetworkVRU. Though it is not always necessary, as a best practice the ICM routing script should always execute a SendToVRU node prior to the first RunExternalScript node. If the NIC is not capable of transmitting Correlation ID (the usual and safe case), then the incoming Dialed Numbers must all be associated with a Customer Instance which is not associated with any NetworkVRU. The CVP peripherals must, however, be associated with a NetworkVRU of Type 8, and all the VRU Scripts must also be associated with that same Type 8 NetworkVRU. In this case it is always necessary to insert a TranslationRouteToVRU node in the routing script prior to the first
9-6
OL-8408-02
Chapter 9
Interacting with ICM Hosted Implementations
RunExternalScript node. If the call is going to the VRU leg because it is being queued, generally the TranslationRouteToVRU node should appear after the Queue node. In that way an unnecessary delivery and removal from CVP can be avoided when the requested agent is already available.
Model #4b. IVR/Queuing via ICM with NIC-controlled pre-routing

This submodel assumes a less capable NIC. That is, the NIC is capable of delivering the call only once, whether to a VRU or to an agent, but once the call is there the NIC cannot be instructed to retrieve the call and re-deliver it somewhere else. In these cases, CVP can take control of the switching responsibilities for the call. From the ICM perspective, this process is known as a handoff. Calls which fit this particular submodel must use the Translation Route mechanism to transfer calls to the VRU. There is no way to implement a handoff using the Correlation ID mechanism. To implement this, the incoming Dialed Numbers must all be associated with a Customer Instance which is associated with a Type 7 NetworkVRU. The VRUs labels are associated with the CVP routing client (not the NIC!). The CVP peripherals must be associated with a NetworkVRU of Type 2, but all the VRU Scripts must be associated with the Type 7 NetworkVRU. In this case, it is always necessary to insert a TranslationRouteToVRU node in the routing script, followed by SendToVRU node, prior to the first RunExternalScript node. If the call is going to the VRU leg because it is being queued, generally these two nodes should appear after the Queue node. In that way an unnecessary delivery and removal from CVP can be avoided if the requested agent is already available.
Note
Notice the two different VRU transfer nodes that are required. The first one transfers the call away from the NIC with a handoff and establishes CVP as a switch leg device for this call. Physically the call is delivered to an ingress gateway. The second transfer delivers the call to the VXML gateway and establishes CVP as the calls VRU device as well.
Hosted Implementations

About Hosted Implementations, page 9-7 How CVP Fits Into Hosted Environments, page 9-8 CVP Placement and Call Routing in a Hosted environment, page 9-9 NetworkVRU Type in a Hosted environment, page 9-10
About Hosted Implementations

Hosted implementations refer to those implementations which incorporate a two-level hierarchy of ICM systems. At the top level sits the Network Application Manager (NAM), and below it sits one or more Customer ICMs (CICMs). Both NAM and CICM are really complete ICMs in and of themselves, with a communication link between them known as INCRP. Each CICM acts in an isolated fashion (i.e., it is not aware of either the other CICMs, nor is it aware that the NAM is itself another ICM). It has no connection to the other CICMs, but its connection to the NAM is through a NIC: specifically, the INCRP NIC.
9-7
Chapter 9 Hosted Implementations
Traditionally, customers implement Hosted setups because they are service providers. They want to provide ICM contact center services to multiple customers of their own. Each customer is hosted on its own CICM, and the NAM is responsible for routing calls which are delivered to the service provider to the appropriate customers CICM. The individual customers run their own contact centers with their own ACDs connected to their own premise-based PGs, which are connected to their assigned service-provider-based CICMs. Thus, the service provider owns and hosts the NAM and all the CICMs, but all the ACDs are owned and hosted by the individual customers. The PGs for those ACDs are owned by the service provider, but located at the customers premise next to his ACDs. The service provider itself does not necessarily operate any ACDs of its own, but it could; those PGs could be connected to a CICM which is assigned to the service provider, or they could actually be connected to the NAM itself. In terms of ICM scripting, all incoming calls initially invoke an appropriate NAM routing script, whose primary responsibility would be to identify the appropriate target customer. The script then delegates control to a routing script which is running on that customers CICM. The CICM-based routing script could then select the appropriate ACD to which to deliver the call, and return the necessary translation route label to the NAM. The NAM would then instruct its routing client to deliver the call to the designated target ACD. If the CICM routing script determined that no ACD could currently take the call, or that it could not yet identify which ACD should take the call, it could ask the NAM to place the call into queue at a Service Control VRU. The CICM routing script could then issue NetworkVRU Script requests via the NAM to that VRU until a routing decision could be made. In practice, however, the NAM/CICM architecture is flexible enough to enable a number of other possibilities. Many Hosted customers use this topology simply as a way to get more calls or more PGs through their ICM setup. Others use CICMs not for customer contact centers, but for outsourcers. In such cases, the NAM handles perhaps the same number of calls as the CICM, and the CICM machines themselves might be physically located quite far away from the NAM. Also, the NAM/CICM architecture was designed at a time when all contact centers ran on TDM-based ACDs. The addition of VoIP routing and Cisco CallManager-based ACDs (i.e., IPCC) with direct agent routing made matters considerably more complicated.
How CVP Fits Into Hosted Environments

When CVP is involved, it is usually used as a self-service and/or queuing platform, connected to the NAM, and physically located within the service providers data center. Thus, it enables the traditional service provider not only to route calls to the appropriate customer-owned ACDs, but also to retain control of calls which are queued for those ACDs, and to provide either basic prompt and collect capability or full-blown self service applications to its customers. The latter case typically incorporates CVP VoiceXML Servers into the network. Depending on the customers needs, the service provider might host the VoiceXML Servers, or the customer might host them. Additionally, the service provider might write and own the self-service application, or the customer might write and own them. Allowing the customer to own or host the VoiceXML Servers is a convenient solution when the self-service application needs to reference back-end services. It allows the customer to keep control of that interaction within his own enterprise network, while transmitting only VoiceXML over HTTP to the service providers VXML Gateway.
9-8
OL-8408-02
Chapter 9
Interacting with ICM Hosted Implementations
In many Hosted environments, particularly when the service provider is itself a PSTN carrier, all the actual call routing occurs via an ICM NIC. In that sense, these deployments are very much like Deployment Model #4, IVR/Queuing via ICM with NIC-controlled routing. The same situation applies if a PGW is being used to route calls, using (typically) the ICM SS7 NIC. However, quite often the service provider does not have a NIC interface at all, and all calls arrive via TDM interfaces such as T3 or E3. In those cases, CVP is used as the switch leg as well as the VRU leg. This situation is similar to Model #3a, DTMF Menu, Prompt and Collect, or to Model #3b, ASR/TTS and/or complex IVR application.
CVP Placement and Call Routing in a Hosted environment

As described above, if CVP is used in its traditional way as a true Network VRU, it is usually connected at the NAM. However, various requirements might cause CVP to be placed at the CICM level instead or in addition. In considering where to place CVP components, the following constraints are involved:
If CVP is placed at the NAM and CVP handles both the switch leg and the VRU leg, the Correlation ID transfer mechanism can be used. The SendToVRU node might be executed by either the NAM or the CICM routing script (the RunExternalScript nodes should also be in the same script which executed the SendToVRU). If CVP is placed at the NAM and a NIC handles the switch leg while CVP handles the VRU leg, either the Correlation ID transfer mechanism or the Translation Route transfer mechanism can be used, depending on the capabilities of the NIC (see Model #4a. IVR/Queuing via ICM with NIC-controlled routing, above).
If Correlation ID transfers are used, then the SendToVRU node might be contained in either the
NAM or the CICM routing script (the RunExternalScript nodes should also be in the same script which executed the SendToVRU).
If Translation Route transfers are used, then the TranslationRouteToVRU node, together with
all RunExternalScript nodes must be in the NAM routing script. The implication here is that the call is queued (or treated with prompt and collect) before the particular CICM is selected. This configuration does not make much sense for queuing, but it could be useful for service providers who want to offer initial prompt and collect before delegating control to the CICM.
9-9
Chapter 9 Hosted Implementations
If CVP is placed at the CICM and a NIC handles the switch leg while CVP handles the VRU leg, only the Translation Route transfer method can be used. The TranslationRouteToVRU node, together with all RunExternalScript nodes must be in the CICM routing script.
Adding Cisco CallManager Originated Calls or ACD Initiated Calls to the mix brings additional constraints. Both of these devices are considered ACDs from the ICMs perspective, and most likely are connected at the CICM level. Assuming these are new calls (as opposed to continuations of existing calls), the route request will come from the ACD, and the resulting label will be returned to the ACD. Neither Cisco CallManager nor any ACD is capable of transmitting Correlation ID upon transfer; only the Translation Route transfer method can be used. This further implies that the transfer destination (e.g., CVP) must also be connected at the CICM level, not the NAM level. Now consider what happens if these calls are not new, but continuations of existing calls. In other words, these calls are attempts to transfer an existing inbound caller from one agent to another agent. Some customers will want such transfers to be blind network transfers (i.e., the first agent drops off and the caller is delivered to a second agent, or queued for a second agent), or warm consultative transfers (i.e., the caller goes on hold while the first agent speaks to a second agent, or waits in queue for a second agent, and eventually hangs up, leaving the caller talking to the second agent).
Blind network transfers. Whether or not the original call was introduced to the NAM via a NIC or CVP switch leg, the transfer label will be passed from the CICM to the NAM to the original switch leg device. We consider two sub-cases.
If the switch leg device is CVP or a NIC which can handle Correlation ID, the Correlation ID
transfer mechanism can be used. The SendToVRU node and all RunExternalScript nodes will be incorporated in the CICM routing script. The CVP VRU leg can be connected to the NAM. This combination blind transfer with Correlation ID transfer is ideal for CVP and should be employed if at all possible.
If the switch leg device is a NIC which cannot handle Correlation ID, then the Translation Route
transfer method must be used, which further implies that the CVP VRU leg device must be connected to the CICM. This is very important: in these cases, the customer might have to deploy additional dedicated CVP Call Servers at the CICM level, since the NAM-level CVP Call Servers cannot be used.
Warm consultative transfers. Note that CVP only helps with warm consultative transfers in the case of IPCC agents transferring the call to other IPCC agents where CVP owns the initial switch leg for the inbound call. For TDM agents, the ACDs own mechanisms are used and does involve CVP. For IPCC Enterprise agents where the incoming call arrived through a NIC, ICMs Network Consultative Transfer facility might be used; that also would not involve CVP.
In that one supported case, where CVP owns the initial switch leg and the transfer is among IPCC agents, the Translation Route transfer method must be used, since the Cisco CallManager cannot handle Correlation ID transfers. This means again, that the CVP VRU leg device must be connected to the CICM. This is very important: in these cases, the customer might have to deploy additional dedicated CVP Call Servers at the CICM level, since the NAM-level CVP Call Servers cannot be used.
NetworkVRU Type in a Hosted environment

In Hosted environments, one must always consider two ICM systems: the NAM and the CICM in question. NetworkVRU Types will be configured differently in the NAM than in the CICM.
9-10
OL-8408-02
Chapter 9
Interacting with ICM Cisco CallManager and ACD Originated Calls - Deployment Models and Sizing Implications
The NAM, as described earlier, sees new calls arrive either from a NIC or from CVP, and is aware of the CVP VRU leg device. The NAMs NetworkVRU Types must be configured exactly as if it were an independent ICM operating with those devices. The fact that transfer labels sometimes come from a CICM can be effectively ignored for the purposes of configuring NetworkVRU Types. The CICM, on the other hand, sees new calls arrive from a NIC - the INCRP NIC to be specific. All the Dialed Numbers that can arrive from the NAM need to be associated with a Customer Instance which is associated with a Type 7 NetworkVRU. Associate that NetworkVRU with all VRU Scripts, and provide the same label as you need in the NAMs NetworkVRU definition, but with the INCRP NIC as its routing client. Other than that, no peripherals have NetworkVRUs configured.
Cisco CallManager and ACD Originated Calls - Deployment Models and Sizing Implications
The following discussion applies to all ACDs, as well as to all Cisco CallManager integrations which use CVP rather than IP-IVR for queuing. As far as CVP is concerned, these devices share the following characteristics:

They manage agents, and can therefore be destinations for transfers They can issue Route Requests, and can therefore be switch leg devices Though they can be switch leg devices, they cannot handle more than one transfer and they cannot handle CorrelationID
There are several reasons why a Cisco CallManager or ACD user would issue a Route Request:

To be connected to another agent in a particular skill group To reach a self service application To blind-transfer a call which the user had previously received to one of the above
In addition, a Cisco CallManager user in particular might be issuing a Route Request in order to:

Deliver a successful outbound call from the ICM Outbound dialer to a CVP-based self service application Warm-transfer a call which the user had previously received to either a particular skill group or a self service application
Each of the above calls invokes an ICM routing script. The script might or might not search for an available destination agent or service. If it finds an appropriate destination, it sends the corresponding label either back to the ACD, or, if blind-transferring an existing call, to the original callers switch leg device. If it needs to queue the call, or if the ultimate destination is intended to be a self service application rather than an agent or service, it sends a VRU translation route label either back to the ACD, or, if blind-transferring an existing call, to the original callers switch leg device. If the above sequence results in transferring the call to CVPs VRU leg device, there is a second transfer to deliver it to a VXML gateway. To ensure that these events take place, the following ICM configuration elements are required: For new calls from the ACD, or warm transfers of existing calls:
The CVP peripheral must be configured to be associated with a Type 2 NetworkVRU The dialed number which the ACD dialed must be associated with a Customer Instance which
is associated with a Type 7 NetworkVRU
9-11
Chapter 9 Using Third Party VRUs
The routing script which was invoked by the ACDs dialed number must contain a
TranslationRouteToVRU node to get the call to CVPs switch leg, followed by a SendToVRU node to get the call to the VXML gateway and CVPs VRU leg
All the VRU Scripts which are executed by that routing script must be associated with the Type
7 NetworkVRU For blind transfers of existing calls:

It does not matter to which NetworkVRU the CVP peripheral is associated The dialed number which the ACD dialed must be associated with a Customer Instance which
is associated with a Type 7 NetworkVRU

The routing script which was invoked by the ACDs dialed number must contain a SendToVRU
node to get the call to the VXML gateway and CVPs VRU leg
All the VRU Scripts which are executed by that routing script must be associated with the Type
7 NetworkVRU When ICM chooses an agent or ACD destination label for a call, it tries to find one which lists a routing client which can accept that label. For ACD or Cisco CallManager originated calls which are not blind transfers of existing calls, the only possible routing client is the ACD or Cisco CallManager. Once the call has been transferred to CVP, because of the handoff operation, the only possible routing client is the CVP switch leg. But in the case of blind transfers of existing calls, two routing clients are possible: the ACD or Cisco CallManager, or the switch leg device which delivered the original call. For calls which originate through CVP, you can prioritize CVP labels above ACD or Cisco CallManager labels by checking the box called Network Transfer Preferred in the ICM Setup screen for the CVP peripheral.
Using Third Party VRUs

A third party TDM VRUs can be used in any of three ways:

As the initial routing client (using the GED-125 Call Routing Interface) As a traditional VRU (using the GED-125 Call Routing Interface) As a Service Control VRU (using the GED-125 Service Control Interface)
In the first and second cases, the VRU acts exactly like an ACD, as described in Cisco CallManager and ACD Originated Calls - Deployment Models and Sizing Implications, page 9-11. Like an ACD, it can be a destination for calls which arrive from another source. Calls can even be translation routed to such devices in order to carry call context information. (This operation is known as a traditional translation route, not a TranslationRouteToVRU.) Also like an ACD, it can issue its own Route Requests, and invoke routing scripts to transfer the call to subsequent destinations or even to CVP for self service operations. Such transfers almost always use the translation route transfer mechanism. In the third case, the VRU takes the place of either CVPs switch leg or CVPs VRU leg, or it can even take the place of CVP entirely. Such deployments are beyond the scope of this document.
9-12
OL-8408-02
C H A P T E R
10
Cisco CallManager Originated Calls Deployment Models and Sizing Implications

This chapter covers the following topics:

Why these Cisco CallManager Originated Calls Are Different, page 10-1 Call Flows (customer), page 10-2 Call Flows (protocol), page 10-3 Deployment Implications, page 10-6
Why these Cisco CallManager Originated Calls Are Different

A Cisco CallManager-originated call is any call which is first introduced into the ICM system by dialing a Cisco CallManager route point that is associated with the JTAPI interface into ICM. Such calls initiate an ICM routing script which can be used to place the caller into queue or into a self service application, select an available agent, invoke App Gateway transactions, and so forth. A call invoked through the JTAPI interface to ICM is a typical postroute request: it provides a dialed number, ANI, variables, etc., and returns a label. Cisco CallManager then delivers the call to the destination specified by the returned label. As with other ACD postroute requests, the exchange ends there. ICM has no ability to send a subsequent label to that Cisco CallManager, unless Cisco CallManager issues another postroute request. This limitation is the first difference between Cisco CallManager-originated calls and calls which originate through a CVP ingress gateway. CVP can continue to route and re-route the call as many times as necessary. For this reason, when calls are originated from Cisco CallManager, it is important to hand off routing client responsibilities to CVP as soon as possible. The second difference has to do with how calls are transferred to a VRU. ACD routing clients such as Cisco CallManager might only be transferred using a TranslationRouteToVRU label. When CVP is the routing client, it can handle translation route labels as well as the CorrelationID labels which are generated by SendToVRU nodes. The next sections provide more details on these differences.
10-1
Chapter 10 Call Flows (customer)
Cisco CallManager Originated Calls - Deployment Models and Sizing Implications
Call Flows (customer)

The following types of calls are Cisco CallManager-originated calls, and must be treated differently than CVP-originated calls:

ICM Outbound with Transfer to IVR, page 10-2 Internal Help Desk, page 10-2 Warm Consultative Transfer, page 10-2
ICM Outbound with Transfer to IVR

The IPCC Outbound Dialer introduces an outbound call by impersonating an SCCP phone and asking Cisco CallManager to place the outbound call. When it detects that a person has answered, it transfers the call to an IPCC destination, taking itself out of the loop. If the customer requirement is to provide a CVP-based message or self service application to the callee, then the call is transferred to CVP using a Cisco CallManager route point. This fits the definition of a Cisco CallManager-originated call.
Internal Help Desk

Enterprises that place IP phones on employees desks often want to provide those employees with the capability to call into a self-service application. An example might be an application which allows employees to sign up for health benefits. Or, the employee might actually be trying to reach an agent, such as the IT HelpDesk, and ends up waiting in queue. Both of these scenarios result in Cisco CallManager-originated calls to CVP. We will also discuss scenarios where the internal caller is dialing into a self service application which is hosted on a VoiceXML Server which is deployed using Model #1, Standalone Self Service. No ICM is involved in this scenario, but it still qualifies as a Cisco CallManager-originated call.
Warm Consultative Transfer

In a typical contact center call flow, most companies want to provide their agents with the ability to transfer callers to a second agent who might or might not currently be available. There are two ways to do this: blind transfer and warm transfer. In a blind transfer, the agent dials a number and hangs up; the caller then gets connected to the second agent, or placed in queue if necessary. There is no Cisco CallManager-originated call involved in this type of transfer. In a warm transfer, the agent dials a number and is connected to the second agent, while the caller is placed on hold. The two agents can talk, then they can conference in the caller, and the first agent can then drop off. If the second agent is not available, it is the first agent who is placed into queue, not the caller. All of this processing can take place without involving CVP, except if the first agent needs to queue. In that case, the first agents call must be transferred to CVP, creating a Cisco CallManager-originated call.
10-2
OL-8408-02
Chapter 10
Cisco CallManager Originated Calls - Deployment Models and Sizing Implications Call Flows (protocol)
Call Flows (protocol)

We will now present the protocol-level call flow for Cisco CallManager-originated calls under each relevant deployment mode:

Model #1, Standalone Self Service, page 10-3 Model #2, CVP Call Control, page 10-3 Model #3a, CVP Call Control with Queue and Collect, page 10-4 Model #3b, CVP Call Control with Queue and Self Service, page 10-6
Note
The Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service, is not discussed here since there is no NIC involved in Cisco CallManager-originated calls.
Model #1, Standalone Self Service

Model #1 does not involve ICM. It arises when a Cisco CallManager user dials a directory number which connects him to a CVP VXML gateway and invokes a CVP VoiceXML Server application. The VXML gateway is configured in Cisco CallManager as an H.323 Gateway device.
1. 2. 3. 4. 5. 6. 7.
Caller dials a route pattern Cisco CallManager directs the call to the VXML gateway VXML gateway invokes a voice browser session based on the configured CVP self service application The CVP self service application makes an HTTP request to VoiceXML Server VoiceXML Server starts a self service application VoiceXML Server and VXML gateway exchange HTTP requests and VXML responses Caller hangs up.
Note
The script must not execute a Transfer node, unless it is to a TDM destination. Transfers to an IP destination will result in an IP-to-IP call, which is not supported.
Model #2, CVP Call Control

Model #2 has no VRU leg. It is all switching. Therefore, Cisco CallManager-originated calls will always be delivered directly to targets, or rejected. No queuing or self service are involved. We assume here that the call is truly originating from Cisco CallManager. This excludes calls which originally arrived through a CVP ingress gateway and were transferred to Cisco CallManager, and are now being transferred again. Such situations are rare, because Cisco CallManager can usually handle those transfers itself. There are exceptions however, such as when the target is a non-Cisco CallManager ACD but that situation will not be covered here. The following items must be configured for this flow to work:

Cisco CallManager route point which invokes an ICM script CVP is a Type 2 NetworkVRU
10-3
Chapter 10 Call Flows (protocol)
VRU translation routes to CVP Translation route DNISs configured in CVP Call Server CVP Call Server configured as H.323 gateway in Cisco CallManager Translation route DNISs configured in Cisco CallManager to request destination from gatekeeper H.323 gatekeeper trunk configured in Cisco CallManager with MTP enabled
1. 2. 3. 4. 5. 6. 7. 8. 9.
Caller dials a route point ICM invokes a routing script The routing script encounters a TranslationRouteToVRU node, to transfer the call to CVP; CVP is configured as a Type 2 NetworkVRU ICM returns the translation route label to Cisco CallManager Cisco CallManager consults gatekeeper, gets address of CVP Call Server Cisco CallManager connects the call to the CVP Call Server Cisco CallManager briefly establishes a g.711 media connection between the caller and the CVP Voice Browser The routing script encounters a Select or Label node, and selects a target label ICM returns the target label to CVP Call Server (not to the device which issued the route request)
10. CVP Call Server consults the gatekeeper for the address of the target device 11. CVP Call Server communicates via H.323 with target device and instructs Cisco CallManager to
establish a media stream to it, removing the CVP Call Servers media stream Now consider what happens if the target device issues another route request to ICM. This part would not be possible without the initial TranslationRouteToVRU shown above in step 3.
12. ICM invokes a new routing script 13. The routing script encounters a Select or Label node, and selects a target label 14. ICM returns the target label to CVP Call Server (not to the device which issued the route request) 15. CVP Call Server consults the gatekeeper for the address of the target device 16. CVP Call Server communicates via H.323 with target device and instructs Cisco CallManager to
establish a media stream to the device.
Model #3a, CVP Call Control with Queue and Collect

Model #3a involves both call switching and VRU activity. It differs from Model #2 therefore, in that calls must be transferred to the CVP VXML gateway after they are transferred to the CVP switch leg. Queuing is possible in this model, as is basic prompt and collect activity. The following items must be configured for this flow to work:

Cisco CallManager route point which invokes an ICM script CVP is a Type 2 NetworkVRU VRU translation routes to CVP Translation route DNISs configured in CVP Call Server Above route point configured in ICM as a DN with a Type 7 NetworkVRU
10-4
OL-8408-02
Chapter 10
Cisco CallManager Originated Calls - Deployment Models and Sizing Implications Call Flows (protocol)
Above NetworkVRU has labels for CVP switch leg routing client Above NetworkVRU labels configured in gatekeeper to point to VXML gateways CVP Call Server configured as H.323 gateway in Cisco CallManager Translation route DNISs configured in Cisco CallManager to request destination from gatekeeper H.323 gatekeeper trunk configured in Cisco CallManager with MTP enabled
1. 2. 3. 4. 5. 6. 7. 8.
Caller dials a route point ICM invokes a routing script The routing script encounters a TranslationRouteToVRU node, to transfer the call to CVP Call Server switch leg ICM returns the translation route label to Cisco CallManager Cisco CallManager consults gatekeeper, gets address of CVP Call Server Cisco CallManager connects the call to the CVP Call Server Cisco CallManager briefly establishes a g.711 media connection between the caller and the CVP Voice Browser The routing script encounters a Queue node
Now assume that the call needs to be queued:

9.
The routing script encounters a SendToVRU node
10. ICM sends a VRU transfer label with Correlation ID to CVP Call Server switch leg 11. CVP Call Server consults gatekeeper, gets address of a VXML gateway 12. CVP Call Server communicates via H.323 with VXML gateway and instructs Cisco CallManager to
establish a media stream to it, removing the CVP Call Servers media stream.
13. The routing script executes one or more CVP Microapps via RunExternalScript nodes, plays media
files, requests DTMF input, etc.(See protocol level call flow for Model #3a for details in Chapter 3, Deployment Models.)
14. While CVP Microapps are in progress, a target agent becomes available to take the call. 15. ICM determines a label for the target agent 16. ICM returns the target label to CVP Call Server 17. CVP Call Server consults the gatekeeper for the address of the target device 18. CVP Call Server communicates via H.323 with target device and instructs Cisco CallManager to
establish a media stream to it, removing the VXML gateways media stream. If the target device later issues another route request to ICM, the call flows again exactly as above. The call must again be translation routed to the CVP switch leg Type 2 NetworkVRU, then Correlation ID transferred via SendToVRU to the CVP VXML gateway to create the VRU leg. Microapps might be executed, and eventually the new target label is delivered to the CVP switch leg, which transfers the call to that target.
10-5
Chapter 10 Deployment Implications
Model #3b, CVP Call Control with Queue and Self Service
Model #3b does not differ significantly from Model #3a, CVP Call Control with Queue and Collect at least as far as call control and signalling. The only departure is that the CVP Microapps which are executed might include subdialog requests to the CVP VoiceXML Server as well. Of course, self service applications are not likely to be invoked during the period when the call is queued. Any agent selection nodes or queue nodes in the ICM routing script would therefore likely be postponed until after the self service application has completed, and control has returned to the ICM routing script.
Deployment Implications
Here is a sampling of items to be aware of when incorporating Cisco CallManager-originated calls into the deployment:

ICM Configuration, page 10-6 Hosted Implementations, page 10-6 Cisco CallManager Configuration, page 10-7 Network Level, page 10-7 Sizing, page 10-7
ICM Configuration
If you want CVP to be able to be involved in subsequent call control, always translation route the call to CVP, as a Type 2 NetworkVRU, before delivering the call to its next destination. This creates a handoff, putting CVP in charge of subsequent transfers for this call, since Cisco CallManager is not able to receive any further labels. If you want to perform any queuing treatment, prompt and collect, or self service applications, always follow the above translation route with a SendToVRU node. SendToVRU can sometimes be invoked implicitly by a Queue node or a RunExtScript node, but you should not rely on that always working. Always include an actual SendToVRU node.
Note
This and all flows in this document assume ICM 7.0(0) or later.) See the assumptions in the above protocol level call flows for additional configuration requirements, Call Flows (protocol), page 10-3.
Hosted Implementations
Translation routes sent by one ICM router must be received by a peripheral which is connected to the same ICM router. This means you can only translation route a call from a CICM level Cisco CallManager into CVP if CVP is also located at the CICM level. In Hosted environments this means you need to provision CVP Call Servers at the CICM level, even if you already have other CVP Call Servers at the NAM level. VXML gateways and gatekeepers can of course be shared. This subject is covered in great detail in Chapter 9, Interacting with ICM.
10-6
OL-8408-02
Chapter 10
Cisco CallManager Originated Calls - Deployment Models and Sizing Implications Deployment Implications
Cisco CallManager Configuration

Cisco CallManager configuration includes:
Remember that the Cisco CallManager will be sending the call to a CVP Call Server, not to a gateway. However, the CVP Call Server must be configured in Cisco CallManager as an H.323 Gateway device. MTP does not need to be turned on for this device. Configure the gatekeeper as an H.323 Gatekeeper trunk device with MTP enabled. Configure the VRU Translation route DNISs to consult that gatekeeper for routing instructions. When configuring agent labels, it is important to remember which device is the routing client. For cases where the label will be returned directly to Cisco CallManager, the Cisco CallManager must be the routing client. For cases where the label will be sent to CVP, the labels must be associated with each of the CVP switch leg Call Servers.
Network Level
Codecs: either g.711 or g.729 might be used for the conversation between the callers IP phone and the VXML gateway. However, for the brief period when the media stream is connected to the CVP Call Server, g.711 must be used.
Sizing
Most customer implementations are not primarily designed for Cisco CallManager-originated calls. The main driver is usually incoming customer calls, though Cisco CallManager-originated calls are frequently a component, particularly in the case of warm transfer. It is easy to forget to size equipment with those calls considered.
CVP Call Servers

As with normal incoming calls, CVP Call Servers must be sized to handle two call legs when the call is either in queue or performing self service activity, and one leg once the call has been delivered to a destination. These rules apply for ICM Outbound as well as Internal Help Desk calls. For warm transfer scenarios, CVP resources are not used for the Cisco CallManager-originated portion of the call unless the first agent needs to go into queue. At that point two call legs are engaged, and once the first agent drops off, both legs are released. These legs are above and beyond those which are required for the original incoming call. Therefore it is important to consider what percentage of incoming calls will be warm-transferred and be queued during that process, and for how long. Those additional call legs need to be considered.
Gateways
Cisco CallManager-originated calls do not use ingress gateways at all. Calls are delivered directly from the Cisco CallManager to the CVP Call Server. They do however use VXML gateways whenever a VRU leg is in use. It is important to consider each Cisco CallManager-originated call which is either in queue or conducting self service activities as a call for the purposes of sizing VXML gateways.
10-7
Chapter 10 Deployment Implications
MTP Resources
The Cisco CallManagers must be sized and configured to allocate an MTP resource for every Internal Help Desk call, every ICM Outbound call which results in a transfer to CVP, and every warm transfer call which results in queuing of the first agent. If you follow the Cisco CallManager configuration guidelines presented in this chapter, it is no longer necessary to allocate MTP resources on a per-CVP Call Server basis, as it used to be.
10-8
OL-8408-02
C H A P T E R
11
Using the GKTMP NIC


The Cisco Gatekeeper External Interface, page 11-1 The ICM GKTMP NIC, page 11-1 Typical Applications of GKTMP with CVP, page 11-2
The Cisco Gatekeeper External Interface

The Cisco H.323 Gatekeeper provides an external interface which uses Gatekeeper Transaction Message Protocol (GKTMP) to handoff the processing of RAS requests to external applications. This allows organizations to supplement the onboard capabilities of the gatekeeper and provide support for externally managed dial plans and intelligent call routing in an H.323 voice network. GKTMP is based on RAS and provides a set of ASCII request/response messages that can be used to exchange information between the IOS Gatekeeper and the external application over a TCP connection. For more information, consult the Cisco Gatekeeper External Interface Reference: http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_programming_referen ce_guide_book09186a0080380f4b.html
The ICM GKTMP NIC

Using its GKTMP NIC the ICM can function as a GKTMP server for the gatekeeper, processing GKTMP request messages as route requests and running routing scripts in the normal way. The RAS sourceInfo Alias and destinationInfo Alias are made available to the ICM script as the Calling Line ID and Dialed Number respectively, the latter typically being used for script selection by the ICM Router. The ICM script might perform many different functions including database or back-end system access and finally sends a label back to the NIC for return to the gatekeeper and ultimately back to the requesting endpoint as the modified destinationInfo Alias. The ICM script can also modify the sourceInfo Alias. However, not all requesting endpoints utilize the translated sourceInfo Alias returned; IOS gateways make use of this whereas the CVP Call Server and Cisco CallManager both ignore it. To force the gatekeeper to reject the Admission-Request (ARQ) and return an Admission-Reject (ARJ) to the requesting endpoint the ICM script can return a BUSY label, optionally with an additional reason code, for example DESTINATION_UNKNOWN. For a complete description of the ICM GKTMP NIC and how it is configured, consult the GKTMP NIC System Management Guide Supplement, available from your Cisco Systems Engineer (SE).
11-1
Chapter 11 Typical Applications of GKTMP with CVP
Using the GKTMP NIC
Typical Applications of GKTMP with CVP

The GKTMP NIC can be used with CVP in both Pre-Routing and Post-Routing call scenarios. The former is used to process the Admission-Request from the ingress gateway before the call is routed to the CVP Call Server and answered, the latter for transfers being performed by the CVP Call Server.
Intelligent rejection before the call is answered by CVP When an H.225 SETUP is received by the CVP Call Server it answers the call, returning a CONNECT message immediately. Sometimes it is required to make a routing decision before delivering the call to CVP and it being answered. One example is the use of look-ahead routing in which the ICM script determines the availability and leachability of other ICM peripherals that will be required for the overall call scenario once the call has been delivered to CVP. Using the GKTMP NIC it is possible to reject calls intelligently for alternate routing via the TDM network rather than answer them and not have the resources to handle them subsequently.
Selection of CVP Call Server based on H.323 call information Occasionally the gatekeeper static configuration is not sufficient for selection of the most appropriate CVP Call Server to handle an incoming call. For example, the routing decision might need to be based on the calling line ID or source signalling address.
Manipulation of the calling line ID Modification of the sourceInfo Alias is sometimes useful in order to overload the calling line ID with additional information required by the destination endpoint where translation routing is not possible.
ICM-based dial plan ICM implements a centralized H.323 voice network dial plan, reducing the need for dial plan configuration on individual gatekeepers. This is appropriate only if the dial plan is large, complex, dynamic and difficult to maintain across multiple gatekeepers.
Time of day routing Allows the gatekeeper routing to be supplemented with date and time based decisions, possibly to handle time dependent resource availability.
Back-end system and database queries ICM database lookup or application gateway capabilities data from external systems can be incorporated into routing decisions.
Filtering calls that might be sent immediately to an available destination and bypass CVP While this approach might be seen as a way to avoid using CVP Call Server resources, it limits the functionality available, for example, there can be no intelligent requery for alternative destinations on ring-no-answer nor will it allow the call to be taken back to CVP for subsequent call treatment and transfers.
Pre-Routing with context passing to CVP Used if call context collected during the Pre-Route phase of the call needs to be passed to CVP rather than simply performing a standalone routing request via the GKTMP NIC. In this example, the CVP Call Server must be configured as a Type 2 VRU in order that the call can be translation routed to it and still perform a subsequent transfer. (Note: this capability has limitations in ICM versions prior to 7.0(0) see Deployment Implications, page 11-4.)
11-2
OL-8408-02
Chapter 11
Using the GKTMP NIC Typical Applications of GKTMP with CVP

Fundamentally, GKTMP allows an ICM routing script to provide additional external business rules that are called by the gatekeeper to select an alternative destination label or target IP address for a call, given a dialed number or label. However, the protocol level call flow differs depending on the purpose for which the GKTMP request is being used. We consider the following uses of GKTMP separately:
Pre-Routing of incoming calls, call context passing not required, page 11-3 In this mode of operation, calls arriving at an ingress gateway make a request to ICM to select either a particular CVP Call Server target or a non-CVP target. When a CVP Call Server is selected, the call is delivered to CVP as a completely new call, with no link to the ICM script involved in the GKTMP-based routing step.
Pre-Routing of incoming calls, call context passing is required, page 11-4 Here, calls which arrive at an ingress gateway make a request to ICM via the GKTMP NIC before being delivered to a particular CVP Call Server target. Any information obtained by this initial ICM routing script is preserved and made available to the ICM script as processing resumes when the call is delivered to the CVP Call Server.
Routing of post-ICM calls, page 11-4 This is to modify the routing of calls that are being transferred to a destination label returned to CVP by an ICM routing script. No information obtained by the previous routing script is available to the new script invoked by the GKTMP request, which functions in a purely standalone manner.
Pre-Routing of incoming calls, call context passing not required

1. 2. 3. 4. 5.
Call arrives at the ingress gateway The ingress gateway requests the gatekeeper to identify a target CVP Call Server (or other IP destination) The gatekeeper issues a GKTMP Request ARQ to ICM via the GKTMP NIC ICM starts a routing script based on dialed number, ANI, time of day, etc. The ICM routing script might return either a Response ARQ or a Response ACF to the gatekeeper. In the former case, the ICM returns modified information in the response and the gatekeeper resumes ARQ processing to select the IP endpoint. This approach is adopted if the ICM is returning a destination label only and not selecting the required destination IP endpoint address(es) explicitly. In the latter case, the ICM completes the processing of the request, returning modified information and selected target IP endpoints. In this case the gatekeeper regards the request as completed, does no further processing of the request and returns the ACF to the ARQing endpoint. The ICM routing script ends here. The gatekeeper returns the selected IP address to the ingress gateway If the target is a non-CVP device, the ingress gateway sets up a VoIP call to that target. If the target is a CVP Call Server, the ingress gateway sets up a new call to it. The CVP Call Server sends a New Call message to ICM
6. 7. 8. 9.
10. ICM starts an independent routing script to handle the incoming call 11. Normal call flow continues. Transfer to VRU leg, Transfer to agent, as well as subsequent blind
Network VRU Transfers to secondary agents or return to queue are fully supported.
11-3
Using the GKTMP NIC
Pre-Routing of incoming calls, call context passing is required

1. 2. 3. 4. 5. 6. 7. 8. 9.
Call arrives at the ingress gateway The ingress gateway requests the gatekeeper to identify a target CVP Call Server (or other IP destination) The gatekeeper issues a GKTMP Request ARQ to ICM via the GKTMP NIC ICM starts a routing script based on dialed number, ANI, time of day, etc. The ICM routing script executes a TranslationRouteToVRU to select a target CVP Call Server ICM returns the selected translation route label (and optionally the destination endpoint IP address) in the GKTMP Response ARQ/ACF via the GKTMP NIC. The gatekeeper returns the selected IP address to the ingress gateway The ingress gateway sets up a new call to the selected CVP Call Server The CVP Call Server sends a RequestInstruction message to ICM
10. The ICM routing script resumes after the TranslationRouteToVRU node 11. Normal call flow continues: Transfer to VRU leg, Transfer to agent, as well as subsequent blind
Network VRU Transfers to secondary agents or return to queue are fully supported. (See Deployment Implications, page 11-4 for pre-ICM 7.0(0) caveats.)
Routing of post-ICM calls

1. 2. 3. 4. 5. 6. 7. 8. 9.
ICM selects a target agent or other destination label. The ICM routing script ends here. ICM returns the selected label to the CVP Call Server The CVP Call Server requests the gatekeeper for the endpoint IP address associated with that label The gatekeeper issues a GKTMP Request ARQ to ICM via the GKTMP NIC ICM starts a completely independent routing script based on the selected label, ANI, time of day, etc. The ICM routing script selects an appropriate target for the call ICM returns the selected label (and optionally the destination endpoint IP address) in the GKTMP Response ARQ/ACF response via the GKTMP NIC. The ICM routing script ends here. The gatekeeper returns the selected endpoint IP address to the CVP Call Server The CVP Call Server performs and Empty Capability Set transfer, communicating with the ingress gateway and the transfer destination endpoint to establish a VoIP call between them.
Deployment Implications
GKTMP is a simple request/response protocol. From an ICM perspective, this means that the GKTMP NIC cannot perform any call control other than returning a single label and/or endpoint IP address. Third party call control through the GKTMP NIC is not possible once that single destination has been returned. However, it is possible when call control responsibilities are handed off to CVP. The discussion below covers the implications of this for each of the three types of call flow described above:

Pre-Routing of incoming calls, call context passing not required, page 11-5 Pre-Routing of incoming calls, call context passing is required, page 11-5
11-4
OL-8408-02
Chapter 11
Using the GKTMP NIC Typical Applications of GKTMP with CVP
Routing of post-ICM calls, page 11-5 Other implications, page 11-6
Pre-Routing of incoming calls, call context passing not required

Two ICM routing scripts are required for this option. The first script identifies the initial target for the incoming call; the second script is the normal routing script for call handling at CVP which is assumed elsewhere in this guide. The transfer from one to the other is via a plain label; it is not a translation route or a VRU leg transfer. The GKTMP-initiated script cannot perform any queuing or other VRU activity; it can only modify the Admission-Request content and optionally return an endpoint IP address. In the case where the Pre-Routing script returns a label which is associated with an endpoint other than a CVP Call Server, no further call control is possible (unless the end point is an ACD or VRU with its own post-routing interface into ICM and its own ability to perform call control operations).
Pre-Routing of incoming calls, call context passing is required

With this option, the GKTMP-initiated and CVP-initiated routing scripts are one and the same. A TranslationRouteToVRU node must be used to move the call to a Type 2 CVP NetworkVRU. This node must precede any Queue node if the customer needs the ability to perform any subsequent agent-to-agent transfers, even if an appropriate agent is already available. This might seem like an extraneous transfer, but it is necessary in order to force call control handoff to CVP. Following the TranslationRouteToVRU and prior to executing any RunExternalScript nodes, a second VRU transfer is required using a SendToVRU node to establish the VRU call leg to the VXML gateway. With ICM implementations prior to 7.0(0), this capability is severely limited, and usually not recommended. Specifically, there are two restrictions:
Once ICM delivers the call to an agent, subsequent agent to agent transfers are not supported via blind Network VRU Transfers with queuing. Agent to agent transfers can still be performed using the ACDs or IPCCs own call switching capabilities, but the Type 2 CVP Network VRU can play no further part in the call. The second transfer to CVPs VRU leg cannot be done with a SendToVRU node. However, two workarounds are possible, each with its own limitations:
Use a second TranslationRouteToVRU node instead of the SendToVRU step. This however
requires that the destination be configured as a Type 8 NetworkVRU, which means it must be a different physical CVP Call Server to the Type 2 CVP platform. This leads to a requirement for extra hardware which might not otherwise be needed based on capacity expectations alone.
Do not do the transfer to CVPs VRU leg at all. This leaves the media terminated at the CVP
Call Server and does not use a VXML gateway at all. It allows no support for ASR/TTS or VoiceXML Server applications, and it requires G.711 RTP between the ingress gateway and the CVP Call Server. This is a deprecated call flow and might soon be declared end-of-life.
Routing of post-ICM calls

Two completely independent ICM routing scripts are used in this scenario. The only connection between the two is that the label returned by the first routing script is used as a Dialed Number which the gatekeeper uses to invoke the second routing script. This is not a translation route or VRU leg transfer, and call context is not available to the second script other than what is included in the gatekeeper request itself.
11-5
Using the GKTMP NIC
Other implications
Note that inserting the GKTMP NIC into the call flow does result in additional route requests being processed by the ICM Router for each call processed in this way and additional call detail records will be written by the ICM Logger. Where possible, configure the GKTMP server triggers on the gatekeeper such that only the calls specifically requiring the additional routing functionality afforded by the GKTMP NIC generate a Request ARQ to the ICM.
11-6
OL-8408-02
C H A P T E R
12
Gateway Options
Cisco offers a large range of voice gateway models, to cover a large range of requirements. Many of these have been qualified for use with CVP, but not all. It is important to always check the latest CVP 3.1 Bill of Materials for the list of currently supported gateway models. This document can be found at: http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml Gateways are used in CVP for conversion of TDM to IP, and for executing VoiceXML instructions. The following sections help you determine which gateways to incorporate into your design. This chapter covers the following topics:

PSTN Gateway, page 12-1 VoiceXML Gateway with DTMF or ASR/TTS, page 12-2 VoiceXML & PSTN Gateway with DTMF or ASR/TTS, page 12-2 TDM Interfaces, page 12-2
PSTN Gateway
In this deployment, the voice gateway is used as the PSTN-to-H.323 voice gateway. The voice gateway is responsible for converting TDM speech to IP and for recognizing DTMF digits and converting them to H.245 signals. In a centralized CVP deployment, you can separate the VoiceXML functionality from the ingress gateway to provide a separate PSTN ingress layer. The separate PSTN layer and VoiceXML farm enables the deployment to support a large number of VoiceXML sessions and PSTN interfaces. For example, the Cisco AS5400XM can accept a DS3 connection, providing support for up to 648 DSOs. However, a gateway that is handling that many ingress calls cannot also support as many VoiceXML sessions. In such cases, the VoiceXML sessions should be offloaded to a separate farm of VXML-only gateways. In a distributed CVP deployment, gateways which reside at the branch office must be dual-use gateways. When the CVP Call Server receives a call from a branch-based ingress gateway, and is asked by the ICM to transfer that call to a VXML gateway, it must be careful to return the call to the same branch office in order to avoid establishing a media stream from one branch to another. It does this by always forcing the VRU leg to go back to the same gateway from which it received the call initially. (For more information, se the SetTransferLabel and SetExcludeIP VBAdmin commands in the CVP 3.1 Configuration and Administration Guide.)
12-1
Chapter 12 VoiceXML Gateway with DTMF or ASR/TTS
Gateway Options
Note
The AS5850eRSC and the Catalyst 6500 Communication Media Module (CMM) are recommended only for PSTN Gateway use. They are not designed to process VXML.
VoiceXML Gateway with DTMF or ASR/TTS

A standalone VoiceXML gateway is a voice gateway with no PSTN interfaces. The VoiceXML gateway allows customers to interact with the IOS VoiceXML Browser via DTMF tones or ASR/TTS. Because the gateway does not have PSTN interfaces, voice traffic is sent via Real-Time Transport Protocol (RTP) to the gateway, and DTMF tones are sent via out-of-band H.245 messages. A voice gateway deployment using VoiceXML with DTMF or ASR/TTS, but no PSTN, enables you to increase the scale of the deployment and support hundreds of VoiceXML sessions per voice gateway. In a centralized CVP Deployment, you could use a VoiceXML farm. For example, if you want to support 300 to 10,000 or more VoiceXML sessions, the recommended voice gateway is the Cisco AS5350XM. The standalone AS5350XM can support many DTMF or ASR/TTS VoiceXML sessions per voice gateway. In addition, Cisco recommends that you stack the AS5350XM gateways to support large VoiceXML IVR farms. In a distributed CVP Deployment, consider providing an extra layer of redundancy at the branch office. You can deploy a separate PSTN gateway and a VoiceXML gateway to provide an extra layer of redundancy. In addition, for a centralized Cisco CallManager deployment, you must provide support for Survivable Remote Site Telephony (SRST). The Cisco 3800, 3700, and 2800 Series routers are the best choice for the voice gateway because they support SRST.
VoiceXML & PSTN Gateway with DTMF or ASR/TTS

The most popular voice gateway is the combination VoiceXML and PSTN Interface Gateway. In addition, for a centralized Cisco CallManager deployment, you must provide support for Survivable Remote Site Telephony (SRST). The Cisco 3800, 3700, and 2800 Series routers are the best choice for the voice gateway because they support SRST.
TDM Interfaces
Cisco AS5400 Series Universal Gateways offer unparalleled capacity in only two rack units (2RUs) and provide universal port data, voice, and fax services on any port at any time. High density (up to one CT3), low power consumption (7.2 A at 48 VDC per CT3), and universal port digital signal processors (DSPs) make the Cisco AS5400 Series Universal Gateways ideal for many network deployment architectures, especially co-location environments and many points of presence (POPs). The Cisco AS5350 Universal Gateway is the only one-rack-unit (1RU) gateway that supports 2-, 4-, or 8-port T1/7-port E1 configurations and provides universal port data, voice, and fax services on any port at any time. The Cisco AS5350 Universal Gateway offers high performance and high reliability in a compact, modular design. This cost-effective platform is ideally suited for internet service providers (ISPs) and enterprise companies that require innovative universal services. The Cisco 2600, 2800, 3700, and 3800 Series Routers support the widest range of packet telephony-based voice interfaces and signaling protocols within the industry, providing connectivity support for more than 90 percent of the world's private branch exchanges (PBXs) and public switched
12-2
OL-8408-02
Chapter 12
Gateway Options TDM Interfaces
telephone network (PSTN) connection points. Signaling support includes T1/E1 Primary Rate Interface (PRI), T1 channel associated signaling (CAS), E1-R2, T1/E1 QSIG Protocol, T1 Feature Group D (FGD), Basic Rate Interface (BRI), foreign exchange office (FXO), E&M, and foreign exchange station (FXS). The Cisco 2600, 2800, 3700 and 3800 Series Routers can be configured to support from two to 540 voice channels. For the most current information about the various digital (T1/E1) and analog interfaces supported by the various voice gateways, refer to the latest product documentation available at the following sites:
Cisco 2600 Series http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis2600/
Cisco 2800 Series http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2800/
Cisco 3700Series http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3700/
Cisco 3800 Series http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/3800/
Cisco AS5300 http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/
Cisco AS5400HPX http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5400/
12-3
Chapter 12 TDM Interfaces
Gateway Options
12-4
OL-8408-02
C H A P T E R
13
Design Implications for VoiceXML Server

This chapter cover the following topics:

What is VoiceXML over HTTP?, page 13-1 Multilanguage Support, page 13-2 Differences in the Supported Web Application Servers, page 13-2 Where to Install CVP Studio, page 13-3
What is VoiceXML over HTTP?

Communication between VoiceXML server and the VoiceBrowser is based on request-response cycles using VoiceXML over HTTP. VoiceXML documents are linked together by using the Uniform Resource Identifiers (URI), a standardized technology to reference resources within a network. User input is carried out by web forms similar to HTML. Therefore, forms contain input fields which are edited by the user and sent back to a server. Resources for the Voice Browser are located on the VoiceXML server. These resources are VoiceXML files, digital audio, instructions for speech recognition (Grammars) and scripts. Every Communication process between the VoiceXML browser and Voice Application has to be initiated by the VoiceXML browser as a request to the VoiceXML server. For this purpose, VoiceXML files contain Grammars which specify expected words and phrases. A Link contains the URL which refers to the Voice application. The browser connects to that URL as soon as it recovers a match between spoken input and one of the grammars. So when gauging VoiceXML server performance, key aspects to consider are:
Network bandwidth between Web application server and the VoiceGateway and QOS. Refer to Bandwidth Provisioning and QoS Considerations, page 8-1 for more details.
Performance on the VoiceXML Server CVP Bill of Materials (BOM) requires the MCS-7845 as a VoiceXML server. Adequate performance is required on the server side to respond to VoiceXML over HTTP requests.
Use of pre-recorded Audio vs. Text to Speech Good Voice User Interface applications tend to use pre-recorded audio files wherever possible. Recorded audio sounds much better than TTS. Pre-recorded Audio file quality needs to be designed such that it does not impact download time and browser interpretation. Make recordings in 8-bit Mu law 8Khz format.
Audio File Caching
13-1
Chapter 13 Multilanguage Support
Make sure the Voice gateway is set to cache Audio content prevents delays in having to download files from the media source. Refer to the Section titled Gateway Prompt Caching Considerations for more details on Prompt Management on Supported Gateways
Use of Grammars A voice application, like any user-centric application, is prone to certain problems that might only be discovered through formal usability testing, or observation of the application in use. Poor speech recognition accuracy is one type of problem common to voice applications, and a problem most often caused by poor grammar implementation. When users mispronounce words or say things that the grammar designer does not expect, the recognizer cannot match their input against the grammar. Poorly designed grammars containing many difficult-to-distinguish entries also results in many misrecognized inputs leading to decreased performance on the VoiceXML server. Grammar tuning is the process of improving recognition accuracy by modifying a grammar based on an analysis of its performance.
Multilanguage Support
The IOS Voice Browser or the MRCP specification does not impose restrictions on support for Multiple Languages. However, there might be restrictions on the ASR/TTS server; check with your preferred ASR/TTS vendor on their support for your languages before preparing a multi-lingual application. Programatically, there is a method where you can dynamically change the ASR server value using a cisco property com.cisco.asr-server in the VoiceXML script. This property overrides any previous value set by the VoiceXML script.
Differences in the Supported Web Application Servers

From a very high level perspective, IBM WebSphere Application Server (www.ibm.com/websphere) is a complete J2EE application server environment complete with an Administration console and connection pooling. However, Tomcat (http://tomcat.apache.org/) is a simple and a basic environment with a Servlet Engine and a Java Server Pages engine only. The decision to use Tomcat or Websphere Application Server depends on the customers current enterprise infrastructure requirements. In many cases, Tomcat is more than sufficient, but if a customer already has WebSphere infrastructure and management capabilities, or has a preference for WebSphere in general, he should use it for CVP. Performance tests conducted on the web application server showed only slight variations in the Processor performance between the two Web Application Servers using metrics such as:

Impact of call volume Impact of application size Impact of Application complexity
Both Tomcat and Websphere Application server running CVP VoiceXML can support up 500 simultaneous calls per 7845 physical box.
13-2
OL-8408-02
Chapter 13
Design Implications for VoiceXML Server Where to Install CVP Studio
Where to Install CVP Studio

CVP Studio is an Integrated Development Environment (IDE). As in the case of any IDE, the studio needs to be installed in a setup that is conducive for development, such as workstations that are used for other software development or business analysis purposes. Since the CVP studio is Eclipse-based, many other development activities such as writing Java programs or building object models can be migrated to this tool so that developers/Analysts have one common utility for most of their development needs. For non-production systems, the CVP studio can be installed in conjunction with the CVP VoiceXML server. If the intent is to only test applications in a non load scenario, the co-resident configuration is acceptable.
13-3
Chapter 13 Where to Install CVP Studio
13-4
OL-8408-02
C H A P T E R
14
Media File Options


Deployment and Ongoing Management, page 14-1 Bandwidth Calculation for Prompt Retrieval, page 14-1 Best Practices for Prompt Management, page 14-2 Configuring Caching on IOS, page 14-2 Branch office implications, page 14-2
Deployment and Ongoing Management

Voice prompts can be stored in the following locations:
In flash memory on each local gateway In this way, gateways do not have to retrieve .wav files for prompts, so WAN bandwidth is not affected. However, if a prompt needs to change, you must change it on every gateway. On an HTTP media server In this way, each local gateway (if properly configured) can cache many or all prompts, depending on the number and size of the prompts.
Bandwidth Calculation for Prompt Retrieval

When prompts are stored on an HTTP media server, the refresh period for the prompts is defined on that server. The bandwidth consumed by prompts consists of the initial loading of the prompts at each gateway and of the periodic updates at the expiration of the refresh interval. As an example of determining the bandwidth consumed by prompts, assume that a deployment has 50 prompts with an average size of 50 kB (50,000 bytes) each. Also assume that the refresh period for the prompts is defined as 15 minutes (900 seconds) on the HTTP media server. The WAN bandwidth required for prompts in this deployment can be calculated as follows:
50 prompts 50,000 bytes 8 bits = 20,000,000 bits 20,000,000 bits / 900 seconds = 22.2 kbps per branch
14-1
Chapter 14 Best Practices for Prompt Management
Media File Options
Best Practices for Prompt Management

The following are best practices for managing prompts:
If the prompts are changing frequently, you can ensure that the prompts are current by configuring the HTTP client cache refresh rate to be 30 minutes. This setting allows the voice gateway to cache prompts that will expire after 30 minutes. Upon the next request the prompt will be downloaded and cached again. The HTTP client cache memory file represents the largest prompt file (in kilobytes) that can be cached. In general, divide prompts larger than 500 kB (about a minute in length) into smaller, more manageable pieces to facilitate loading and caching. For example, queue music could be a repetitive loop of a 30-second prompt. Because the prompts are streamed, the prompt are not cached unless the whole prompt is played. Therefore, make prompts a manageable size. If prompts are going to be retrieved from flash, specify prompt URLs in the form: flash:<filename>.wav.
Configuring Caching on IOS

The Cisco MRCP client uses an HTTP client, which is a part of Cisco IOS. The client fetches VoiceXML documents, audio files, and other file resources. To optimize the fetching of the HTTP client, set the cache configurations. For example, if a 1 MB audio file is being fetched, ensure the audio file is also cached. If there is not enough space configured on the router to hold the file, the HTTP client fetches the same audio file each time it is needed; this causes delays in processing. There are two key HTTP client cache configurations:

http client cache memory file size in kb 1 10,000 http client cache memory pool size in kb 1 10,000
Note
The upper range is the maximum space allowed for all cached files. The space available can not exceed 10 MB, otherwise subsequent files are not cached.
Branch office implications

In most cases, customers implementing CVP in Branch Office deployments expect a small footprint for hardware. In most scenarios, when a separate media server is not a preferred model, customers prefer deploying voice prompts on the gateway flash. Typical prompt sizes when recorded in G711 MuLaw format of average duration are about 10-15K in size. When sizing gateways for such implementations, size the FLASH memory by factoring in the number of prompts and their sizes and also room on which to store the IOS image.
14-2
OL-8408-02
C H A P T E R
15
Licensing
This chapter describes how licensing works in a CVP deployment, including how CVP components and ports are licensed. This chapter also presents some significant points about ICM and IOS licensing. The chapter contains the following topics:

CVP Licensing, page 15-1 Gateway Licensing, page 15-4
CVP Licensing
CVP licensing does not directly correlate to CVP sizing. In particular, while the number of ports you need to license bears some resemblance to the number of ports for which you sized, there is very little relationship between the number of servers you need to license and the number of physical servers you actually order. CVP licenses consist of port licenses and server licenses. Once you have determined these license requirements, you can add redundant port licenses and redundant server licenses. These are further subdivided into Self Service, Queue and Transfer, and Call Director variants. This section includes the following topics:

Regular Port Licenses, page 15-1 Regular Server Licenses, page 15-2 Redundant Licenses, page 15-2 License Enforcement, page 15-3 ASR/TTS Licensing, page 15-3
Regular Port Licenses

First, determine the number and type of port licenses required. To do so, imagine the busiest point in the busiest hour of the contact center. Note that what is important here is not busy hour calls, but what calls are actually doing at the busiest moment in the day. Take that moment as a snapshot, and determine three things:
1. 2.
How many calls are taking to agents How many calls are either:
15-1
Chapter 15 CVP Licensing
Licensing
waiting in queue performing simple self service without ASR/TTS and without using VoiceXML Server 3.
How many calls are performing self service activities which do use ASR/TTS or VoiceXML Server
The number of calls you determined corresponds directly to the number of regular (non- redundant) port licenses you need of each type. You need:

CVP Call Director port licenses CVP Queue and Transfer licenses, and CVP Self Service licenses.
Notice that for CVP Standalone deployments, you only need CVP Self Service licenses, since agents are not considered in such deployments. Two caveats apply to CVP Call Director licenses

CVP Call Director licenses are not required for IPCC agents. CVP Call Director licenses are not required for ACD agents where the call has been transferred to those agents using a method which takes the call away from the CVP ingress gateway (*8 TnT, hook flash, or TBCT).
Regular Server Licenses

Next, consider the number of regular (non- redundant) server licenses required. Basically, you need one server license for every 300 port licenses. For example, if you required 450 Call Director port licenses, you would need 2 Call Director server licenses. If you need 100 Queue and Transfer port licenses, you need 1 Queue and Transfer server license. You can, however, combine these licenses in order to optimize your server license usage, by effectively merging lower cost ports into higher cost servers. In this example, 150 of the 300 Call Director ports can run under the Queue and Transfer server license; you would, therefore, purchase one Call Director server license (for 300 Call Director ports) and one Queue and Transfer server license (150 Call Director + 100 Queue and Transfer ports). As with port licenses, two caveats apply to CVP Call Director server licenses:

CVP Call Director licenses are not required for IPCC agents. CVP Call Director licenses are not required for ACD agents where the call has been transferred to those agents using a method which takes the call away from the CVP ingress gateway (*8 TnT, hook flash, or TBCT).
In other words, if you did not need a CVP Call Director port license, then you do not need a CVP Call Director server license.
Redundant Licenses
Redundant licenses are purchased by port and by server. Basically, you order as many redundant ports of each type as you require, based on your redundancy model, but you may not order more redundant ports of each type than the number of regular ports you have ordered of that type. Thus, if your redundancy model is N+N, you would order as many Call Director, Queue and Transfer, and Self Service redundant port licenses as you ordered regular port licenses. If your redundancy model is N+1, you would order 300 redundant port licenses of each type that you ordered regular port licenses for, capped
15-2
OL-8408-02
Chapter 15
Licensing CVP Licensing
by the actual number of regular port licenses of that type. For example, if you had 700 Self Service port licenses, you would order 300 Redundant Self Service licenses. If you only had 200 Self Service port licenses, you could then only order 200 of the redundant variety. To calculate redundant server licenses, use the same procedure as you did for regular server licenses: one redundant server license of every 300 redundant port licenses. As before, you can conserve redundant server licenses by combining port licenses as necessary into the next more expensive level.
License Enforcement
Port and Server licenses are enforced by the CVP VoiceXML Server only. This means that only CVP Self Service licenses are actually enforced. The VoiceXML Server acquires a license the first time a call makes a request to run a VoiceXML Server application, and releases the license when the VoiceXML Server application terminates. Therefore, a single call can actually move from being a Self Service call (while it is running a VoiceXML Server self service application) to a Queue and Transfer call (while it is in queue for an agent) to a Call Director call (while connected to an agent). Notice however, that the rules for determining port and server license requirements are based on a contact-center-wide snapshot in time, rather than on the stage of a particular call.
ASR/TTS Licensing
ASR and TTS licenses are not sold by Cisco, and must be acquired directly from the vendor. For all the vendors currently supported by CVP, ASR and TTS port licenses are carefully enforced. The license is checked out the moment a call needs to use it, and reserved until the call leaves the VXML gateway.
Note
This is different than for VoiceXML Server licenses. Also, ASR and TTS licenses are independent: a call checks out an ASR license when it first needs to use ASR services, and a TTS license when it first needs to use TTS services. If you plan to move calls from Self Service to Queue and Transfer, you will most likely want to release the ASR and TTS licenses. However, CVP makes no distinction between a call which is at the VXML gateway for self service purposes, and one which is there in order to play queue music. It does not know that the call has progressed from Self Service to Queue and Transfer. The same VXML gateway session remains active across the transition, so any ASR and TTS licenses which were obtained in the first phase are not automatically released. You can, however, force the licenses to be released by causing the call to be removed from the VXML gateway and then redelivered there as a new VRU leg call. Removing it from the VXML gateway releases the ASR and TTS licenses, and redelivering the call makes it immediately available to play queue prompts again, but this time without ASR and TTS licenses. If you are using ICM release 7.0(0) or later, all you need to do is include an explicit SendToVRU node ahead of the Queue node. Prior to ICM release 7.0(0), you need to use a TranslationRouteToVRU node. This only works if you originally translation routed the call to CVP.
15-3
Chapter 15 Gateway Licensing
Licensing
Gateway Licensing
Gateway and IOS licensing are generally beyond the scope of this document. However, note that if you are using any of the ISR gateways (28xx, 37xx, 38xx) as VXML gateways, you also need to purchase FL-VXML- 1 or FL-VXML-12 licenses.
15-4
OL-8408-02
C H A P T E R
16

This chapter discusses various types of reporting and monitoring functions that can be used with CVP, and covers the following areas:

Real Time Health Monitoring of CVP Components, page 16-1 Statistical Monitoring of CVP Components, page 16-2 End to End Tracking of Individual Calls, page 16-2 Formal Reporting Based on ICM Data, page 16-3 Formal Reporting Based on CVP VoiceXML Server Data, page 16-3
Real Time Health Monitoring of CVP Components

There are several ways to monitor the health of CVP components. CVP VoiceXML Server does not have any built-in health monitoring capabilities other than the SNMP facilities offered by the operating system. The CVP Call Server continues to use the Cisco Standalone Distributed Diagnostics and Services Network (SDDSN) to provide alarm reporting through a variety of mechanisms such as:

SNMP traps CiscoWorks2000 Syslog, which receives log messages and permits queries on the logs Microsoft Windows Remote Access Server (RAS) and Hosted IPCC or ICM Event Management System (Cisco Remote Monitoring Suite, traditionally called Cisco Phone Home)
The ICM Remote Monitoring Suite's AlarmTracker is often used as the mechanism to monitor system status for multiple CVP machines. The CVP Call Server sends alarms to SDDSN, and you can use the Alarm Tracker to view alarm status across multiple CVP machines. For detailed information about the CVP Call Servers entire SNMP implementation, refer to the CVP 3.1 Configuration and Administration Guide, Chapter 7, Alarm Handling and Logging. Cisco gateways provide for SNMP monitoring. Information about various IOS MIBs are publicly available at Cisco.com; of particular relevance is the ISDN MIB, information about which can be found at: ftp://ftp.cisco.com/pub/mibs/supportlists/as5400/as5400-supportlist.html.
16-1
Chapter 16 Statistical Monitoring of CVP Components
Statistical Monitoring of CVP Components

This section focuses on ways to monitor the number of calls being handled by each component or by the contact center as a whole, either real-time or historically. While no single tool provides system-wide monitoring, there are a number of tools available for monitoring system components:

Gateway statistics, including historical and real-time call counts, may be obtained via IOS commands. The gateways ISDN MIB referenced above can be used to provide overall call volumes to an SNMP console, though it does not help distinguish which calls are in self service, in queue, or talking to agents. The ICM provides reports on the number of VRU ports in use at half hour intervals and present this information in discreet or aggregated form. If you know how many ports are available, you can determine whether there were all-trunks-busy periods, and for how long. The CVP Call Server stores detailed statistics in its log files every half hour (a configurable interval) indicating how many calls arrived, were transferred, encountered errors, etc., as well as how long they lasted and many other specific pieces of information. These are described in the CVP 3.1 Configuration and Administration Guide in Chapter 5, Engine Administration, and in Chapter 7, Viewing Voice Browser Logs. These statistics are however not in a form which is suitable for loading into a database or spreadsheet. This document is available at: http://www.cisco.com/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.ht ml
The CVP VoiceXML Server writes data rows to a flat log file every for every new call it handles. This data is in comma-separated-value format and quite suitable for loading into a database.
End to End Tracking of Individual Calls

When a call arrives at a CVP ingress gateway, IOS assigns that call an H.323 Conference ID, which is a 36-digit hexadecimal GUID that uniquely identifies the call. CVP carries that GUID through all of the components that the call encounters, as shown below:

Ingress gateway shown in IOS log files VXML gateway shown in IOS log files CVP Call Server shown in CVP Voice Browser and CVP Application Server log files CVP VoiceXML Server shown in detailed call logs, and available to VoiceXML Server applications for storage or for passing on to further back-end systems ICM shown in the ECC variable user.task.id and stored with all TCD and RCD records ASR and TTS servers shown in logs as the logging tag Cisco CallManager appears in the detailed logs
Thus, with proper levels of logging enabled, a call can be traced through all of the above components.
16-2
OL-8408-02
Chapter 16
Reporting and Monitoring Formal Reporting Based on ICM Data
Formal Reporting Based on ICM Data

ICM 6.0(0) introduced a series of reporting enhancements, among which was a new facility for VRU Progress Reporting. This facility made it possible to identify segments of a VRU application, and then keep track of how many calls entered and left those segments, how many successfully completed their transactions, and how many transferred out or abandoned intentionally or due to errors. VRU Progress Reporting is designed for use with complex self service applications that use CVP Microapplications a practice which has since fallen into disuse in favor of the CVP VoiceXML Server. However, it is still possible to make good use of this facility by dividing VoiceXML Server applications into segments or transactions, and using ICM scripting to handle the top level self service menu. This way, the ICM can still keep and present formal statistics on the success and failure rates of each application segment.
Formal Reporting Based on CVP VoiceXML Server Data

As mentioned above, CVP VoiceXML Server provides a comma-separated-value file in which information about each call is logged. In fact, if you turn debug settings high enough, you receive a large amount of logging, including the results of each node in each application for each call. This is a large volume of data, but for some purposes you require that level of detail. For example, you may be interested in capturing a great deal of call data for the first few weeks of an applications production use, or in order to troubleshoot a particularly difficult intermittent problem. Cisco generally does not recommend that this level of call logging be turned on for long periods of time, due to throughput concerns. However, if you are sure you are under-utilizing your CVP VoiceXML Servers, this is a method of capturing detailed application information. Be aware however, that though VoiceXML Server rolls over to new log files every day at midnight, it does not automatically purge old log files. This amount of data can quickly saturate the disk if you do not put operational measures in place to ensure that does not happen. With custom report development, you can process the CVP VoiceXML Server log files to produce the following types of reports, among others:
Application reporting: Call counts and call duration summaries per application
Source: Application log files under each application folder Levels: All levels of reporting
Application reporting: Call source summary data such as call counts by ANI
Source: Application log files under each application folder Levels: All levels of reporting
Application menu usage call counts and durations: This data can provide some insight into how a caller transverses through the menu setup for the self-service application. Important: There could be system performance degradation with complete logging.
Source: Application log files under each application folder Levels: Moderate and complete logging only
Voice elements reporting: This data can provide insight into interaction with voice elements including basic speech statistics. Leverage application log files under each application folder.
Source: Application log files under each application folder Levels: Moderate and complete logging only
16-3
Chapter 16 Formal Reporting Based on CVP VoiceXML Server Data
Call detail reporting: This data can provide flow details about every call made to the system and can help trace a particular call through the self-service application.
Source: Log files under each root folder Levels: All levels of reporting
16-4
OL-8408-02
GLOSSARY
A
ANI Application Server; App Server ASR ASR grammar
Automatic Number Identification. Usually the caller's phone number. One of the CVP components. The App Server is logically located between an ICM PG and one or more CVP or Cisco IOS voice browsers. Automated speech recognition. The ability to collect user input using speech recognition. A list of valid responses that a caller can provide during speech recognition.
C
Cisco Security Agent CSS
A security layer that provides intrusion detection and protection (in addition to regular virus scanning software). Content Services Switch. Responsible for load balancing and failover between the gateways and back-end servers (media servers, ASR/TTS servers, VoiceXML servers). Customer Voice Portal. The current version (and new name) of the Cisco ISN product.
CVP
D
DTMF
Dual tone multifrequency. The technique used to transmit keystrokes from touch-tone phones.
G
GED
GeoTel Engineering Document. An API for integrating ACDs, IVRs, and agents into the ICM.
GL-1
Glossary
H
H.323
A protocol standard that provides a foundation for audio, video, and data communications across IP-based networks, including the Internet. By complying to H.323, multimedia products and applications from multiple vendors can interoperate, allowing users to communicate without concern for compatibility. Hot Standby Routing Protocol. A proprietary routing protocol from Cisco that provides backup to a router in the event of a failure. Using HSRP, several routers present the appearance of a single virtual router on the LAN, sharing the same IP and MAC addresses. If one router fails, the hosts on the LAN are able to continue forwarding packets to a consistent IP and MAC address. CVP Voice Browsers talk to gatekeepers that are configured for redundancy using HSRP.
HSRP
I
ICM in-band
Intelligent Contact Management. A call routing and agent management platform from Cisco. Refers to the technique whereby data (usually DTMF keystrokes) is transmitted audibly on the same path as voice. IP Contact Center. An IP-based call center solution from Cisco. Interactive Voice Response (Voice Response Unit). An automated voice system designed for call-center applications. With respect to the ICM, CVP plays the role of an IVR.
IPCC IVR (or VRU)
L
label
A text string issued by the NAM or ICM to its routing client in response to a route request. Labels are predefined using the ICM Configuration Manager tool set. A label is a symbolic representation of the exact target location. Labels are free-form, and the format is generally dictated by the specific peripheral (ACD, VRU, CVP, PSTN, and so forth).
M
MCS MGCP
Media Convergence Server. Cisco's standard hardware platform for Windows and Linux servers. Media Gateway Control Protocol. Signaling protocol used by Media Gateway Controller (MGC) or Call Agent (CA). Also handles call routing and stores customer information and connection information. General term for a specific defined function in the CVP that can be invoked from the ICM. The value of call variables from the ICM will affect the behavior of the function. The term is also used to refer to the same specific defined functions invoked from the ICM and executed on third-party VRUs. When the ICM invokes the execution of a micro-app, the application server will generate VoiceXML that is sent to the voice browser for execution.
Micro-App; Microapp; Micro-application; Microapplication
GL-2
OL-8408-02
Glossary
MRCP
Media Resource Control Protocol. This protocol is used between the Cisco IOS voice browser and any ASR or TTS server. Media termination point. A network host that is able to send and/or receive voice or audio data.
MTP
N
NAM
Network Applications Manager. When several ICMs are deployed in a hierarchy, the NAM is the top ICM that controls those beneath it. Network Interface Controller. This is the piece of software that interfaces the NAM or ICM to the public network. The NIC essentially normalizes various carrier's AIN capability into the ICM's internal routing protocol.
NIC
O
out-of-band
Refers to the process by which data (usually DTMF keystrokes) is transmitted on some path other than the audible voice path.
P
PG
Peripheral Gateway. An ICM component that is responsible for communicating with peripheral devices such as CVP or Cisco CallManager.
R
RTP
Real-Time Transport Protocol. An Internet protocol for transmitting real-time data such as audio and video. Typically, RTP runs on top of the UDP protocol.
S
SDDSN
Standalone Distributed Diagnostics and Service Network. Allows for alarm monitoring and Event Management System (EMS) logging.
T
TTS
Text-to-speech. Ability to convert text strings to speech for playing to the calling party.
GL-3
Glossary
V
VoiceXML
Voice eXtensible Markup Language. A language similar to HTML that brings the full power of Web development and content delivery to interactive-voice-response (IVR) applications. Voice over IP. The technology for transmitting voice via a data network. Virtual Router Redundancy Protocol. An election protocol that dynamically assigns responsibility for one or more virtual routers to the VRRP router(s) on a LAN, allowing several routers on a multi-access link to use the same virtual IP address. Voice Response Unit (or Interactive Voice Response). An automated voice system designed for call-center applications. With respect to the ICM, CVP plays the role of a VRU.
VoIP VRRP
VRU (or IVR)
W
W3C
World Wide Web Consortium.
GL-4
OL-8408-02
INDEX
A
alternate endpoints application server call disposition configuration call disposition configuration server
5-17 5-8, 5-9 5-8 2-6 5-11
internal Help Desk call flows (protocol)
10-2 10-2
warm consultative transfer

10-3
for Model #1, Standalone Self Service for Model #2, CVP Call Control
10-3
10-3
Automatic Speech Recognition (ASR)

5-18 5-17
for Model #3a, CVP Call Control with Queue and Collect 10-4 for Model #3b, CVP Call Control with Queue and Self Service 10-6 CallManager and ACD Originated Calls and high availability
5-18 9-11
B
bandwidth for ASR/TTS
8-5 8-5 8-5
call disposition configuration
5-18 5-18 6-4 2-7
H323 signaling flow optional component calls from CallManager survivability

8-4 6-1 7-1
for H.323 Signaling for voice traffic provisioning sizing

8-4 8-1 8-6
for media file retrieval
10-1
for VoiceXML Documents
transfer options call transfers
Hook flash and Wink release trunk

7-1
7-2 7-4
Intelligent Network (IN) Release Trunk
C
caching on IOS configuration
14-2 6-2, 8-6
Takeback-N-Transfer (TNT) components of CVP

2-1
7-2 7-3
Call Admission Control (CAC) call control traffic call disposition failures call flows
5-6 5-8 8-2
Content Services Switch (CSS) call disposition CSS

10-2 2-5 5-13 2-2
2-5, 5-12
core components of CVP
voice browser
10-2
Customer Voice Portal (see CVP) CVP

ICM Outbound with Transfer to IVR
OL-8408-02
IN-1
Index
Application Server as Service Node IVR call server components

4-2 2-1
5-8 9-3, 9-4
F
features of CVP
5-14 1-1
as Intelligent Peripheral IVR

9-2
call disposition with microapplications
G
5-14 9-4
configuring microapplications features overview Studio

2-5 5-6 2-5, 5-15 1-1 8-2
G.711 Media Burst blocking gatekeeper alternate configuration call disposition configuration H.323 HSRP
6-5 5-4 5-6 5-5 5-6 8-7
deployment models and networkVRU types Network Architecture

1-1
Voice Browser
VoiceXML Server
high availaility
5-4
D
data traffic
8-4 10-6 10-7 10-7
HSRP configuration overview sizing gateways and TDM Interfaces MGCP

10-6 4-6 12-1 5-3 2-3 2-4
5-5 6-2
in distributed deployment
4-3, 4-6
deployment implications
for CallManager Configuration for CVP Call Control Servers for gateways
10-7
12-2
for hosted implementations for ICM Configuration for MTP resources for network level for sizing
10-7 3-1 10-8 10-7 10-6
options overview PSTN sizing
originating
12-1 4-3
deployment models
VoiceXML
3-1
5-10 12-1 12-1
Model #1. Standalone Self Service Model #2, CVP Call Control
3-5
VoiceXML & PSTN GED-125 GKTMP and ICM call flow

11-1 11-2 8-3
VoiceXML with DTMF or ASR/TTS
Model #3a, CVP Call Control with Queue and Collect 3-9 Model #3b, CVP Call Control with Queue and Self Service 3-14 Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service 3-17
applications
11-3 11-4 11-1
deployment implications glossary

GL-1
Gatekeeper Transaction Message Protocol NIC
IN-2
OL-8408-02
Index
H
H.323
8-2 5-1
regular ports regular servers
15-1 15-2
high availability gatekeeper

5-4
M
5-2 xiii 7-2 9-7
layer 2 switch
media files media server MGC

2-4 xiv 2-5
14-1 2-5
history of revisions Hook flash and Wink
Media Gateway Controller (MGC)

2-6, 5-14 5-14
hosted implementations Hosted IPCC

2-7
configuration monitoring
Hot Standby Router Protocol (HSRP) how to use this document HSRP
2-4, 5-4, 5-5 5-5
end-to-end call tracking real-time statistical MRCP

8-3 13-2 16-1 16-2
16-2
alternate gatekeeper
I
ICM
2-7, 9-1 8-3 2-7, 5-19
multilanguage support
ICM Central Controller configuration disposition interacting with

5-19 5-19 9-1
N
network level considerations network security using firewalls networkVRU types
8-8 9-1 9-4 8-1
Intelligent Contact Management (ICM)
network VRU types IPCC current release Hosted

2-7 8-1 xiii
9-1 7-4
and CVP deployment models in a Hosted environment

9-10
O
organization of this document originating gateway
5-3 5-4 5-3 xiv
IP infastructure
L
Layer 2 Switch licensing CVP
15-1 15-3 5-2
ASR/TTS
15-1
P
PGW Softswitch
2-5
enforcement gateways
15-3
prompt management best practices

15-2
15-4
14-2
redundant licenses
OL-8408-02
IN-3
Index
protocols HSRP SS7

2-4 2-5
configuration
5-20
T
Takeback-N-Transfer (TNT) TDM interfaces
12-2 2-6 7-2
Q
QoS
8-7
Text-To-Speech (TTS) Text-to-Speech (TTS) call disposition configuration server

xiii 7-1 2-5 5-17 9-12 5-18 5-17
R
RAS
2-5
releases of software release trunk transfers reporting
Third Party VRUs TTS

2-6
Remote Access Service (RAS) on CVP VoiceXML data on ICM data revision history RSVP
6-5, 8-6 16-3 xiii 16-3
7-3
V
versions of software voice browser call disposition
5-8 5-7 xiii
S
SDDSN servers for media
2-6 2-5 2-5 2-5
configuration voice traffic VoiceXML

8-2
Voice eXtensible Markup Language (see VoiceXML)
CVP Studio installation location described over HTTP server

4-2 1-2 13-2
13-3
for VoiceXML
service creation environment Signaling System 7 (SS7) sizing CVP call server gatekeeper gateways overview
4-3 4-1 4-3 4-3, 4-6 2-5
multilanguage support
13-1 2-5, 4-3
server design implications VoiceXML gateways alternate endpoints call disposition configuration
5-12 5-10 5-10 5-11
13-1 13-2
web appllication server differences
VoiceXML server software versions SS7

2-5
xiii
content services switch (CSS) hardware configuration VoiceXML server

5-12
5-12
Standalone Distributed Diagnostics and Services Network (SDDSN) 2-5, 5-19 call disposition
5-20
IN-4
OL-8408-02
Index
5-16 5-15
W
W3C
2-6 2-6
World Wide Web Consortium (W3C)
IN-5

Cisco Customer Voice Portal (CVP) Solution Reference Network Design (SRND)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco Customer Voice Portal (CVP) Solution Reference Network Design (SRND)

Uploaded by

Copyright:

Available Formats

Cisco Customer Voice Portal (CVP) Solution Reference Network Design (SRND)

Customer Voice Portal (CVP) Release 3.1 March 2006

Text Part Number: OL-8408-02

High Level Architecture

What is the Cisco Customer Voice Portal? What is VoiceXML?

Typical CVP Deployment

Deployment Models and Sizing

4-1 4-1 4-2 4-3

Sizing Overview CVP Call Server

CVP VoiceXML Server

CVP Solution Design Best Practices

Designing CVP for High Availability Overview

Call Survivability in Distributed Deployments Gatekeeper implications

Call Transfer Options

Intelligent Network (IN) Release Trunk Transfers

Blocking initial G.711 Media Burst Network Security using Firewalls

Interacting with ICM

Using the GKTMP NIC The ICM GKTMP NIC

The Cisco Gatekeeper External Interface

Routing of post-ICM calls Other implications 11-6

Gateway Options PSTN Gateway

12-1 12-1 12-2 12-2

VoiceXML Gateway with DTMF or ASR/TTS TDM Interfaces

VoiceXML & PSTN Gateway with DTMF or ASR/TTS

Media File Options

14-1 14-1 14-1

Bandwidth Calculation for Prompt Retrieval

Reporting and Monitoring

Formal Reporting Based on CVP VoiceXML Server Data

Revision Date November, 2005 March, 2006

Preface Document Organization

Part I: General Information

Part II: Deployment Models and Sizing

Part III: Reference Material

Product Documentation DVD

Preface Documentation Feedback

Cisco Product Security Overview

Preface Obtaining Technical Assistance

Reporting Security Problems in Cisco Products

For Nonemergencies psirt@cisco.com

In an emergency, you can also reach PSIRT by telephone:

1 877 228-7302 1 408 525-6532

Obtaining Technical Assistance

Cisco Technical Support & Documentation Website

Preface Obtaining Technical Assistance

Submitting a Service Request

Definitions of Service Request Severity

Preface Obtaining Additional Publications and Information

Obtaining Additional Publications and Information

Preface Obtaining Additional Publications and Information

High Level Architecture

What is the Cisco Customer Voice Portal?

Chapter 1 What is VoiceXML?

Typical CVP Deployment

Chapter 2 CVP Solution Components

Typical CVP Deployment

H323 RAS Gatekeeper

H323 CVP Call Control JTAPI

VXML CVP VXML servers VXML GED-125

VXML Gateway with IOS VB

ICM Enterprise Edition

CVP AS Media servers