Cisco Customer Voice Portal (CVP) Release 3.1 Solution Reference Network Design (SRND)
Network Level Considerations (The IP Infrastructure)
Downloads: This chapterpdf (PDF - 224.0KB) The complete bookPDF (PDF - 1.96MB) | Feedback

Network Level Considerations (The IP Infrastructure)

Table Of Contents

Network Level Considerations (The IP Infrastructure)

Bandwidth Provisioning and QoS Considerations

CVP Network Architecture Overview

Voice Traffic

Call Control Traffic

H.323

GED-125

MRCP

ICM Central Controller to CVP VRU PG

Data Traffic

Bandwidth Sizing

VoiceXML Documents

Media File Retrieval

H.323 Signaling

ASR/TTS

Voice Traffic

Call Admission Control

RSVP

QoS

Blocking initial G.711 Media Burst

Network Security using Firewalls


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

Bandwidth Sizing

Call Admission Control

QoS

Blocking initial G.711 Media Burst

Network Security using Firewalls

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.

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

Call Control Traffic

Data Traffic

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:

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_home.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:

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.

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.

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

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

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

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
Port
Queue
PHB
DSCP
Max Latency (round trip)

Media Server

r TCP 80

CVP-Data

AF11*

10*

1 sec

CVP Call Server H.323

TCP 1720

Signaling

CS3

24

200 ms

CVP Application Server

TCP 8000

CVP-Data

AF11*

10*

1 sec

CVP Call Server AppAdmin Remote Message Interface (RMI) port

TCP 40099

Default

BE

0

5 sec

CVP VoiceXML Server

TCP 8080

CVP-Data

AF11*

10*

1 sec

Ingress Gateway H.323

TCP 1720

Signaling

CS3

24

200 ms

VoiceXML Gateway H.323

TCP 1720

Signaling

CS3

24

200 ms

H.323 Gatekeeper

UDP 1719

Signaling

CS3

24

200 ms

MRCP

TCP 554

Signaling

CS3

24

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.

Network Security using Firewalls

When configuring network security using firewalls or ACL's, 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
Destination Port

Voice Gateway -> Media Server

TCP 80

Voice Gateway -> CVP Call Server H.225

TCP 1720

Voice Gateway -> CVP Call Server

TCP 8000

Voice Gateway -> CVP VoiceXML Server

TCP 8080

Voice Gateway -> MRCP Server

TCP 554

CVP Call Server -> Egress Voice Gateway H.225

TCP 1720

CVP Call Server -> VoiceXML Gateway H.225

TCP 1720

CVP Call Server -> H.323 Gatekeeper

UDP 1719