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
New or Revised Topic
July 6, 2012
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
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:
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.
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.
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 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.
In 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
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.
Table 2 Call Server Call Rate by Server Model Number
The following Example Call Server call rate calculations pertain to the
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
Specifically, the number of Call Servers required is the larger
((Self Service) + (Queue and Collect) + Talking) / 1200, rounded up
(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.
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.
The 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
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
Table 3 VXML Server Call Rates by Server Model Number
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
provides simultaneous call information for HTTPS calls using various
applications and call flow models.
Table 4 HTTPS Simultaneous Calls for Unified CVP Servers
Unified CVP Call Server Type, Application, and Call Flow
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
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.
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:
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.
15 second greeting (118Kb greeting file)
30 minute content expiration
Media Server hardware equivalent to the following (or better) is required to handle the above profile:
MCS-7825-H1 with RAID 0 (media server only)
MCS-7825-I4 with Raid 1 (media server only)
MCS-7845-H2 with RAID 1 (co-located media/call server)
Unified CVP co-residency
The following call rate calculations pertain to the MCS-7845-I3-CCE2
The following components can be installed on the same physical
Unified CVP Call Server (Call Server)
Unified CVP VXML Server (VXML Server)
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.
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
(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
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
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.
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
((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
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
Unified CVP Reporting Server,
does not change.
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.
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
Cisco Unified SIP Proxy
Starting with Unified CVP 9.0(1) only Cisco Unified SIP Proxy (CUSP) server is supported.
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.
The 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:
Caller inbound leg
VXML outbound leg
Ringtone outbound leg
Agent outbound leg
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.
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
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.