-
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
-
Preface
-
Unified CVP architecture
-
Functional deployment models
-
Distributed deployments
-
Unified CVP design for high availability
-
Cisco Unified ICM interactions
-
Calls originated by Cisco Unified Communications Manager
-
Gateway options
-
Unified CVP VXML server design implications
-
Network infrastructure considerations
-
Call transfer options
-
Media file options
-
Managing, monitoring, and reporting functions
-
Sizing
-
Index
-
Feedback
Contents
- Sizing
- New or changed chapter information
- Overview
- Unified CVP Call Server
- Call Server Sizing for Agent Greeting
- Call Server Log Directory Size Estimate
- Unified CVP VXML Server
- VXML Gateway Sizing for Agent Greeting
- VXML Gateway Agent Greeting Prompt Cache Sizing
- Media Server Sizing for Agent Greeting
- Unified CVP co-residency
- Cisco Unified SIP Proxy
- Unified CVP video service
- Basic video service sizing
- Unified CVP Reporting Server
- Multiple Reporting Servers
- Reporting message details
- Example applications
Sizing
This chapter discusses how to determine how many physical machines to order and, in the case of gateways, what kind to order.
- New or changed chapter information
- Overview
- Unified CVP Call Server
- Unified CVP VXML Server
- Media Server Sizing for Agent Greeting
- Unified CVP co-residency
- Cisco Unified SIP Proxy
- Unified CVP video service
- Unified CVP Reporting Server
New or changed chapter information
The following table lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.
Table 1 New or Changed Information Since the Previous Release of This Document Updated content related to features not supported for Unified CVP 9.0(1) such as Content Service Switch (CSS), Cisco Unified Presence Server (CUPS) Gatekeeper, H.323, co-residency, IBM WebSphere, Microsoft Windows Server 2003
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 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 using 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 are counted as talking calls.
However, if the call was transferred through *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 are not 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, using 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 from the definitions used for port licensing purposes. The use of automatic speech recognition (ASR) or text-to-speech (TTS) has nothing to do with delineating which calls are in which state, as 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 the Unified CVP to retrieve and re-deliver the call to another agent or back into self-service.
NoteThe 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 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 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 Unified CVP design for high availability.
NoteIn Unified CVP 9.0(1), the Call Server, VXML Server, and Media Server are combined as one installation. Installing the CVP Server will install all three components. In the earlier versions, Call Server, VXML Server, and Media Server could be installed on different machines.
Unified CVP Call Server
Note
The Unified CVP Call Server (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.
Note
For UCS performance numbers, refer to the Cisco doc-wiki link: http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CVP
Note
The following Example Call Server call rate calculations pertain to the MCS-7845-I3-CCE2 server.
Each Call Server can handle 1200 SIP calls. Each Call Server is further limited to a sustained call arrival rate of 14 call per second (cps) for SIP. However, Model #4 is exempt from this limitation because the Call Server in that model does not perform any SIP processing.
Specifically, the number of Call Servers required is the larger of:
((Self Service) + (Queue and Collect) + Talking) / 1200, rounded up
or
(Average call arrival rate) / 14, rounded up.
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.
Call Server Sizing for Agent Greeting
When using the Agent Greeting feature, performance of Unified CVP Call Servers is reduced by 25%(The servers operate at 75% of calls per second (CPS) of a system not using the Agent Greeting feature).
Size your system using the methods detailed in the guide, then multiply the CPS by 75%:
- For example, 10 CPS on a UCS platform without Agent Greeting translates into 7.5 CPS on a Call Server with Agent Greeting enabled.
- Ports required are calculated based on the CPS and duration of agent greeting, and must be accounted from the total supported ports of a server.
NoteThe Agent Greeting feature is only supported with SIP, and is not supported with H.323.
Call Server Log Directory Size Estimate
Use the following formula to calculate the estimated space per day (in Gigabytes) for the Call Server Directory log file.
3.5 * R
Where: R = number of calls per second
For proper serviceability, reserve enough space to retain from 5 to 7 days of log messages.
To set the log directory size, refer to the Operations Console, Infrastructure tab for Call Server set up.
Unified CVP VXML Server
VXML Server call rate calculations are shown in the table and examples below.
Note
The following VXML Server example call rate calculations pertain to the MCS-7845-I3-CCE2 server.
Unified CVP VXML Server sizing with HTTP is simple: one Unified CVP VXML Server can handle up to 1200 calls. If you are using Unified CVP VXML Servers, you should size those machines according to the following formula:
Calls / 1200, 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.
Note
For UCS performance numbers, refer to the Cisco doc-wiki link: http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CVP
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.
Table 2 provides simultaneous call information for HTTPS calls using various applications and call flow models.
Note
For UCS performance numbers, refer to the Cisco doc-wiki link: http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CVP
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.)
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 1000VXML Gateway Sizing for Agent Greeting
The additional gateway VXML ports required are calculated based on CPS and the duration of the agent greeting. The agent greeting is counted as one additional call to the VXML gateway.
Use the following formula to determine the additional ports required for the Agent Greeting feature:
Total ports = Inbound ports + [ ( Agent Greeting Duration / Total call duration ) * Inbound ports ]For example, if you estimate 120 calls, each with a 60 second call duration, then this gives you 2 CPS and a requirement of 120 inbound ports. If you assume that the agent greeting duration is 5 seconds on every call, then the overall calls per second is 4 CPS, but the number of ports required is 130
Total Ports = 120 inbound ports + [(5 second agent greeting duration / 60 second total call duration) * 120 inbound ports] = 130 total ports.VXML Gateway Agent Greeting Prompt Cache Sizing
When sizing agent greeting prompt cache, consider the following example:
The following calculation shows that a 1 minute long file in the g711uLaw codec uses approximately 1/2 MB:
64 Kbits/sec = 8 Kbytes/sec (bit rate for g711uLaw codec) 8 Kb/sec * 60 seconds - 480 Kb (~ 0.5 MB)
- The maximum memory used for prompt cache in IOS router is 100 MB and the max recommended size of a single file should not exceed 600 KB
- Number of Agent Greetings cached using the above sizing numbers are given below:
5 second greeting - 40 KB i.e. ~25 greetings per MB. This typical use case scenario provides caching for approximately 80*25 agent = 2000 agents with 80% space reserved for Agent Greeting.
60 second greeting - 480 KB i.e. ~2 greeting per MB. The worst case scenario provides caching for approximately 50*2 agent = 100 agents with 50% space used for Agent Greeting.
Media Server Sizing for Agent Greeting
Media Server sizing is typically not provided due to the diverse requirements of a media server based on very specific deployment requirements, and because a wide range of hardware is used for media servers.
However, the following sizing profile is for a Media Server used with the Agent Greeting feature.
Unified CVP co-residency
Note
The following call rate calculations pertain to the MCS-7845-I3-CCE2 server.
The following components can be installed on the same physical server (co-resident):
A SIP-based co-resident server can handle 1200 SIP calls as well as 1200 VXML Server sessions simultaneously, and it can handle a sustained call arrival rate of 14 calls per second.
Note
This means you can run 1200 ports of Call Server doing SIP call control, and 1200 ports of VXML Server on one server with a 1200 port license.
The number of Unified CVP Call Servers required is the larger of:
((Self Service) + (Queue and Collect) + Talking) / 1200, rounded up,
or
(Average call arrival rate) / 14, rounded up, except in the VRU-only model
The co-resident media server can be used for up to 1200 calls, 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 1200 ports of the Call Server with SIP call control, and 1200 ports of the VXML Server, all on one server with 1200 port licenses.
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.
Note
In the above example definition, self-service means that a call requires SIP call control and runs an application on the VXML Server. Queue and collect means that a call requires SIP call control and runs an application using Microapps only on the Call Server.
The following example applies for VoiceXML and HTTP sessions only. The same values apply to both co-resident and distributed deployments of Call Servers and VXML Servers.
The number of servers required using SIP call control would be as follows:
((Self Service) + (Queue and Collect) + Talking) / 1200, rounded up
((1200) + (500) + 3700) / 1200 = 5 servers
If you use the Cisco Unified Border Element as a Session Border Controller (SBC) for flow-through calls to handle VoiceXML requirements, then you must use the sizing information presented above. The Cisco Unified Border Element is limited to the maximum number of simultaneous VoiceXML 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 calls only (no VoiceXML), then take Voice Activity Detection (VAD) into consideration and see the sizing information in the Cisco Unified Border Element Ordering Guide, available at:
Co-Resident Unified CVP Reporting Server and Unified CVP Call Server
The Unified CVP Reporting Server can also be co-resident with the Unified CVP 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 VXML Server to the Reporting Server. Thus, when the Reporting Server is co-resident with a Call Server, the Call Server is not processing any SIP calls but is simply relaying reporting data from the 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.
Note
If Unified Border Element is to be used as an SBC to handle flow-thru or flow-around calls only (no vxml), with VAD in consideration, we can use the Unified Border Element Ordering Guide for sizing.
Note
If Unified Border Element is to be used as an SBC for flow-thru or flow-around calls AND is to handle vxml requirements, we must use the sizing information in the CVP SRND. Unified Border Element will be limited to the maximum number of simultaneous vxml sessions\calls as outlined there for the particular situation and hardware platform.
Cisco Unified SIP Proxy
Starting with Unified CVP 9.0(1) only Cisco Unified SIP Proxy (CUSP) server is supported.
Information on CUSP architecture, feature, configuration, and data sheets is available at http://wwwin.cisco.com/artg/products/voice_video/cusp/.
The CUSP baseline tests were done in isolation on the proxy, and capacity numbers (450-500 cps) should be used as the highest benchmark, and most stressed condition allowable. In a Unified CVP deployment, a CUSP proxy would typically see incoming calls from the TDM gateway, from Unified CVP itself, and from the UCM SIP Trunk. With a SIP back-to-back user agent in CVP, the initial call setup from the proxy perspective will entail an inbound call immediately followed by an outbound call (whether for IVR or to ACD). Later in the call, for example mid-way in the call, CVP may transfer the call to an agent, which entails an outbound leg, and reinvites to the inbound leg. There is also a ringtone service setup which also entails a separate outbound call and a reinvite to the caller. Reinvites on the caller leg occur at CVP transfer or during supplementary services.
NoteThe performance numbers published are with Record- Route enabled. The performance numbers will reduce if Record-Route is disabled. Cisco does not recommend Record-Route to be enabled.
A CVP call, from the proxy server perspective, entails on average, 4 separate SIP calls:
The rule of thumb for Unified CVP and CUSP proxy sizing is to define 4 SIP calls for every 1 CVP call, so the CPS rate will be 500 / 4 = 125. The overall number of active calls is a function of Call Rate (CPS) * call handle time (CHT). Assuming an average call center call duration of 180 seconds (CHT), we will get an overall active calls value of 22,500 calls. As one Call Server can handle approximately 1200 simultaneous calls, this would all allow a single CUSP proxy to handle the load of 18 CVP Call Servers, in this scenario. A real world customer deployment will need to take into account the CPS and the CHT in order to size the proxy for their solution.
Unified CVP video service
Cisco Unified CVP release 7.0 introduced capabilities for video-capable agents of Cisco Unified Contact Center Enterprise (Unified CCE).
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 Call Servers must be used for the video and audio calls.
Basic video service sizing
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 VoiceXML 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.
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 is generated by your VoiceXML application. The example applications and the tables in subsequent sections of this chapter 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:
- Estimate the calls per second that the application receives.
- 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
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.
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.
Multiple Reporting Servers
If the number of messages per second (as determined in steps 1 and 2 above) exceeds the Unified CVP Reporting Server (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 Unified CVP Call server and each Unified CVP VXML Server can be associated with only one Unified CVP Reporting Server.
- Reports cannot span multiple Informix databases.
For more information on these requirements, see the Reporting Guide for Cisco Unified Customer Voice Portal, available at:
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 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
