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

Sizing

Table Of Contents

Sizing

What's New in This Chapter

Sizing Overview

Unified CVP Call Server

Unified CVP VXML Server

Unified CVP Co-Residency

Unified Presence Server

Unified CVP Video Service

Sizing Unified CVP Basic Video Service

Sizing Unified CVP Full Video Service

CVP Components

Cisco Unified Videoconferencing Hardware

Other Software and Hardware

Unified CVP Reporting Server

How to Use Multiple Reporting Servers

Reporting Message Details

Example Applications


Sizing


Last revised on: August 18, 2009

 

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

Unified CVP Call Server

Unified CVP VXML Server

Unified CVP Co-Residency

Unified Presence Server

Unified CVP Video Service

Unified CVP Reporting Server

What's New in This Chapter

Table 14-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

 

Table 14-1 New or Changed Information Since the Previous Release of This Document 

New or Revised Topic
Described in:

Sizing co-resident deployments

Unified CVP Co-Residency

Unified CVP VXML Server sizing

Unified CVP VXML Server


Sizing Overview

When sizing a contact center, first determine the worst-case contact center profile in terms of the number of calls that are in each state. 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 that are executing applications using the Unified CVP VXML Server

Queue and collect — Calls that are in queue for an agent or that are executing prompt-and-collect type self-service applications

Talking — Calls that are connected to agents or to third-party TDM VRU applications

In counting the number of calls that are in the talking state, count only calls that are using Unified 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 Unified CVP resource because Unified 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 that are tromboned to a TDM target, using both an incoming and an outgoing TDM port on the same gateway or on a different gateway (that is, toll bypass). Calls that are transferred to VRUs or agents in this manner should be counted as talking calls.

However, if the call was transferred via *8 TNT, hookflash, Two B Channel Transfer (TBCT), or an ICM NIC, neither the gateway nor Unified CVP play any role in the call. Both components have reclaimed their resources, therefore such calls should not be counted as talking calls.

Finally, include in the overall call counts those calls that have been transferred back into Unified CVP for queuing or self-service, via either blind or warm methods. For instance, if a warm transfer is used and the agent is queued at Unified CVP during the post-route phase, the call would use two ports due to two separate call control sessions at Unified CVP. Because these calls usually do not amount to more than 5% or 10% of the overall call volume, it is easy to overlook them.

The definitions of these call states differ somewhat from the definitions used for port licensing purposes (see Licensing, page 15-1). The use of automatic speech recognition (ASR) or text-to-speech (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 Unified CCE agents or ACD agents, nor does it matter whether the customer intends to use Unified CVP's ability to retrieve and re-deliver the call to another agent or back into self-service. Note that the solution must be sized for the number of ports in use for calls in a talking state to agents. Even though licenses for those ports do not have to be purchased when using Unified CCE agents, TDM agents do require a Call Director license.

In addition to the overall snapshot profile of calls in the contact center, you must also consider the busiest period call arrival rate in terms of calls per second. You will need this information for the contact center as a whole. Because it is hard to identify a true maximum arrival rate, you can use statistical means to arrive at this number. Except in fairly small implementations, this is seldom the critical factor in determining sizing.

With the above data, you can begin sizing each component in the network. This section next considers the Unified CVP products: Call Server and Unified CVP VXML Server followed by the Unified Presence Server and Unified CVP Reporting Server. This section deals entirely with the number and type of physical components required to support the Unified CVP system, but it does not include any discussion of redundancy. For an understanding of how to extend these numbers to support higher reliability, see Designing Unified CVP for High Availability, page 4-1.

Unified CVP Call Server


Note The Unified CVP Call Server is not used in Model #1: Standalone Self-Service. This section does not apply to such deployments.


Unified CVP Call Servers are sized according to the number of calls they can handle, in addition to their maximum call arrival rate.

Each Unified CVP Call Server can handle 850 SIP calls or 500 H.323 calls. Each Unified CVP Call Server is further limited to a sustained call arrival rate of 7 calls per second (cps). However, Model #4 is exempt from this limitation because the Unified CVP Call Server in that model does not perform any H.323 or SIP processing.

Specifically, the number of Unified CVP Call Servers required is the larger of:

((Self Service) + (Queue and Collect) + Talking) / 850 [or 500 for H.323], rounded up

or

(Average call arrival rate) / 7, rounded up [except in Model #4]

If you have a Call Server servicing both SIP and H.323 calls, you can size the server by prorating the performance used for each call type. For example, if 60% of the calls will be H.323 and 40% SIP, the maximum load in terms of active calls in this case will be:

60% * (500 H.323 calls) + 40% * (850 SIP calls) = 640 active calls

In addition, calls delivered to the Cisco Unified Communications Manager cluster should be load-balanced among the subscribers in the cluster and should not exceed 2 calls per second (cps) per subscriber.

Unified CVP VXML Server

Unified CVP VXML Server sizing with HTTP is simple: one Unified CVP VXML Server can handle up to 750 calls. If you are using Unified CVP VXML Servers, you should size those machines according to the following formula:

Calls / 750, rounded up,

where Calls refers to the number of calls that are actually in Unified CVP VXML Server self-service applications at that busy moment snapshot in time.

Unified CVP can also be configured to use HTTPS on the Unified VXML Server and on the Unified CVP IVR Service. (IVR Service can generate very basic VoiceXML documents and is part of the Unified CVP Call Server.) Due to the large processing overhead of HTTPS, the Tomcat application server can achieve a maximum of only 100 simultaneous connections, depending on the configuration. In addition, the following design guidelines apply:

Unified CVP VXML Server with WebSphere in a Standalone model can support up to 250 calls.

Unified CVP VXML Server with Tomcat in a Standalone model can support up to 100 calls.

Unified CVP Comprehensive call flow model using Unified CVP Call Server and Unified CVP VXML Server with WebSphere can support up to 100 calls.

Unified CVP Comprehensive call flow model using Unified CVP Call Server and Unified CVP VXML Server with Tomcat can support up to 100 calls.

In all of the above scenarios, the Reporting and Datafeed options were disabled. Also note that:

Cisco IOS Release 12.4(15)T5 or later release is required on the gateway to support the HTTPS option. (Mainline Cisco IOS currently is not supported.)

The HTTPS option has not been tested with co-resident Unified CVP Call Server and Unified CVP VXML Server and hence is not a supported configuration.

Cisco recommends the following configuration on the Cisco IOS VoiceXML Gateway with HTTPS option. Not having this configuration setting can severely impact the performance and sizing of the VXML gateway and the overall solution in general with HTTPS.

http client connection persistence
http client cache memory pool 15000
http client cache memory file 1000

Unified CVP Co-Residency

The following components can be installed on the same physical server (co-resident):

Unified CVP Call Server

Unified CVP VXML Server

Media Server

A SIP-based co-resident server can handle 750 SIP calls as well as 750 Unified CVP VXML Server sessions simultaneously, and it can handle a sustained call arrival rate of 6 calls per second. An H.323 co-resident server can handle 500 H.323 calls as well as 500 Unified CVP VXML Server sessions simultaneously, and it can handle a sustained call arrival rate of 6 calls per second.

The number of Unified CVP Call Servers required is the larger of:

((Self Service) + (Queue and Collect) + Talking) / 750 [or 500 for H.323], rounded up,

or

(Average call arrival rate) / 6, rounded up, except in the VRU-only model

The co-resident media server can be used for up to 750 calls [or 500 for H.323], assuming that prompt caching is enabled in the VoiceXML gateways. If multiple co-resident servers are to be used, you must load-balance across the co-resident media servers in order to spread the load of the calls across all of the servers. To reduce the administrative overhead of managing content on multiple media servers, separate dedicated media servers can be used.

This means you can run 750 ports of the Call Server with SIP call control, and 750 ports of the VXML Server, all on one server with 750 port licenses. An H.323 co-resident server can handle 500 H.323 calls as well as 500 Unified CVP VXML Server sessions simultaneously, and it can handle a sustained call arrival rate of 6 calls per second. This means you can run 500 ports of the Call Server with H.323 call control, and 500 ports of the VXML Server, all on one server with 500 licensed ports.

For example, assume that your deployment must be sized for 1200 self-service ports, 500 queue and collect ports, and 3700 simultaneous calls to agents.

Self-service means that a call requires SIP or H.323 call control and runs an application on the VXML Server. Queue and collect means that a call requires SIP or H.323 call control and runs an application using Microapps only on the Call Server.

The following example applies for VXML and HTTP sessions only.

Hence, the number of servers required in the co-resident model using SIP call control would be as follows:

((Self Service) + (Queue and Collect) + Talking) / 750 [or 500 for H.323], rounded up

((1200) + (500) + 3700) / 750 = 8 servers

The number of servers required in a standalone model (that is, a deployment where the Call Server and VXML Server are separate instead of co-resident) using SIP call control would be as follows:

Call Servers

((Self Service) + (Queue and Collect) + Talking) / 850 [or 500 for H.323], rounded up

((1200) + (500) + 3700) / 850 = 7 servers

VXML Servers

Calls / 750

(1200) / 750 = 2 servers

Hence, in this case the standalone model would require a total of 9 servers whereas the co-resident model would require a total of only 8 servers.

The co-resident VXML model for the above formula supports a maximum of 750 SIP and 500 H.323 sessions.

If you use the Cisco Unified Border Element as a Session Border Controller (SBC) for flow-through calls to handle VXML requirements, then you must use the sizing information presented above. The Cisco Unified Border Element is limited to the maximum number of simultaneous VXML sessions or calls as outlined above for the particular situation and hardware platform.

If you use the Cisco Unified Border Element as an SBC to handle flow-through or flow-around calls only (no VXML), then take Voice Activity Detection (VAD) into consideration and refer to the sizing information in the Cisco Unified Border Element Ordering Guide, available at

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/order_guide_c07_462222.html

Co-Resident Reporting Server and Call Server

The Unified CVP Reporting Server can also be co-resident with the Call Server, but only for Standalone VoiceXML deployments. The Call Server is normally not needed in a Standalone VoiceXML deployment; but if reporting is desired, a Call Server is required in order to send the reporting data from the Unified CVP VXML Server to the Reporting Server. Thus, when the Unified CVP Reporting server is co-resident with a Call Server, the Call Server is not processing any SIP or H.323 calls but is simply relaying reporting data from the Unified CVP VXML Server.

The co-resident Call Server does not have a significant impact on performance in this model, therefore the sizing information in the section on the Unified CVP Reporting Server, does not change.

Unified Presence Server

The Cisco Unified Presence server is the SIP Proxy Server provided by Cisco for use with Unified CVP. Table 14-2 outlines the performance of the various server types.

 

Table 14-2 Call Handling Capacities for Cisco Unified Presence Servers 

Cisco Server Model
Recording Function
UDP
TCP

MCS-7825

Record-Route On

200 cps

100 cps

Record-Route Off

300 cps

300 cps

MCS-7835

Record-Route On

200 cps

100 cps

Record-Route Off

300 cps

300 cps

MCS-7845

Record-Route On

600 cps

200 cps

Record-Route Off

1100 cps

500 cps


The sizing numbers in Table 14-2 assume a dedicated SIP Proxy. If you are using the same Cisco Unified Presence server for presence services, you should adjust the numbers accordingly, based on the capacity used. For instance, if the Cisco Unified Presence server supports 2500 presence users but you will actually have only 1250 (50%), then that leaves approximately 50% of the SIP Proxy capacity.

The capacities in Table 14-2 are measured in calls per second (cps). However, one call coming in from the PSTN is not equivalent to one call through Cisco Unified Presence. Multiple calls are actually generated per inbound customer call for queuing, ringback, and subsequent agent transfers. A typical incoming call will be transferred by Unified CVP four times, so the inbound PSTN call rate should be multiplied by 4.

For example:

If Unified CVP receives 20 PSTN calls per second, Cisco Unified Presence will see about 80 calls per second.

Unified CVP Video Service

Cisco Unified CVP release 7.0 introduces capabilities for video self-service and queuing, integrated with video-capable agents of Cisco Unified Contact Center Enterprise (Unified CCE). Unified CVP video capabilities come in two forms: Full Video Service and Basic Video Service.

The same Unified CVP Call Server can be used to service both video calls and traditional audio calls, as long as the audio calls are handled using the Unified CVP comprehensive call flow. If any model other than the comprehensive model is used for the audio calls, then separate Unified CVP Call Servers must be used for the video and audio calls.

Sizing Unified CVP Basic Video Service

The Unified CVP Basic Video Service employs the Unified CVP Comprehensive call flow, and as such it requires the Unified CVP Call Server, the Unified CVP VXML Server, and VXML Gateways. Sizing of these components for the Basic Video Service is done in the same manner as for traditional audio applications.

Cisco Unified Videoconferencing hardware, Radvision IVP, and Radvision iContact are not required for the Basic Video Service.

Sizing Unified CVP Full Video Service

The Unified CVP Full Video Service requires the Unified CVP Call Server plus video-specific components such as Cisco Unified Videoconferencing hardware and third-party software from Radvision, Inc., including the Radvision iContact application and the Radvision Interactive Video Platform (IVP). Additional hardware such as 3G Gateways are also required for 3G mobile video solutions.

CVP Components

Sizing the Unified CVP Call Server for full-service video is done in the same manner as for traditional audio applications. In other words, the Unified CVP Call Server does not care whether a call is an audio call or a video call, therefore video sizing can be done the same way as audio sizing.

The Unified CVP VXML Server is not required for video-only deployments because the Unified ICM script editor is the only way to script and run Unified CVP video functionality. However, if a Unified CVP system needs to support both audio and video calls, then the Unified CVP VXML Server should be used, and it should be sized in the standard manner for the number of audio calls.

A Unified CVP Video Media Server supports up to 1500 agents connected to the web interface. Of those agents, the number of simultaneous video streams being played to the caller is limited as follows:

On a Cisco MCS 7845-H2

100% with caching: 850 simultaneous streams

100% without caching: 66 simultaneous streams

On a Cisco MCS 7825-H3

100% with caching: 425 simultaneous streams

100% without caching: 33 simultaneous streams

In addition, up to 10,000 media files and/or resources can be distributed across up to 5000 directories. Each subfolder counts as a directory.

Cisco Unified Videoconferencing Hardware

The following components are required for the Cisco Unified Videoconferencing hardware that terminates mixes video calls in the solution:

IPVC-3545-CHAS (the MCU chassis)

IPVC-3545-MCU (one MCU card required per chassis)

IPVC-3545-EMP (one EMP card required per chassis, with a maximum of two EMP cards allowed per chassis)

The minimum configuration consists of the MCU chassis, the MCU card, and one EMP card (also called an MVP card), and it supports up to 48 H.263 CIF video ports (or up to 96 H.263 QCIF video ports). Adding a second EMP/MVP card to the chassis increases the capacity up to 96 H.263 CIF video ports (H.263 QCIF capacity remains at 96 ports even with the second EMP/MVP card). Note that a deployed video service must be in either the CIF video format (in which QCIF endpoints such as 3G mobile phones are treated like CIF endpoints for MCU sizing purposes) or the QCIF video format. The different formats cannot be mixed as part of the same video service deployment.

Video capacity can be increased beyond this size by adding additional MCU chassis (each with one MCU card and one or two EMP/MVP cards). All MCUs are managed as a pool of media resources by the Radvision IVP controller. When a new call is received, the Radvision IVP can select any of the MCUs it manages to service the call, based on resource availability.

MCU video ports are consumed by all of the following:

Video caller

Video agents

Unified CVP or Radvision playing video to the caller

Agent playing video to the caller

Video session being recorded

Video ports are allocated and de-allocated as necessary during the life of a call. The following examples illustrate how many MCU video ports are required in different video call scenarios:

A caller undergoing video self-service or video queuing consumes two video ports (one for the video caller and one for the video being played to the caller by Unified CVP or Radvision).

If the above session is recorded, then three video ports are consumed.

A caller and an agent having a video conversation consume two video ports. If this session is recorded, then three video ports are consumed.

If an agent plays a video to the caller, then three video ports are consumed. If this session is recorded, then four video ports are consumed.

If video agent #1 performs a blind transfer to video agent #2, two video ports are consumed while the caller is on hold (one for the caller and one for the on-hold video being played to the caller). Once agent #2 becomes available, two video ports are still consumed (one for the caller and one for agent #2). If agent #2 plays a video to the caller, or if the session is recorded, then additional video ports are consumed, as described above.

If video agent #1 performs a consultative transfer (by bringing on agent #2 while agent #1 stays on the call), three video ports are consumed (one for the caller, and one for each of the two video agents).

Other Software and Hardware

Sizing information for the Radvision IVP, iContact, and 3G Gateway products should be obtained from Radvision.

VXML Gateways are not required if the solution needs to support Full Service Video only. However, if a Unified CVP system needs to support both audio and video calls, then VXML Gateways are required for the audio calls, and they should be sized in the standard manner.

Unified CVP Reporting Server

There are many variables to take into account when sizing the Unified CVP Reporting Server. Different VoiceXML applications have different characteristics, and those characteristics play a large part in the amount of reporting data generated. Some of these factors are:

The types of elements used in the application

The granularity of data required

The call flow users take through the application

The length of calls

The number of calls

To size the Reporting Server, you must first estimate how much reporting data will be generated by your VoiceXML application. The example applications and the tables in subsequent sections of this chapter will help you to determine the number of reporting messages generated for your application.

Once you have determined the number of reporting messages generated by your application, complete the following steps for each VoiceXML application:

1. Estimate the number of minutes customers will spend receiving VoiceXML call treatment by that application.

2. Estimate the calls per second that the application will receive.

3. Estimate the number of reporting messages for your application.

Use the following equation to determine the number of reporting messages generated per second for each VoiceXML application:

A# = %CPS * CPS * MSG / Min / 60

Where:

A# = the number of estimated reporting messages per second for an application. Complete one calculation per application (A1, A2, ..., An).

CPS = the number of calls per second.

%CPS = the percentage of calls that use this VoiceXML application.

MSG = the number of reporting messages this application generates. To determine the number of reporting messages generated by your application, use the information provided in the sections on Reporting Message Details, and Example Applications.

Min = Amount of time spent in the application (in minutes).

60 = the number of seconds in one minute.

Next, estimate the total number of reporting messages that your deployment will generate per second by summing the values obtained from the previous calculation for each application:

A(total) = A1+ A2+.....+An

This is the total number of reporting messages generated per second by your VoiceXML applications. The Cisco MCS-7845 reporting servers can handle 420 messages per second. If the total number of reporting messages per second for your deployment is less than 420, you can use a single reporting server. If it is greater, you need to use multiple reporting servers and partition the VoiceXML applications to use specific reporting servers.

How to Use Multiple Reporting Servers

If the number of messages per second (as determined in steps 1 and 2 above) exceeds the reporting server capacity, then the deployment must be partitioned vertically.

When vertically partitioning to load-balance reporting data, a Unified CVP system designer must consider the following requirements that apply to deployments of multiple reporting servers:

Each Call server and each Unified CVP VXML Server can be associated with only one Reporting Server.

Reports cannot span multiple Informix databases.

For more information on these requirements, refer to the Reporting Guide for Cisco Unified Customer Voice Portal Release 7.0(1), available at

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

When designing Unified CVP deployments with multiple reporting servers, observe the following guidelines:

Subdivide applications that generate more combined call processing and application messages than are supported by one reporting server.

VoiceXML can be filtered, and filtering out non-interesting data creates more usable data repositories that support higher message volume.

Configure the dial plan and/or other available means to direct the incoming calls to the appropriate Call Server and Unified CVP VXML Server.

If you need to combine data from multiple databases, possible options may include:

Exporting reporting data to Excel, comma separated values (CSV) files, or another format that allows data to be combined out side of the database

Exporting reporting data to CSV files and importing it into a customer-supplied database

Extracting data to a customer-supplied data warehouse and running reports against that data

Reporting Message Details

Table 14-3 outlines the various elements or activities and the number of reporting messages generated by each.

 

Table 14-3 Number of Reporting Messages per Element or Activity 

Element or Activity
Number of Reporting Messages (Unfiltered)

Start1

2

End1

2

Subdialog_start1

2

Subdialog_return1

2

Hotlink

2

HotEvent

2

Transfer w/o Audio

2

Currency w/o Audio

2

Flag

2

Action

2

Decision

2

Application Transfer

2

VXML Error

2

CallICMInfo (per call)

2

Session Variable (per change)

2

Custom Log (per item)

2

Play (Audio file or TTS)

2

Get Input (DTMF)

5

Get Input (ASR)

9

Form

10

Digit_with_confirm

20

Currency_with_confirm

20

ReqICMLabel

30

1 These elements are required in every application and cannot be filtered.


Example Applications

This section presents some examples of applications that can be used to estimate the number of reporting messages that will be generated by your particular application.

Low Complexity

Total: 16 reporting messages per minute per call.

 

Element Type
Approximate Number of Reporting Messages

Start

2

Subdialog_strart

2

Play element

2

Play element

2

Play element

2

Play element

2

Subdialog_end

2

End

2


Medium Complexity DTMF Only

Total: 39 reporting messages per minute per call.

 

Element Type
Approximate Number of Reporting Messages

Start

2

Subdialog_strart

2

Play element

2

Get input

5

Play element

2

Get input

5

Form

10

Input

5

Transfer with audio

2

Subdialog_end

2

End

2


Medium Complexity Using Automatic Speech Recognition (ASR)

Total: 51 reporting messages per minute per call.

 

Element Type
Approximate Number of Reporting Messages

Start

2

Subdialog_strart

2

Play element

2

Get input

9

Play element

2

Get input

9

Form

10

Input

9

Transfer with audio

2

Subdialog_end

2

End

2


High Complexity Using Automatic Speech Recognition (ASR)

Total: 107 reporting messages per minute per call.

 

Element Type
Approximate Number of Reporting Messages

Start

2

Subdialog_strart

2

Icmrequrestlabel

30

Form

10

ASR capture

9

Digit with confirm

20

Form

10

Digit with confirm

20

Subdialog_end

2

End

2