Cisco Unified Customer Voice Portal (CVP) 7.x Solution Reference Network Design (SRND)
Network Infrastructure Considerations
Downloads: This chapterpdf (PDF - 434.0KB) The complete bookPDF (PDF - 3.14MB) | Feedback

Network Infrastructure Considerations

Table Of Contents

Network Infrastructure Considerations

Bandwidth Provisioning and QoS Considerations

Unified CVP Network Architecture Overview

Voice Traffic

Call Control Traffic

Data Traffic

Bandwidth Sizing

VoiceXML Documents

Media File Retrieval

H.323 Signaling

SIP Signaling

ASR and TTS

Voice Traffic

Call Admission Control

QoS Marking

Blocking Initial G.711 Media Burst

Network Security Using Firewalls


Network Infrastructure Considerations


Last revised on: August 18, 2009

 

This chapter presents deployment characteristics and provisioning requirements of the Unified CVP network. Provisioning guidelines are presented for network traffic flows between remote components over the WAN, including recommendations for applying proper Quality of Service (QoS) to WAN traffic flows.

For the most current information on network considerations, refer to the sections on deployment models, bandwidth, and QoS presented in the latest version of the Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND), available at

http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html

This chapter covers the following topics:

Bandwidth Provisioning and QoS Considerations

Bandwidth Sizing

Call Admission Control

QoS Marking

Blocking Initial G.711 Media Burst

Network Security Using Firewalls

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:

In a distributed Unified CVP deployment, when the ingress gateways are separated from the Unified CVP servers by a WAN.

In Unified CVP deployments where the ingress gateway and the agent are separated over a WAN. The agent can be a TDM ACD agent or a Unified CCE agent.

Unlike Unified ICM, Unified CVP has a very simple view of QoS:

Unified CVP has no concept of a private WAN network structure. All WAN activity, when required, is conducted on a converged WAN network structure.

Unified CVP does not use separate IP addresses for high and low priority traffic.

Unified CVP does mark the QoS DSCP of SIP packets. H.323 traffic must be marked by routers or switches in the network using access control lists (ACLs).

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

Call Control Traffic

Data Traffic

Voice Traffic

Voice calls consist of Real-Time Transport Protocol (RTP) packets that contain actual voice samples. RTP packets are transmitted in the following cases:

Between the ingress PSTN gateway or originating IP phone and one of the following:

Another IP phone, such as an agent

The destination phone might or might not be co-located with the ingress gateway or calling IP phone, and the connection can be over a WAN or LAN.

An egress gateway front-ending a TDM ACD (for legacy ACDs or IVRs)

The egress gateway might or might not be co-located with the ingress gateway, and the connection can be over a WAN or LAN.

A VoiceXML gateway performing prompt-and-collect treatment

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.


Note Unified CVP can support both G.711 and G.729 codecs. 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. An IP-originated call from a G.729 region would require a transcoder during IVR treatment at the VoiceXML gateway.


Between the VoiceXML gateway and the ASR/TTS server. The RTP stream between the VoiceXML gateway and ASR/TTS server must be G.711, and the connection can be over a WAN or LAN.

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:

Ingress gateway to/from Unified CVP Call Server

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.

Unified CVP Call Server to/from egress gateway

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.


Note Currently approved deployment designs do not support SIP for interoperability between the PGW and Unified CVP. If your design requires this functionality, contact the Cisco Assessment to Quality (A2Q) team.


GED-125

The Unified CVP Call Server and the Unified ICM VRU PG communicate using the GED-125 protocol. The GED-125 protocol includes:

Messages that control the caller experience, such as notification when a call arrives

Instructions to transfer or disconnect the caller

Instructions that control the IVR treatment the caller experiences

The VRU PG normally connects to Unified CVP over a LAN connection. However, in deployments that use clustering over the WAN, it is possible for Unified CVP to connect to the redundant VRU PG across the WAN.

At this time, no tool exists that specifically addresses communications between the VRU PG and Unified CVP. However, bandwidth consumed between the Unified ICM Central Controller and VRU PG is very similar to the bandwidth consumed between the VRU PG and Unified CVP.

The VRU Peripheral Gateway to ICM Central Controller Bandwidth Calculator tool is available (with proper login authentication) through the Cisco Steps to Success Portal at

http://tools.cisco.com/s2s/HomePage.do?method=browseHomePage

You can also access the Bandwidth Calculator directly (with proper login authentication) at

http://tools.cisco.com/s2slv2/ViewDocument?docName=EXT-AS-100901

If the VRU PGs are split across the WAN, the total bandwidth required would be double what the calculator tool reports: once for Unified ICM Central Controller to VRU PG and once for VRU PG to Unified CVP.

Media Resource Control Protocol (MRCP)

The VoiceXML gateway communicates with ASR/TTS servers using Media Resource Control Protocol (MRCP) v1.0. 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 (with proper login authentication) at:

http://tools.cisco.com/s2slv2/ViewDocument?docName=EXT-AS-100901

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:

The VoiceXML gateway requests media files in an HTTP request to a media file server. The media server response returns the media file in the body of the HTTP message. The VoiceXML gateway then converts the media files to RTP packets and plays them to the caller. The connection in this case can be over a WAN or LAN.

The VoiceXML gateway requests VoiceXML documents from either the Unified CVP VXML Server or the Unified CVP IVR Service. The connection in this case can be over a WAN or LAN.

This chapter focuses primarily on the types of data flows and bandwidth used between a remote ingress gateway and the components with which it interfaces:

Unified CVP VXML Server

Unified CVP Call Server IVR Service

Unified CVP Call Server SIP or H.323 Service

IP phones

Media servers

Egress gateways

ASR or TTS servers

Guidelines and examples are presented to help estimate required bandwidth and, where applicable, provision QoS for these network segments.

Bandwidth Sizing

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 (VXML) documents are generated based on voice application scripts written using either Unified ICM scripts or Cisco Unified Call Studio, or both. A VoiceXML document is generated for every prompt that is played to the caller. The VoiceXML documents vary in size, depending on the type of prompt being used; menu prompts with many selections are much larger than a simple prompt that simply plays an announcement.

On average, a VoiceXML document between the Unified CVP Call Server or Unified CVP VXML Server and the gateway is about 7 kilobytes. You can calculate the bandwidth used by approximating the number of prompts that will be used per call, per minute. The calculation is as follows:

7,000 bytes * 8 bits = 56,000 bits per prompt

56,000 * (Number of prompts per minute) / 60 = kbps per port

However, if you are going to use a more complex application that uses many menu prompts (more than the average estimated above) or if you want to calculate the bandwidth more exactly, you can use the VoiceXML document sizes listed in Table 9-1 to calculate the amount of bandwidth needed. The document sizes in Table 9-1 are measured from the Unified CVP VXML Server to the VXML Gateway.

 

Table 9-1 Approximate Size of VXML Document Types 

VXML Document Type
VXML Document Size (approximate)

Root document (one required at beginning of call)

19,000 bytes

Subdialog_start (at least one per call at beginning of call)

700 bytes

Query gateway for Call-ID and GUID (one required per call)

1,300 bytes

Menu (increases in size with number of menu choices)

1,000 bytes + 2,000 bytes per menu choice

Play announcement (simple .wav file)

1,100 bytes

Cleanup (one required at end of call)

4,000 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 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

Assume that there is a total of 50 prompts, with an average size of 50 kB and a refresh interval of 15 minutes. The bandwidth usage would then be:

(50 prompts) * (50,000 bytes/prompt) * (8 bits/byte) = 20,000,000 bits

(20,000,000 bits) / (900 secs) = 22.2 average kbps per branch

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.


Note Cisco does not recommend implementing ASR/TTS over the WAN without first qualifying the bandwidth and latency requirements with your Cisco partner.


Classifying RTP Media Traffic Between VoiceXML Gateways and ASR/TTS Servers

The RTP port range used by the VoiceXML gateway is the normal Cisco IOS RTP UDP port range of 16384 to 32767; however, the RTP UDP port range used by the ASR/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 3
 rule 3 /5559000/ /5559001/
!
voice translation-profile change
 translate called 3
!
!Primary dial-peer is ASR/TTS enabled DNIS in ICM script
dial-peer voice 9000 voip
 max-conn 6
 preference 1
 destination-pattern 55590..
 ...
!
!As soon as 'max-conn' is exceeded, next preferred dial-peer will change the DNIS to a 
DTMF prompt & collect ICM script
dial-peer voice 9001 voip
 translation-profile outgoing change
 preference 2
 destination-pattern 55590..
 ...
!
 

Note 80 kbps is the rate for G.711 full-duplex with no VAD, including IP/RTP headers and no compression. 24 kbps is the rate for G.729 full-duplex with no VAD, including IP/RTP headers and no compression. For more information on VoIP bandwidth usage, refer to the Voice Codec Bandwidth Calculator (login authentication required), available at http://tools.cisco.com/Support/VBC/do/CodecCalc1.do.


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

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html

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

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html

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-2.

 

Table 9-2 Recommended Port Usage and QoS Settings 

Component
Port
Queue
PHB
DSCP
Maximum Latency
(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 VXML 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 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 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-3 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 7.0 Port Utilization Guide.


Note Because the Unified CVP Operations Console Server uses dynamic ports for communication with other components, it cannot be deployed outside of a firewall while the rest of the Unified CVP components reside inside the firewall.


 

Table 9-3 TCP/UDP Ports Used by Unified CVP, Voice Gateways, and VoiceXML Gateways 

Source and Destination Component
Destination Port

Voice Gateway to Media Server

TCP 80

Voice Gateway to Unified CVP Call Server H.225

TCP 1720

Voice Gateway to Unified CVP Call Server SIP

TCP or UDP 5060

Voice Gateway to Unified CVP Call Server

TCP 8000

Voice Gateway to Unified CVP VXML Server

TCP 7000

Voice Gateway to MRCP Server

TCP 554

Unified CVP Call Server to Egress Voice Gateway H.225

TCP 1720

Unified CVP Call Server to Egress Voice Gateway SIP

TCP or UDP 5060

Unified CVP Call Server to VoiceXML Gateway H.225

TCP 1720

Unified CVP Call Server to VoiceXML Gateway SIP

TCP or UDP 5060

Unified CVP Call Server to H.323 Gatekeeper

UDP 1719

Unified CVP Call Server to SIP Proxy Server

TCP or UDP 5060