-
Cisco Unified Customer Voice Portal (CVP) 4.x Solution Reference Network Design (SRND)
-
Preface
-
Unified CVP Architecture Overview
-
Functional Deployment Models
-
Distributed Deployments
-
Designing Unified CVP for High Availability
-
Interactions with Cisco Unified ICM
-
Calls Originated by Cisco Unified Communications Manager
-
Gateway Options
-
Design Implications for VoiceXML Server
-
Network Infrastructure Considerations
-
Call Transfer Options
-
Using the GKTMP NIC
-
Media File Options
-
Managing, Monitoring, and Reporting
-
Sizing
-
Licensing
-
Index
-
Feedback
Table Of Contents
Network Infrastructure Considerations
Bandwidth Provisioning and QoS Considerations
Unified CVP Network Architecture Overview
Blocking Initial G.711 Media Burst
Network Security Using Firewalls
Network Infrastructure Considerations
This chapter presents deployment characteristics and provisioning requirements of the Unified CVP network. Provisioning guidelines are presented for network traffic flows between remote components over the WAN, including recommendations for applying proper Quality of Service (QoS) to WAN traffic flows.
For the most current information on network considerations, refer to the sections on deployment models, bandwidth, and QoS presented in the latest version of the Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND), available at
This chapter covers the following topics:
•
Bandwidth Provisioning and QoS Considerations
•
•
Bandwidth Provisioning and QoS Considerations
In many Unified 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 Unified CVP environment:
•
•
Unlike Unified ICM, Unified CVP has a very simple view of QoS:
•
•
•
Adequate bandwidth provisioning is an important component in the success of Unified CVP deployments. Bandwidth guidelines and examples are provided in this chapter to help with provisioning the required bandwidth.
Unified CVP Network Architecture Overview
In a Unified CVP environment, WAN and LAN traffic can be grouped into the following categories:
Voice Traffic
Voice calls consist of Real-Time Transport Protocol (RTP) packets that contain actual voice samples. RTP packets are transmitted in the following cases:
•
–
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.
–
The egress gateway might or might not be co-located with the ingress gateway, and the connection can be over a WAN or LAN.
–
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 (located on the same LAN). The connection is typically over a LAN but can be over a WAN.
•
Call Control Traffic
There are several types of call control traffic in a Unified CVP solution. Call control functions include those used to set up, maintain, tear down, or redirect calls.
H.323 or SIP
Unified CVP is currently certified with three types of VoIP endpoints: Cisco IOS voice gateways, Cisco Unified Communications Manager (Unified CM), and the PGW in either Call Control mode or Signaling mode. Call Control traffic flows between the following endpoints:
•
The ingress gateway can be a PGW, Unified CM, or a Cisco IOS gateway, or other SIP device in the case of SIP. The connection can be over a WAN or LAN.
•
The egress gateway can be Unified CM or a Cisco IOS gateway. 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 (Unified CCE or TDM) or a legacy TDM IVR. The connection can be over a WAN or LAN.
GED-125
The Unified CVP Call Server and the Unified ICM VRU PG communicate using the GED-125 protocol. The GED-125 protocol includes:
•
•
•
The VRU PG normally connects to Unified CVP over a LAN connection. However, in deployments that use clustering over the WAN, it is possible for Unified CVP to connect to the redundant VRU PG across the WAN.
At this time, no tool exists that specifically addresses communications between the VRU PG and Unified CVP. However, bandwidth consumed between the Unified ICM Central Controller and VRU PG is very similar to the bandwidth consumed between the VRU PG and Unified CVP.
The VRU Peripheral Gateway to ICM Central Controller Bandwidth Calculator tool is available (with proper login authentication) through the Cisco Steps to Success Portal at
If the VRU PGs are split across the WAN, the total bandwidth required would be double what the calculator tool reports: once for Unified ICM Central Controller to VRU PG and once for VRU PG to Unified CVP.
Media Resource Control Protocol (MRCP)
The VoiceXML gateway communicates with ASR/TTS servers using Media Resource Control Protocol (MRCP) v1.0. 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 can be over the LAN or WAN.
ICM Central Controller to Unified CVP VRU PG
No tool exists that specifically addresses communications between the Unified ICM Central Controller and the Unified CVP VRU PG. Testing has shown, however, that the tool for calculating bandwidth needed between the Unified ICM Central Controller and the IP IVR PG also produces accurate measurements for Unified CVP if you perform the following substitution in one field:
For the field labeled Average number of RUN VRU SCRIPT nodes, substitute the number of Unified ICM script nodes that interact with Unified CVP. Nodes that can interact with Unified CVP are Run External Script, Label, Divert Label, Queue to Skill Group, Queue to Agent, Agent, Release, Send to VRU, and Translation Route to VRU.
This bandwidth calculator tool is available (valid Cisco Partner login required) at:
The connection in this case can be over a WAN or LAN.
Data Traffic
Data traffic includes VoiceXML documents and prerecorded media files returned as a result of HTTP requests executed by the VoiceXML gateway. Specifically:
•
•
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:
•
•
•
•
•
•
•
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 Unified CVP solution occur in a Distributed Unified CVP topology, due primarily to the fact that the ingress and/or VoiceXML gateway is separated from the servers that provide it with media files, VoiceXML documents, and call control signaling. For purposes of the following discussion, assume all calls to a branch begin with one minute of IVR treatment followed by a single transfer to an agent that also lasts one minute. Each branch has 20 agents, and each agent handles 30 calls per hour for a total of 600 calls per hour per branch. The call average rate is therefore 0.166 calls per second (cps) per branch.
Note that even a slight change in these variables might have a large impact on sizing. It is important to remember that .166 calls per second is an average for the entire hour. Typically, calls do not come in uniformly across an entire hour, and there are usually peaks and valleys within the busy hour. Try to find the busiest traffic period, and calculate the call arrival rate based on the worst-case scenario.
VoiceXML Documents
VoiceXML documents are generated based on voice application scripts written using either Unified ICM scripts or Unified CVP VoiceXML Studio, or both.
A VoiceXML document roughly corresponds to a Run External Script node in a Unified ICM script. A VoiceXML document between the Unified CVP Call Server and the gateway is about 7 kilobytes. 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 average bandwidth usage can then be calculated as follows:
(7000 bytes/document) * (20 documents) * (8 bits/byte) = 1,120,000 bits per call
(0.166 cps) * (1,120,000 bits per call) = 185.9 average kbps per branch
One might expect that Unified CVP VoiceXML Server applications produce much more complex VoiceXML documents than do Unified CVP Microapplications because the VoiceXML applications themselves are much more complex. However, that does not appear to be the case. Unified 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, Unified CVP VoiceXML Server makes use of a "root document," which enables it to factor out common VoiceXML code and error handling into a file that 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 size as Unified CVP Application Server pages: 7 kilobytes.
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 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at
Assume that there is a total of 50 prompts, with an average size of 50 kB and a refresh interval of 15 minutes. The bandwidth usage would then be:
(50 prompts) * (50,000 bytes/prompt) * (8 bits/byte) = 20,000,000 bits
(20,000,000 bits) / (900 secs) = 22.2 average kbps per branch
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 average bandwidth required would be (0.166 * 56 kbps) = 9.3 kbps for the WAN link to the remote branch.
SIP Signaling
SIP is a text-based protocol, therefore the packets used are larger than with H.323. The typical SIP call flow uses about 17,000 bytes per call. Using the previous bandwidth formulas based on calls per second, the average bandwidth usage would be:
(17,000 bytes/call) * (8 bits/byte) = 136,000 bits per call
(0.166 calls/second) * (136 kilobits/call) = 22.5 average kbps per branch
ASR and TTS
Centralized Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) are now supported in distributed Unified CVP deployments as of Unified CVP 4.0. In order to support this model, QoS must be configured on the network and bandwidth must be reserved specifically for the ASR/TTS RTP and MRCP traffic. ASR/TTS cannot use silence suppression and must use the G.711 codec, therefore centralized ASR/TTS is bandwidth intensive. ASR/TTS RTP and MRCP traffic is not tagged with QoS DSCP markings, therefore it is necessary to use access control lists (ACLs) to classify and re-mark the traffic at the remote site and central site.
Classifying RTP Media Traffic Between VoiceXML Gateways and ASR/TTS ServersRTP
The RTP port range used by the VoiceXML gateway is the normal Cisco IOS RTP UDP port range of 16384 to 32767; however, the RTP UDP port range used by the ASR/TTS server can vary by OS and ASR/TTS vendor. It is possible to construct an ACL to match the traffic from the ASR/TTS server based on the VoiceXML gateway UDP port range; but if possible, Cisco recommends finding the ports used by the ASR/TTS server as well. The RTP traffic should be marked with DSCP EF so that it is placed in the priority queue with other voice traffic.
The QoS priority queue must also be configured to support the maximum number of ASR/TTS sessions anticipated. If a call admission control mechanism such as Cisco Unified CM locations or Resource Reservation Protocol (RSVP) is used, this extra priority queue bandwidth should not be included when configuring the locations or RSVP bandwidth. For example, if you want to support two ASR/TTS G.711 sessions (80 kbps each) as well as four IP telephony phone calls using G.729 (24 kbps each), the priority queue total bandwidth would be 256 kbps. The locations call admission control or RSVP bandwidth should be limited to only the IP telephony bandwidth (96 kbps in this example). Configuring the locations or RSVP bandwidth with 256 kbps would allow IP telephony calls to use all of the bandwidth and conflict with the ASR/TTS sessions.
Classifying MRCP Traffic Between VoiceXML Gateways and ASR/TTS Servers
The MRCP traffic is much easier to classify. ASR/TTS servers listen on TCP 554 for MRCP requests, therefore this port should be used in ACLs to classify the traffic. The bandwidth used by MRCP can vary depending on how often the application uses the ASR/TTS resource. MRCP uses about 2000 bytes per interaction. If there is an ASR/TTS interaction every 3 seconds per call, you can calculate the average bandwidth as follows:
(2000 bytes/interaction) * (20 interactions/minute) * (8 bits/byte) = 320,000 bits per minute per call
(320,000 bits per minute) / (60 seconds/minute) = 5.3 average kbps per branch
If you configure a maximum of 6 ASR/TTS sessions at any given time, then (6 * 5.3 kbps) = 32 average kbps per branch.
Limiting the Maximum Number of ASR/TTS-Enabled Calls
It is possible to limit the number of calls enable for ASR/TTS so that, once the limit is reached, regular DTMF prompt-and-collect can be used instead of rejecting the call altogether. In the following example, assume 5559000 is the ASR/TTS DNIS and 5559001 is the DTMF DNIS. You can configure the ingress gateway to do the ASR load limiting for you by changing the DNIS when you have exceeded maximum connections allowed on the ASR/TTS VoIP dial peer.
voice translation-rule 3rule 3 /5559000/ /5559001/!voice translation-profile changetranslate called 3!!Primary dial-peer is ASR/TTS enabled DNIS in ICM scriptdial-peer voice 9000 voipmax-conn 6preference 1destination-pattern 55590.....!!As soon as 'max-conn' is exceeded, next preferred dial-peer will change the DNIS to a DTMF prompt & collect ICM scriptdial-peer voice 9001 voiptranslation-profile outgoing changepreference 2destination-pattern 55590.....!
Note
Voice Traffic
Unified CVP can support both G.711 and G.729. G.711 must be used for the VoiceXML portion of the call, but G.729 can be used once the call is connected to an Agent. If you are using ASR/TTS for speech recognition, then G.711 must be used because ASR/TTS servers support only G.711. For the most current bandwidth information on voice RTP streams, refer to the latest version of the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager, available at
Call Admission Control
Call admission control is the mechanism for determining if there is enough bandwidth available on the network to carry an RTP stream. Unified CM can use its own locations mechanism or RSVP to track bandwidth between the ingress gateway and destination IP phone locations.
For more information about call admission control, see the chapter on Distributed Deployments, page 3-1.
RSVP
Cisco Unified CM 5.0 introduced support for Resource Reservation Protocol (RSVP) between endpoints within a cluster. RSVP is a protocol used for call admission control, and it is used by the routers in the network to reserve bandwidth for calls. RSVP can be used for delivering calls to Unified CCE agents in a Unified CM cluster. For more information on RSVP, refer to the latest version of the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager, available at
QoS Marking
The Unified CVP Call Server marks only the QoS DSCP for SIP messages. If QoS is needed for Unified CVP H.323 signaling and data traffic across a WAN, configure network routers for QoS using the IP address and ports to classify and mark the traffic as recommended in Table 9-1.
Table 9-1 Recommended Port Usage and QoS Settings
(Round Trip)Media Server
TCP 80
CVP-Data
AF111
101
1 sec
Unified CVP Call Server, H.323
TCP 1720
Call Signaling
CS3
24
200 ms
Unified CVP Call Server, SIP
TCP or UDP 5060
Call Signaling
CS3
24
200 ms
Unified CVP IVR Service
TCP 8000
CVP-Data
AF111
101
1 sec
Unified CVP VoiceXML Server
TCP 7000
CVP-Data
AF111
101
1 sec
Ingress Gateway, H.323
TCP 1720
Call Signaling
CS3
24
200 ms
Ingress Gateway, SIP
TCP or UDP 5060
Call Signaling
CS3
24
200 ms
VoiceXML Gateway, H.323
TCP 1720
Call Signaling
CS3
24
200 ms
VoiceXML Gateway, SIP
TCP or UDP 5060
Call Signaling
CS3
24
200 ms
H.323 Gatekeeper
UDP 1719
Call Signaling
CS3
24
200 ms
SIP Proxy Server
TCP or UDP 5060
Call Signaling
CS3
24
200 ms
MRCP
TCP 554
Call Signaling
CS3
24
200 ms
1 The DSCP (or PHB) value for CVP-Data traffic is only a recommendation. You can choose the actual DSCP value used to mark the traffic according to your preference.
Neither the CVP-Data queue nor the Signaling queue is a priority queue as described in Cisco IOS router terminology. The priority queue is used for voice or other real-time traffic, while call signaling and Unified CVP traffic are reserved a certain amount of bandwidth based on the call volume.
Blocking Initial G.711 Media Burst
When a gateway first receives a call, the gateway signals the Unified CVP Call Server using H.323 in order to hand off the call control responsibilities. To establish this initial call, a short media stream is established between the gateway and the Unified CVP Call Server. The media stream is only in one direction, from the gateway to the Unified CVP Call Server. Because this media stream is not accounted for by Unified CM's locations-based call admission control, Cisco recommends that the media stream be blocked from traversing bandwidth-constrained links to avoid oversubscribing the priority queue. This precaution is needed only for H.323 deployments; SIP deployments do not have this consideration. The following example illustrates the ACL configuration:
access-list 100 deny udp host 10.0.0.1 host 10.10.0.100 range 16384 32767access-list 100 permit ip any anyinterface serial0/0ip access-group 100 outIn the preceding example, 10.0.0.1 is the voice gateway's H.323-bound IP address and 10.10.0.100 is the Unified 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 Unified CVP Call Server.
Network Security Using Firewalls
When configuring network security using firewalls or ACLs, refer to Table 9-2 for information about TCP/UDP ports used by Unified CVP, voice gateways, VoiceXML gateways. For a complete listing of ports used by Unified CVP, refer to the Unified CVP 4.0 Port Utilization Guide.
