Cisco Unified Communications Sizing Tool Tutorial
Introducing the Unified Capacity Sizing Tool
The Cisco Unified Communications Sizing Tool (Unified CST) builds on earlier sizing and capacity planning tools to size the servers required to implement various Unified Communications deployments.
In this tutorial, a new Unified Communications solution is sized for an imaginary company called Bonjour Networks, which is a European company that manufactures semiconductors, with its head office in Paris (see Figure 1-1).
Figure 1-1 Bonjour Networks
The first step is to assess the geographical distribution of customer offices and the overall architecture that the customer plans to implement for their Unified Communications solution. There are various deployment types, each of which requires a slightly different application of the Unified CST (see Table 1-1).
Table 1-1 Unified Communications Deployment Types
How to Size the System
Create a single system with all users located in the same physical location.
Multi-site with centralized call processing
Create a single system that satisfies the needs of users at the central headquarters site as well as the requirements of users at branch sites.
Multi-site WAN with distributed call processing
Create a system using multiple clusters, with each cluster located at a different site and interconnected using IP-based trunks.
Clustering over the IP WAN
Create the components of a single cluster distributed geographically and interconnected through the IP WAN. This helps achieve geographical diversity and supports business continuance when one of the sites is unavailable.
Bonjour Networks is growing fast and becoming an international company. Last year, they merged with SomeCompany, located in Germany (see Figure 1-2).
Figure 1-2 Bonjour Networks Merging with SomeCompany
SomeCompany is already supported by a single Unified Communication Manager cluster. Rather than supporting Bonjour Networks on the same cluster, Bonjour Networks has decided to implement a new cluster at their Paris headquarters and to use their network to interconnect the two clusters.
Therefore, the new cluster to be deployed in Paris must be sized, including the inter-cluster links to the existing cluster in Frankfurt. Paris is a multi-site deployment with centralized call processing. With the addition of Frankfurt, Paris becomes a multi-site deployment with distributed call processing. For the purposes of this exercise, this implementation is treated as a multi-site deployment with centralized call processing (see Figure 1-3).
Figure 1-3 Multi-site Deployment with Centralized Call Processing
The main office of Bonjour Networks is located in Paris, with 16 branches located across France. The three closest branch offices are located in Reims, Rouen, and Orleans (see Figure 1-4).
Figure 1-4 Bonjour Networks—Three Closest Branch Offices
The branch offices are connected to the main office through a wide area network (WAN). Voice traffic carried by the corporate IP network is referred to as "on-net" traffic.
Bonjour Networks also has a large branch office in New York with 500 employees, and it requires Cisco Emergency Responder to satisfy local emergency calling requirements (see Figure 1-5).
Figure 1-5 Bonjour Networks—New York Branch Office
All intra-cluster traffic within the headquarters site, within each branch site, and between branch and headquarters will be on-net to reduce PSTN tariffs. Traffic between the Paris cluster and the cluster in Frankfurt is called inter-cluster traffic, and is also on-net. Other traffic to locations outside the company is over the PSTN, and is called "off-net".
This cluster will support roughly 13,000 employees. Because of the recent merger, the depreciation of equipment, and the need for increasing modes of communication, Bonjour Networks will replace their multiple PBX system with a centralized call processing and voice messaging system, and will add mobility and conferencing.
Six months from now, Cisco Unified Contact Center will be added to support their technical support and order processing departments.
Using the Cisco Unified CST
This chapter describes how to get started using the Cisco Unified CST and how to perform basic system sizing using the sample scenario. This chapter includes the following topics:
• Getting Started
• Using the Deployment Model Tab
• Using the Endpoints Tab
• Using the Traffic Mix Tab
• Using the Dial Plan Tab
• Using the Applications Tab
• Using the Media Tab
• Using the Output Tab
• Using the Cisco Emergency Responder Page
• Using the Voice Messaging Page
• Using the Conferencing and Collaboration Page
• Using the Gateways Section
• Understanding the Solution Sizing Summary
• Copying A Solution
To start sizing the new solution, we perform the following steps:
Step 1 To get started, we direct our web browser to the Unified CST website (see Figure 2-1) at the following URL:
Figure 2-1 Unified CST
The Unified CST fully supports Microsoft Internet Explorer 6.0 and Mozilla Firefox 2.x. Other browsers are not fully supported.
Step 2 On the login screen, we provide our Cisco.com credentials.
Access to the Unified CST is limited to Cisco employees and authorized channel partners.
After entering valid credentials, the tool displays the My Solutions screen (see Figure 2-2).
Figure 2-2 My Solutions Screen
The My Solutions screen displays a list of previously saved solutions, including the name, description, the type of solution, when the solution was last updated, as well as the status of the solution.
We can filter the display of previously saved solutions by clicking the type of solution we want to see.
For more information on tool features and navigation, consult the user guide by clicking the Help Book button, or click Training to access the Introduction to the Unified Communications Sizing Tool on-demand video.
Step 3 Click New Solutions at the top of the My Solutions screen.
The New Solutions Sizing screen appears, as shown in Figure 2-3.
Figure 2-3 New Solution Sizing Screen
Step 4 In the New Solution Sizing screen, provide the following:
a. Name for the solution
b. Description if one is needed
c. Country of deployment
The Sizing Scenario screen appears, as shown in Figure 2-4.
Figure 2-4 Sizing Scenario Screen
The Unified CST can perform sizing in three ways:
• System Release Sizing—Based on Unified Communications system releases, this is the generally the best choice for new deployments.
• Compatible Components Sizing—Based on compatibility with Unified Communications products, this is generally best for existing implementations.
• Individual Product Sizing—This is best when sizing individual products rather than an entire system.
Step 5 Because Bonjour Networks requires a new deployment including more than Unified Communications Manager, select System Release Sizing.
The tool displays the Components screen, as shown in Figure 2-5.
Figure 2-5 Selecting Components to Include in Sizing Calculations
The Components page lets us select the components to include in the sizing calculations.
Step 6 In the Components page, do the following:
a. Keep the default for the System Release version.
b. For the initial deployment required by Bonjour Networks, select each component except for Unified Contact Center Enterprise, which we will be implementing and sizing later.
c. Click Continue to proceed. Note that the Continue button automatically saves the solution.
After we create a new solution and select the needed components, the tool displays a series of pages that let us describe the solution we want to size. The solution navigation menu, on the right-hand side of the application, lets us navigate to any component at any time.
The component navigation menu (tab navigation bar) in the upper-center pane of the application, lets us navigate to any of the available questionnaires for the currently selected component. The currently selected questionnaire always appears in the center pane. Additional information about each entry is provided through context-sensitive online help. To view the online help, click the small question mark to the right of each entry.
Using the Deployment Model Tab
Figure 2-6 shows the Deployment Model tab.
Figure 2-6 Unified CM Deployment Model Tab
The Deployment Model tab gathers information that the tool uses for determining the Unified CM resources that are required, such as the number of servers and clusters. To fill out the Deployment Model page for our sample deployment scenario, we complete the following steps:
Step 1 Allow the default values for the following fields, which are the same as the configuration defaults found in an actual Unified CM server:
• CUCM trace level
Step 2 For the Database Complexity option, select Complex.
The choice we make for database complexity depends on the number of end points. The general guideline here is that any system with more than 10,000 endpoints should be considered to have a complex database.
Note In general, when not sure of the customer requirements, check the more demanding options (Detailed, Complex, and CDR/CMR On). The tool then allocates CPU resources that it considers adequate for these system functions. Note that the Frequently Asked Questions (FAQ) document offers more details about how to select these options.
Step 3 In the Locations field, type 18.
Bonjour Networks requires 18 call admission control locations; one for each branch and one for the headquarters.
Step 4 In the Regions field, type 36.
Bonjour Networks requires two regions per branch. One region is required per branch to accommodate fax traffic and one region for voice traffic.
Step 5 In the Device Pools field, type 42.
Bonjour Network headquarters requires eight device pools, and two device pools will be configured in each of the branch offices.
Step 6 Click Continue to move forward to the Endpoints tab.
Pressing Continue or navigating to a different questionnaire by using the solution or component navigation menu automatically saves our entries.
Using the Endpoints Tab
The Endpoints tab lets us enter the number of endpoints for each protocol, the dialing method used by each phone, the security profile, and the video capabilities (see Figure 2-7).
Figure 2-7 Endpoints Tab
To ensure accuracy, we determine the type of phones needed for the various types of employees, which can include managers, staff, administrators, shift workers, and also phones found in different locations, such as conference rooms, break rooms, lobbies, and so forth. We have worked out these quantities by doing an audit of the existing phones, and adjusted it for areas where the needs have changed. A simple spreadsheet was created (see Figure 2-8), and from these figures, we can provide the tool with the required information.
Figure 2-8 Endpoints Spreadsheet
This information helps the tool calculate resource utilization for static memory and traffic distribution.
The types of phone chosen for Bonjour Networks depend on engineering and functionality requirements. The various input fields allow the tool to accommodate any mix of phone protocol, security, and dialing approach. For information about the various choices available, see the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 7.x at the following URL: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/uc7_0.html.
For the Number of Users field, we need to enter the maximum number of users active during the busy hour, which is considered the hour of the day that has the highest amount of call activity. In this case, we need to determine the highest number of staff or shift workers that are using the voice network simultaneously during the hour of greatest overall voice network activity.
Bonjour Networks is a new installation, and wishes to use industry-standard SIP endpoints with KPML dialing. From our spreadsheet, we know that Bonjour Networks needs a total of 11,942 phones. Of these, 2,100 phones will be secure and another 1,500 will support secure video capabilities. 90 conference room phones, using the SCCP protocol, are needed. Non-secure phones include 7714 audio-only phones, and an additional 500 with video capabilities. 38 ATAs will be used to support analog phones. Therefore, we will use 11942 as the number of users.
Click Continue to save these entries and move to the Traffic Mix tab.
Using the Traffic Mix Tab
Figure 2-9 shows the Traffic Mix tab.
Figure 2-9 Traffic Mix Tab
In the Traffic Mix tab, we need to determine the expected traffic load and the average duration of calls during the busiest hour of call activity.
This value ultimately has an impact on system sizing and is used to determine the actual value of BHCA for incoming and outgoing calls to and from the PSTN, calls between clusters, or inter-cluster and intra-cluster calls.
The default average BHCA of four call attempts per hour is a good estimate. We keep the default setting of Moderate BHCA, Moderate ACHT, but 3 minutes of Average Call Holding Time (ACHT) is too long, based on the historical statistics obtained from the PBX records. Therefore, we will change ACHT to 2 minutes.
In the "Traffic Split Scenario" field, we will select Balanced On-Net Off-Net. In our scenario, the on-net traffic is a little higher than off-net traffic, but we can make the necessary adjustment in the next screen that appears. The other options (Predominantly On-Net and Predominantly Off-Net) are intended for situations where almost all of the traffic is of one type.
Figure 2-10 shows the section of the Traffic Mix tab that focuses on busy hour calls made to and from the PSTN.
Figure 2-10 PSTN BHCA—Initial Display with Balanced On-Net and Off-Net Traffic Option
Because we selected Balanced On-Net Off-Net, half of our calls are assumed to be off-net, with 25 percent of the calls coming from the PSTN and 25 percent going to the PSTN. The tool assumes the use of MGCP gateways for 100 percent of PSTN calls.
However, for Bonjour Networks, we expect only 40 percent of the calls to be off-net. Therefore, we update these fields by typing 20 percent in the first two fields. The system changes the display again, as shown in Figure 2-11.
Figure 2-11 PSTN BHCA Section
If we change the percentage of BHCA, the BHCA input fields turn red until we change the values and the combined total again equals 100 percent.
Bonjour Networks expects 30 percent of their traffic between the cluster in Paris and the cluster in Frankfurt. Therefore, we type 15 percent in the first two fields in the Inter-cluster BHCA section, as shown in Figure 2-12.
Figure 2-12 Inter-cluster BHCA Section
The remaining 30 percent will be intra-cluster calls. All intra-cluster calls will be IP-to-IP. Therefore, we type 30 percent in the first field in the Intra-cluster BHCA section, as shown in Figure 2-13.
Figure 2-13 Inter-cluster and Intra-cluster BHCA
When the total BHCA is equal to 100 percent, the error condition is removed and the fields turn black.
Click Continue to save these settings and move to the Dial Plan tab.
Using the Dial Plan Tab
Figure 2-14 shows the Dial Plan tab.
Figure 2-14 Dial Plan Tab
For each protocol, we need to determine how many directory numbers will be CTI controlled. This information is used to calculate CPU requirements and, for deployments of more than 2500 directory numbers, how many servers and/or clusters are required.
If we are not sure how many CTI-controlled directory numbers are required, we may want to either enter an estimate or skip this question until we have completed the Applications tab in a subsequent step, then come back later to provide the tool with quantities of CTI-controlled DNs.
In the Dial Plan tab, we copy the values suggested as defaults by the tool into the data entry fields for non CTI-controlled SCCP and SIP DNs.
Next, we need to calculate the total number of shared lines, including lines shared with a softphone, and the average number of phones on which each shared line will appear. This information is critical in determining the amount of memory and storage required. Shared lines will be used for our 22 lobby ambassadors and 18 security phones, resulting in a total of 40 DNs being shared. We have estimated that on average, three additional phones will share a single directory number.
Because the only SCCP phones in our system are the conference phones and their DNs are not shared with any other phones, we do not need to flag that lines will be shared between SIP and SCCP phones.
Knowing that we have one main site and 17 remote sites, we provide the tool with values for partitions and routes based on a total of 18 sites. For each site, we need one partition, five calling search spaces, and two translation patterns to accommodate a traditional calling search space approach to the dial plan, as documented in the SRND. Again for each of the 18 sites, we need five route patterns, five route lists, and five route groups per site. Figure 2-15 shows the results of these calculations for all the sites.
Figure 2-15 Partitions and Routes
These entries should be as precise as possible when considering systems with a large quantity of sites because the dial plan configuration may occupy a larger amount of system memory. The entries we provide here are nominal, and do justice to the scale of the system we are planning, because we are dealing with only 18 sites.
Click Continue to save these settings and move to the Applications tab.
Using the Applications Tab
Figure 2-16 shows the Applications tab.
Figure 2-16 Applications Tab
The Bonjour Networks sales department will require Extension Mobility. This department has approximately 700 employees. 500 employees will likely log in at the start of the day, and 400 will log in during the first five minutes of the morning. The peak of Extension Mobility usage will be during the five minutes in which 400 employees will log in, representing a maximum of 80 logins per minute.
4000 employees will use Cisco Unified Mobility and will have an average of one remote destination each (see Figure 2-17).
Figure 2-17 Extension Mobility
If we include Unified Communications Manager Assistant, Attendant Console, BLF Presence, or Contact Center agents, we need to calculate the quantity of CTI-controlled directory numbers required for these applications and add the resulting number of CTI-controlled DNs to the pre-existing CTI configuration in the Dial Plan tab.
Note Note that the CTI impact of WebDialer on system sizing is automatically accounted for by the tool; it is not reflected on the Dial Plan tab, and it does not need to be added manually to the Dial Plan tab.
Unified Communications Manager Assistant will be used by two assistants for each of the 45 managers, representing a total of 90 assistants. For the value of the Number of DNs on Unified CM Manager Assistant CTI Route Point field, we count each manager as a separate DN; this simplifies our design, but should not be taken as a best practice for all cases. Here, we input 45. We leave the default value of incoming BCHA at 4.
The main site will require ten Attendant Consoles, eight remote sites will require two consoles, and the remaining seven sites require one console, for a total of 33. All attendant consoles share a common pilot point within each site, for a total of 18 for this system. The average number of pilot point members is therefore approximately 2, and we accept 4 as the average BHCA (see Figure 2-18).
Figure 2-18 BHCA
Web Dialer and BLF Presence are not needed for this system. Unified Contact Center will be implemented in a later phase, so we leave the UCC Agents at default values, as shown in Figure 2-19.
Figure 2-19 Web Dialer, BLF Presence, and UCC Agents
We now calculate the CTI load that Unified Communications Manager Assistant and Attendant Console represent (see Figure 2-20), and add the result to the Dial Plan tab.
Figure 2-20 Calculating CTI-Controlled Lines
For Unified Communications Manager Assistant, each assistant will have two lines: one primary line, and one intercom line. Furthermore, each assistant will require one extra CTI connection to serve as a proxy to the manager they support. Thus each assistant requires three CTI connections, for a total of 270 CTI connections. The 45 managers each have one primary and one intercom line. This represents a total CTI load of 90 connections. The total CTI load for the 90 assistants and the 45 managers they support is 360.
For Attendant Console, each of the 33 attendant consoles will support an intercom, a personal, and a main business line. This represents a total of 99 CTI-controlled lines. All attendant consoles share a common pilot point within each site. This represents a total of 18 pilot points for our system. The total of all CTI-controlled lines for the use of attendant consoles is 117.
Now we can go back to the Dial Plan tab to add another 477 CTI-controlled directory numbers for CM Manager Assistant and Attendant Console, as shown in Figure 2-21.
Figure 2-21 Dial Plan Tab
Click Continue to save these settings and move to the Media tab.
Using the Media Tab
Figure 2-22 shows the Media tab.
Figure 2-22 Media Tab
Media resources such as Music On Hold (MoH) sources, conference bridges, and transcoders affect CPU utilization. Based on the value of the Total of non-transit BHCA field from the Traffic Mix tab, we need to estimate the percentage of busy hour calls for each type of media resource. We review the actual number of busy hour calls per media resource and make adjustments to our input until we are satisfied with the actual results.
Here, we assume 2 percent of the busy hour call attempts will require Music on Hold.
No transcoders will be configured because we have no applications supporting G.711 only. MTPs and RSVP agents will not be needed.
We estimate that 0.5 percent of calls will be conference calls until we can obtain further information. (See Figure 2-23.)
Figure 2-23 Media Tab—Percentage of Conference Calls
The value provided by the tool as "Actual" for the "Percentage of Calls Being Conferenced (Unscheduled Conferences)" field in Figure 2-23 is an indication of the quantity of ad-hoc conference calls during the busy hour.
Figure 2-24 Calculating Ad-Hoc Conferencing Resources
Assuming an Average Call Hold Time (ACHT) of three minutes for conference calls, we thus have approximately 3 times 200, or 600 total minutes of conference time to be held in the busy hour. This represents 10 Erlangs worth of conference traffic. Using an Erlang B calculator, and allowing for 0.1 percent blocking, we estimate Unified Communications Manager needs to accommodate 21 conference resources (see Figure 2-24).
Figure 2-25 Completed Media Resources Questionnaire
Note Note that this part of the tool is intended solely to model the call processing load imparted on CUCM by the ad-hoc conferencing traffic; the actual provisioning of the DSP resources needs to be reflected in the Bill Of Materials. The actual quantity of conferencing resources deployed in the system will likely be higher than our calculations show because we need to deploy them not only at the main headquarters site, but also at each of the 17 remote sites.
Click Continue to save these settings and move to the Output tab.
Using the Output Tab
Figure 2-26 shows the Unified Communications Manager Output tab.
Figure 2-26 Unified Communications Manager Output Tab
The Output tab displays the output of the sizing tool based on all the information we have submitted so far.
The tool assumes sizing based on MCS-7845 servers, with up to four server pairs to minimize the cluster count. Because the tool tells us that two server pairs are required, we have room to grow. Note that if we intended to limit cluster size to, for instance, one server pair, the cluster count goes up (see Figure 2-27).
Figure 2-27 Output Tab—Cluster Count
In addition, if we choose a lower grade of server, the cluster count goes up (see Figure 2-28). Note that for each permutation of server grade and cluster count, the resulting utilization figures show us how much of the cluster resources are taken up by the configured system load.
Figure 2-28 Output Tab—Cluster Count (2)
Because it is generally preferable to have fewer and more powerful servers, as well as to minimize the cluster count, we select high grade servers and allow up to four server pairs (see Figure 2-29).
Figure 2-29 Output Tab—Server Pairs
Had the output recommended more than one cluster, we would have had to initiate one sizing exercise per cluster. For example, if the tool had recommended two clusters, we would have separated the system load in two, and configured each cluster with its respective share of the total system load. Note that the distribution of the total load between the systems does not need to be absolutely equal. In the case of Bonjour Networks, we might use one cluster for the remote sites and one for the main site in Paris.
The warning message regarding GW Locations will be removed after we have added at least one gateway for each location.
We keep four server pairs for now. If the percentage of utilization is still low after adding the remaining products and components, we can either select a lower grade server or fewer pairs, and drive the utilization figures up.
Note that the Minimal Number of Unified CM Call Processing Server Pairs does not represent the total number of Subscriber servers but rather the total number of server pairs. The total number of servers, including the redundant servers, will be reflected in the Total Number of Servers. We have two call processing server pairs, or four servers, two TFTP servers, plus a publisher server, for a total number of seven servers (see Figure 2-30).
Figure 2-30 Utilization
Click Continue to save these settings and display the Cisco Emergency Responder page.
Using the Cisco Emergency Responder Page
Figure 2-31 shows the Emergency Responder page.
Figure 2-31 Cisco Emergency Responder Page
The Unified CST sizing tool assumes that there are no roaming phones and initially sizes Cisco Emergency Responder based on the total number of phones. We select a server type that provides adequate capacity utilization.
We are sizing Emergency Responder only for devices in the US branch, and we are assuming that no phones from the European sites will actually roam into the network of the US site. Therefore, we do not count any roaming phones. Furthermore, roaming phones are an issue only when multiple clusters are involved with more than one Emergency Responder group. When we have a single Emergency Responder group, it is responsible for discovering all telephony endpoints in all the access points into the network, so there is no such thing as a roaming phone in this situation.
The other fields indicate the relative usage of each dimension of the Emergency Responder group, which in this case is based on 7835 servers.
As shown in Figure 2-32, choosing a different server grade changes the relative percentage utilization of the Emergency Responder group.
Figure 2-32 Changing the Emergency Responder Server Type
Click Continue to save these settings and move to the Voice Messaging page.
Using the Voice Messaging Page
Figure 2-33 shows the Voice Messaging page.
Figure 2-33 Voice Messaging Page
For messaging, we determine our needs based on the Busy Hour value. If this is a new deployment and we are unsure of the needs of the user, we can start with the recommended default values and adjust later if required based on actual output.
Integration type will be SIP for 11,942 users during the busy hour. Because we have some empirical data from the existing PBX installation, we can readjust the default setting of 20% for the percentage of incoming calls redirected to voicemail during the busy hour to 13%. Because Bonjour Networks has SIP Unified Communication Manager to Unity over a SIP integration, we select No for the "Unity Failover Deployment" option. We leave the rest of the values at the defaults, as shown in Figure 2-34.
Figure 2-34 Voice Messaging Page—Input Section
The Voice Messaging (VM) system is sized based on requirements for both leaving and retrieving the messages. With IMAP, voicemail ports are not needed for retrieval. Therefore, the number of servers with IMAP is always less or equal to the number of servers without IMAP (see Figure 2-35).
Figure 2-35 Output
Click Continue to save these settings and move to the Conferencing and Collaboration page.
Using the Conferencing and Collaboration Page
Figure 2-36 shows the Conferencing and Collaboration page.
Figure 2-36 Conferencing and Collaboration Page
The Conferencing and Collaboration panel lets us identify the number of users with access to MeetingPlace and how often they will use conferencing during the busy hour. When considering the percentage of simultaneous audio users, we need to evaluate the proportion of users who will need to connect into conferences as opposed to attend conferences with other co-workers in the same room. When the majority of audio users are expected to dial in using a telephone (either on the network or from the PSTN), additional resources will be required to handle the load.
Concerning the Expected Top of the Hour Dial in Duration field, a burst or heavy call volume at the top of the hour can also be very costly because of the demand for call processing resources. If the duration of dial in is expected to be less than five minutes or if we are unsure, enter a shorter time duration and determine how Unified Communication Manager is affected.
Bonjour Networks is introducing MeetingPlace to key groups and will broaden the user base later. We will monitor the value of online collaboration for a year based on an increase in productivity and communication. Audio users will be located in all location types: off-net, on-net, and users dialing in from their desks or from conference rooms.
Most of our users are knowledge workers, so we use 5000 as the number of knowledge users.
This conferencing scenario choice estimates 5 percent audio users and 6 percent web users. We expect very few will use the video feature. Outlook and Lotus Notes will be integrated.
We believe that five minutes will be sufficient for the Expected Top of the Hour Dial-in Duration but we want to determine the impact when we enter three minutes. We accept the remaining default values. (See Figure 2-37.)
Figure 2-37 Completed Conferencing and Collaboration Questionnaire
In the Traffic Mix section, we split the total conferencing load among the different conferencing types (see Figure 2-38). We estimate that 20 percent of the participants will come in through MGCP gateways to accommodate home workers, traveling users, and customer participation during conferences. We estimate 20 percent will come from the German cluster through ICT trunks from Frankfurt, and 60 percent from IP phones controlled by the Paris-based cluster.
Figure 2-38 Conferencing Traffic Mix
The Output section displays the number of servers required to run applications, process calls, and host web conferencing (see Figure 2-39).
Figure 2-39 Output (Revised)
Note that the MP-3545 chassis can hold up to four total audio or video blades. If the quantity for MP-3545 were greater than 1, we would need our detailed design to consider the distribution of audio and video blades in the actual deployed chassis.
Now we can return to take a look at the updated utilization figures, after having added the conferencing load to our system. On the Unified Communications Manager Output page, we see that the Call Processing has reached approximately 74 percent (see Figure 2-40).
Figure 2-40 Unified Communications Manager—Output Tab, Utilization
Figure 2-41 shows the Utilization section before MeetingPlace was added.
Figure 2-41 Before MeetingPlace
These figures are based on having set the Expected Top of the Hour Dial in Duration to three minutes. Now we can see what happens if we change it to five minutes. We go back, change the value, and return here to see the increase relative to 74 percent (see Figure 2-42 and Figure 2-43).
Figure 2-42 Changing the Top-of-the-Hour Dial-in Duration (Conferencing and Collaboration)
Figure 2-43 Utilization (Revised)
As we can see, call processing has decreased by about 3 percent.
Using the Gateways Section
Figure 2-44 shows the Gateways Group 1 section with the default values.
Figure 2-44 Gateway Group 1
The number of gateway groups to be defined is based on the needs of the users in our network. When considering how many groups to create, we consider the common needs for groups of users.
For the headquarters site in Paris, we select a gateway type where port density is maximized. Also, Survivable Remote Site Telephony (SRST) is not required in Paris because the users are co-located with the cluster. We anticipate that 70 percent of the gateway calls processed by our system will be for headquarters, and we will need to provide the tool with that value.
We then consider the remote sites. At first glance, they could all share a common gateway group based on common platform needs, such as the use of IOS-based gateways such as the 3845 chassis, which has the ability to serve as the WAN edge router and can run SRST.
One issue prevents us from sharing a single gateway group with all the remote sites: all of them except New York require E1 integration into the PSTN. New York, on the other hand, requires T1 integration into the PSTN, so we need to create a separate, unique gateway group for New York.
From these considerations, we determine that we need three gateway groups: one each for Paris and New York, and another one for all the remote sites in France.
Now we configure each gateway group for the target user needs.
We start with Group 1 for Paris. Approximately 70 percent of our call volume originates or terminates in Paris because it is our headquarters (see Figure 2-45). The great majority of our users is at that site because of centralized functions such as marketing and sales and customer support. This value of 70 percent can be confirmed by examining the legacy PBX call history, as well as by looking at the historical PSTN connectivity cost distribution for all of our sites as billed by our service providers.
Figure 2-45 IPT Load
We receive an error message for each "Percentage of Load to Gateway Group" field until the total for all groups is 100 percent. After we have completed our last gateway group, the error message will be removed if the fields add up to 100 percent.
We select the Cisco 3845 as the voice gateway platform. The default values are fine but we need E1 for PSTN Integration. We need to ensure that the GW Used as SRST or CME choice is adequate in this case. SRST or CME make a heavy demand on gateway resources and increase the number of gateways needed for the group. We do not need this functionality for this gateway group.
The IPT Load for our Paris Gateway Group reflects the total number of gateways required, based on the selected gateway platform, the quantity of DSOs, E1 or T1 ports, and utilization. Two chassis are required, and although the current utilization is over 80 percent, it is in relation to the quantity of E1 ports configured. Because each chassis can go above the 13 E1s shown here, we have room to grow if we need to add more E1 ports. (See Figure 2-46.)
Figure 2-46 IPT Load—Group 1
Now we add a second gateway group for the New York site (see Figure 2-47). 5 percent of the IP Telephony load will be concentrated in New York. T1 integration is a major difference from the Paris gateway group, as well as the use of SRST.
Figure 2-47 Gateway Group 2
We see in the resulting IPT Load for this gateway group that while it is handling a small fraction of the traffic of the Paris group, the number of required 3845 gateways is higher. (See Figure 2-48.) This is mostly because we chose to use SRST in New York.
Figure 2-48 IPT Load—Group 2
As before, we are not near the maximum capacity of the actual chassis and have plenty of room for expansion if we add more traffic requirements on this gateway group.
Finally, we need to configure the third gateway group for the 16 remaining remote sites in France, which collectively represent the rest of the IPT traffic load, or 25 percent of the total (see Figure 2-49).
Figure 2-49 Gateway Group 3
This group needs to accommodate 16 sites with SRST functionality and E1 interfaces to the PSTN. The output is shown in Figure 2-50.
Figure 2-50 Gateway Group 3
After adding all the gateways, we look at the final Unified Communications Manager utilization numbers (see Figure 2-51).
Figure 2-51 Utilization (Unified Communications Manager, Output)
Understanding the Solution Sizing Summary
Now we can look at the solution sizing summary (see Figure 2-52).
Figure 2-52 Solution Sizing Summary
The summary lists the equipment type, model and quantity required for each product and component. After we have completed our initial sizing exercise, the solution is automatically saved.
Copying A Solution
The My Solutions page displays a list of previously saved solutions, including the name, description, the type of solution, when the solution was last updated, and the status of the solution (see Figure 2-53). In our case, we see that our solution is now 100 percent complete.
Figure 2-53 My Solutions Tab
To use this page to copy a solution or to share a solution with any user who has a tool-enabled Cisco.com user ID, complete the following steps:
Step 1 To copy an existing solution, click Copy.
The tool displays the Copy Dialog box, as shown in Figure 2-54.
Figure 2-54 Copy Dialog Box
Step 2 Enter a new name for the solution in the dialog box.
To send the solution to another cisco.com user, click Copy to in the dialog box, as shown in Figure 2-55.
Figure 2-55 Copying a Solution
Step 3 Enter the Username in the field provided.
Step 4 Click Copy.
The system copies the solution to the My Solutions tab of the specified user and generates an e-mail notification to the user, as shown in Figure 2-56.
Figure 2-56 E-mail Notification When Sharing a Solution
Adding Cisco Unified Contact Center Enterprise
This chapter describes how to add Cisco Unified Contact Center Enterprise (Unified CCE) to the solution described in the previous chapters. This chapter includes the following topics:
• Updating the Solution
• Using the Components Tab
• Using the Inbound Tab
• Using the Outbound Tab
• Using the UCCE Options Tab
• Using the Expert Advisor Tab
• Using the PG Tab
• Using the CVP Tab
• Using the VoiceXML Gws Tab
• Calculating the Number of CTI Route Points
• Viewing the Revised Output
• Viewing the Impact on Gateway Requirements
• Viewing the Updated Solution Sizing Summary
• Getting Help
Updating the Solution
In the world of our scenario, we now assume that eight months have gone by since our initial sizing exercise. Unified Communications Manager was deployed three months ago and Bonjour Networks is now ready to add Unified CCE to take care of their technical support and order processing departments.
To update the solution created in the last sections, complete the following steps:
Step 1 Log back into the tool.
The My Solutions page appears, this time displaying Bonjour Networks, as shown in Figure 3-1.
Figure 3-1 My Solutions Tab
The My Solutions page lets us view, edit, copy, or share an existing solution.
Step 2 To start a new scenario based on the previously saved Bonjour Network solution, click Copy next to the solution that we wish to copy.
The Copy Dialog box appears, as shown in Figure 3-2.
Figure 3-2 Copy Dialog Box
Step 3 In the Copy dialog box, type Bonjour Networks with Unified CC and click Copy.
The new solution is added to the My Solutions page, as shown in Figure 3-3.
Figure 3-3 My Solutions Tab with New Solution Added
Step 4 Click Bonjour Network with Unified CC.
The tool displays the Solution Summary page for this solution, as shown in Figure 3-4.
Figure 3-4 Solution Summary Page for Initial Bonjour Networks Solution
Step 5 To add Unified Contact Center Enterprise to the solution, click Identify Components.
The tool displays the Component Selection page (see Figure 3-5), which we used to start our initial sizing exercise.
Figure 3-5 Component Selection Page
Step 6 In the Components screen, add Unified Contact Center Enterprise by clicking the Yes button.
The tool displays the Components tab, which lets us describe the Unified Contact Center implementation.
Using the Components Tab
Figure 3-6 shows the Components tab.
Figure 3-6 Components Tab
Step 7 In the Components tab, select the following components and options for Unified Contact Center:
• Inbound, which lets us size the requirements of the solution to accommodate customer calls coming into the system.
• Outbound, which lets us size the requirements of the solution for calls placed to customers originating from our contact center.
• Expert Advisor, which lets us connect subject matter experts with the contact center agents or the caller.
• For our Voice Response Unit needs, select CVP, which lets us service calls on the edge of the network using VXML scripts.
Step 8 After selecting the necessary components, click Continue. to move to the Inbound tab.
Using the Inbound Tab
Figure 3-7 shows the Inbound Tab.
Figure 3-7 Inbound Tab
In the Inbound tab, we configure the requirements for the inbound call traffic. We need to consider how many calls are expected during the busy hour. Here, we enter 2000 (see Figure 3-8). This is based on historical data we obtained from our pre-existing system.
Figure 3-8 Requirements for Inbound Call Traffic
A call blocking probability of 1 percent is typical.
The service level goal represents what percentage of calls should be answered within the specified amount of seconds. The target is for 90 percent of calls to be answered within 30 seconds. Note that changing this value directly affects the sizing of the system and the staffing requirements of our contact center.
Next, we need to consider how many different types of inbound call flows will be processed by our contact center. For each, we define a unique traffic mix with its associated parameters. These include the following:
• Percent of total calls—The sum total of all traffic types needs to add up to 100 percent. An error message is displayed after we create the first call group. The error message will be removed after the combined Percent of Total Calls for all call groups equals 100 percent.
• Average talk time (sec)—Estimation of how much time an agent will spend on the phone with a caller.
• Average After Call Work Time (sec)—Also known as "wrap-up time"; represents the typical average amount of time needed by contact center agents to finish administrative tasks stemming from the call they just processed.
• Average call treatment time-VRU (sec)—How much time the caller spends in the voice response unit.
• Wait Before Abandon-Tolerance (sec)—Estimation of how much time customers will wait on the line, for each call type, before giving up.
• Percentage Calls Transferred—Percentage of calls that will require connection to a resource other than the original call taker, such as another agent or a supervisor, to complete the call.
• After Transfer Talk Time (sec)—Time the caller will spend with the second agent or a supervisor.
• Percentage of Calls Conferenced—Percentage of calls where more than one agent or supervisor will be online with the caller at the same time.
• Percentage of Calls Silently Monitored—Percentage of calls subject to monitoring by a supervisor, typically for quality assurance. Note that this pertains only to the silent monitoring function available through Unified Communications Manager.
If we are unsure how to estimate the expected traffic mix, we can refer to Table 3-1, which is Table 9.2 in the "Sizing Contact Center Resources" chapter of the Cisco Unified Contact Center Enterprise 7.5 SRND (http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/ipcc_enterprise/srnd/75/c7resrcs.html).
Table 3-1 eBusiness Best Practices for All Industries, 20011
Inbound Call Center Statistics
80% calls answered in? (seconds)
Average speed of answer (seconds)
Average talk time (minutes)
Average after-call work time (minutes)
Average calls abandoned
Average time in queue (seconds)
Average number of calls closed on first contact
Average TSR occupancy
Average time before abandoning (seconds)
Average adherence to schedule
Cost per call
Inbound calls per 8-hour shift
1 Special Executive Summary; Principal Investigator, Dr. Jon Anton; Purdue University, Center for Customer-Driven Quality.
Bonjour Networks supports three contact center call types: self-service, technical support, and sales calls. All calls will be routed initially through the Interactive Voice Response (IVR) unit. Thereafter, 90 percent of queued calls should be answered by an agent within 30 seconds.
We estimate that 30 percent of calls will be fully serviced by the automated voice response unit (see Figure 3-9). These calls will never be routed to an agent and we expect that they will take approximately two minutes for self service in the system.
Figure 3-9 Traffic Mix Section—First Call Type
We now click Add to go to our second call type.
Technical Support will represent 60 percent of calls (see Figure 3-10). Each call will spend about 40 seconds in the IVR before it is passed to an agent. Most calls will take four minutes to complete and another minute of "after call" work. 10 percent of calls will be transferred to another agent and another 5 percent will be conferenced. We estimate three minutes of talk time for calls transferred to another agent. We expect that callers will hang up after waiting 2.5 minutes for a technical support agent.
Figure 3-10 Traffic Mix Section—Second Call Type
We now click Add to go to our third call type.
Sales calls, which represent about 10 percent of all incoming calls, will require an average of 30 seconds in the IVR, five minutes of talk time, and two minutes of "after call work" to complete the order after disconnection (see Figure 3-11). 5 percent of calls will be transferred to another agent. We estimate that callers will hang up after waiting one minute for a sales agent.
Figure 3-11 Traffic Mix Section—Third Call Type
Now we scroll down the page and look at the questions that address information about the agents who will be handling calls incoming into our system (see Figure 3-12).
Figure 3-12 Agents Section
Here, we see that we can have the following two types of agents:
• Local—Agents who work in a contact center with CTI-controlled phone. Each local agent can be either an SIP phone or an SCCP phone.
• Mobile—Agents with non-CTI controlled phones, who can be in a location other than an actual contact center room.
Each mobile agent can be considered as one of the following:
– Nailed up Agent—Individuals who require a dedicated connection to the contact center, typically though the PSTN
– Call by Call Agent—Individuals whose connection with the contact center is re-established by the system, on a call-by-call basis
Note Note that the display-only fields on this page automatically adjust as information becomes known. For example, if 70 percent of agents are local, then the Mobile Agents field is instantaneously updated to 30 percent, because the total number of all agents must be always equal to 100 percent (see Figure 3-13).
Figure 3-13 Agents Section—Updated Display-Only Field
Bonjour Networks expects that on average, a supervisor will manage nine agents. All our agents will be "local agents" who will work from the contact center and they will be using the same phones as the majority of the other employees: that is non-secure SIP phones without video capabilities. To represent 100 percent of all agent phones to be SIP, we must enter 0 percent for SCCP agents on this page (see Figure 3-14).
Figure 3-14 Agents Section—Percentage of Local Agents Updated
Note that here we see Nailed up Agents with a value of 100 percent; this value represents what proportion of Mobile Agents are to be considered as Nailed Up Agents. In our scenario, because we have no Mobile Agents, the tool does not compute any capacity to account for Nailed Up Agents.
We accept the default blocking probability of 0.1 percent.
We can now look at the UCCE Options tab to see how many agents are currently required to handle the anticipated inbound calls (see Figure 3-15).
Figure 3-15 UCCE Options Tab
The tool tells us that we need 139 agents to handle inbound call flows.
We now need to consider the outbound campaign requirements of the system. We will come back to the Options tab to see the resulting increase in agents required to handle the combined inbound and outbound call flows for our contact center.
We now go to the Outbound tab.
Using the Outbound Tab
Figure 3-16 shows the Outbound tab.
Figure 3-16 Outbound Tab
Bonjour Networks is planning to use the new system to implement an outbound marketing campaign to reach its customers to perform satisfaction surveys.
To describe the anticipated outbound traffic for our contact center, we need to estimate the port requirements for each campaign. In our case, we have only one campaign. We also need to describe the expected traffic in terms of placed calls that go unanswered, go into an answering machine, or are answered by a person.
The following totals should add up to 100 percent, representing the totality of anticipated outbound traffic:
• Unanswered calls
• Calls picked up by an answering machine
• Total calls answered by a person
Note that each of these values are listed under their respective outbound call type summary.
We start our outbound campaign scenario by using 30 dialer ports (see Figure 3-17).
Figure 3-17 Unified Contact Center, Outbound, Dialer Ports
Now we can look at the three call response types.
We accept the values suggested by the tool for the Unanswered calls (see Figure 3-18).
Figure 3-18 Unanswered Calls Summary
We estimate that 40 percent of calls will be picked up by an answering machine and 40 percent will be answered by a person (see Figure 3-19).
Figure 3-19 Answering Machine Summary
Answering machine calls require our attention; we adjust the Transfer to IVR parameter from the default value of 25 seconds to 40 seconds.
Now we turn our attention to Answered Calls, where we adjust the following parameters (see Figure 3-20):
• We split the 40 percent of total Answered calls, assigning 35 percent to Transferred to IVR and 5 percent to Transferred and Answered by Agent. The sum of these two parameters is 40 percent, representing the total proportion of outbound calls answered by a person.
• We adjust the value of the Average Holding Time (AHT) parameter of the IVR announcement field from the default of 0 to 40 seconds.
• We adjust the AHT parameter of the Transferred and Answered by Agent field from the default of 120 to 180 seconds.
Figure 3-20 Answering Machine Summary
The Input section represents a collection of network-related parameters whose default values we accept for now (see Figure 3-21). Modification of these parameters is typically required only if the networks (such as the PSTN and the IP WAN) are significantly out of the norm.
Figure 3-21 Input Section
Note that after we have provided the tool with all configuration parameters, we can see the resulting impact on the required quantity of agents and can adjust numbers to simulate other scenarios based on a different quantity of dialer ports.
We click Continue to display the UCCE Options tab.
Using the UCCE Options Tab
Figure 3-22 shows the UCCE Options tab.
Figure 3-22 UCCE Options Tab
In the Extended Call Context (ECC) section, we enter a quantity for each variable that will be attached to calls and potentially used for reporting and planning (see Figure 3-23).
Figure 3-23 ECC Section
We estimate an average of ten Scalars, five Arrays, and ten Elements.
The Others section represents the quantity of skill groups supported by the agents and the system. We will have, on average, five Skill Groups per Agent, so we leave the parameter at its default setting. For Total Skill groups per System, we need to consider the typical situation where many agents are assigned the same skill group. In our case, we estimate that the total number of different skill groups for the entire system is 50.
The WebView (WV) Users value is defaulted to the number of Supervisors calculated in the System Load section on this tab, or 16.
For the quantity of Real Time Administrative Workstations (Aws), we use three for system administrators and supervisors.
The System Load information presented by the tool is calculated based on inbound and outbound call data as provided thus far (see Figure 3-24).
Figure 3-24 System Load Section
If we believe that the quantity of agents is too low or too high, we consider whether the expected BHCA or traffic mix data should be changed for incoming calls or if the port requirements for outbound campaigns are inadequate.
The Call Flows table summarizes the contact center call activities as calculated from the data entered as Traffic Mix on the Inbound and Outbound tabs. The information on this tab is used to determine system load when sizing Peripheral Gateway and Unified Contact Center Enterprise components.
We see here that Outbound call requirements added four agents to the total we had previously seen.
We now click Continue to proceed to the Expert Advisor tab.
Using the Expert Advisor Tab
Figure 3-25 shows the Expert Advisor (Exp Adv) tab.
Figure 3-25 Exp Adv Tab
To help determine how many Expert Advisors will be required, we can click Helper to display a calculator that can be used to determine the number of required Expert Advisors (see Figure 3-26).
Figure 3-26 Calculator
After entering the requirements, we click Calculate to obtain an output, and then click Insert to automatically update the questionnaire with our input and output. If we decide against using the calculator, we click Clear and then Cancel. This removes the calculator and any associated error messages.
The business requirements specified that there are currently 12 subject matter experts. We want to make sure that Bonjour Networks has enough experts to handle the expected load so we verify this information with the calculator.
No more than 2 percent of incoming BHCA will require assistance from a subject matter expert. Our total BHCA is 2000, times 2 percent, giving us 40. Each call is expected to be completed within 3 minutes and each expert will partake in every other call, which represents an Average Informal Agent Acceptance Factor of 50 percent. Expert Advisors share the same Service Level Agreement as Inbound and Outbound calls; therefore, we accept the remaining defaults and click Calculate.
The calculator determines that 10 expert advisors are required for the contact center. We size the system based on 12 advisors instead to allow for additional subject matter experts. We clear the calculator by clicking Cancel and continue with the previously entered value of 12 expert advisors.
The BHCA is entered to reflect the data we used in the calculator, which is 40.
We use the default value for Assignment Queues per system and Average Assignment Queues per Agent. We see that the server default is MCS-7845H2 (see Figure 3-27).
Figure 3-27 Exp Adv Tab
Now we see whether the server count remains the same when we change the server type to MCS-7835H (see Figure 3-28).
Figure 3-28 Exp Adv Tab—Server Type
Because the quantity of servers listed in the System Equipment panel does not change, we know that the requirements can be supported with one MCS-7835 server. Had they changed, we could have opted to go with the higher grade server choice.
We now click Continue to move to the Peripheral Gateway (PG) tab.
Using the PG Tab
Figure 3-29 shows the PG tab.
Figure 3-29 PG Tab
The PG tab helps us size the Agents Peripheral Gateway Server.
Bonjour Network is satisfied with its security posture and so does not require that CTI OS security be turned on.
We now need to estimate the number of skill groups per team and per peripheral gateway (see Figure 3-30).
Figure 3-30 PG Tab (2)
The average skill groups per team will be 25. This is based on our assumption that each team has nine agents and one supervisor, and that all the agents share seven common skill groups and each has two unique skill groups. 9 agents times 2 unique skill groups is 18, added to the 7 common skill groups gives us a total of 25 skill groups per team.
We now provide the tool with a Total Unique Skills Per PG value of 50. Our entire system, as we mentioned before, must support a total quantity of skill groups of 50. If we later find that the tool recommends more than one PG server pair, we can adjust this value.
Now we can see the output when we use the MCS-7835 (see Figure 3-31). We see that we need a single APG server pair, but that its APG Capacity Used% value is high, at 70.78 percent. Also, we see that an extra pair of servers is required to accommodate the VRU functionality.
Figure 3-31 Server Section
When we instead select the MCS-7845 server type, we no longer need extra servers for the VRU PG functionality (see Figure 3-32). We can also see that the APG Capacity Used% figure drops to 30.09 percent. We therefore choose to use the 7845 platform to save on server count.
Figure 3-32 Server Section—MCS-7845 Server
The Total APG Server Required With Redundancy output field indicates 2, which really means that the capacity of one server is needed. We now see that the one server pair that the tool indicates is required can indeed carry the total load of 50 skill groups for the entire system.
We now click Continue to move to the Customer Voice Portal (CVP) tab.
Using the CVP Tab
Figure 3-33 shows the CVP tab.
Figure 3-33 CVP Tab
For the Web Server For CVP Deployment choice, we retain the default value of Tomcat because it comes with the installation discs.
For the CVP XML Reports required flag and the CVP HTTPS Selected Flag, we also retain the default choices because we do not require detailed VXML script reports or HTTPS.
As for the redundancy choice, because we have only one site where Contact Center is required, as well as knowing that the scale of the contact center system is limited, we keep the default choice of N+1, where only one extra server is configured to provide redundancy to all the CVP servers. We can always come back later if we find that the one redundant server is insufficient, based on the total quantity of CVP servers required.
You may remember that Bonjour Networks chose CVP instead of IP-IVR to use VXML capabilities. Here, we therefore select VXML instead of Microapp.
End-user phones and trunks will use SIP as a signaling protocol, so it makes sense to choose SIP here as our Comprehensive Deployment Protocol.
The various call type percentages shown in Figure 3-34 are either auto-populated based on data we have already provided the tool, or require our input.
Figure 3-34 CVP (cont.)
The Comprehensive Percentage Network Transfer by Agents field is left at 0 because the Bonjour Networks contact center does not need the PSTN for network transfer.
Because VXML will be used, we use a MicroApp value of 0.
Now we can click Continue to move to the VoiceXML Gws tab.
Using the VoiceXML Gws Tab
Figure 3-35 shows the VoiceXML Gws tab.
Figure 3-35 VoiceXML Gws Tab
The sizing data outputs for VoiceXML Offered Load (Erlangs), ACHT - Average Call Holding Time (seconds), and Blocking Probability are determined by the information contained in the previous CVP page.
The choices we make for VoiceXML Gateway Platform, VoiceXML Service, and IOS Release affect the gateway quantity requirements of the Output section. For our situation, we indicated in the previous section that our preferred gateway platform was the 3845. We do not anticipate using Text To Speech or Automated Speech Recognition functionality, and thus select VoiceXML and DTMF. We use IOS release 12.4M, which is the default.
The output specifies how many gateways will be required. We can try various combinations of requirements and observe here the result on the recommended quantity of gateways. Based on the default gateway Cisco 3845, only one gateway is required.
We can now go to the Applications tab of Unified Communications Manager to provide the tool with the number of CTI route points for Unified Contact Center.
Calculating the Number of CTI Route Points
Figure 3-36 shows the calculation needed to determine the number of CTI route points.
Figure 3-36 Calculating CTI Route Points
We use one phone number (or CTI route point) for the customers to reach Bonjour Networks. When a customer dials this phone number, they are prompted with a menu to select between Self-Service, Technical Support, and Sales. These options are also directly reachable using separate numbers, so we will configure three additional route roints.
This represents a total of four CTI route points for inbound calls.
For outbound calls, because we have only one campaign, we use one CTI route point. We also estimate we are going to need 20 CTI route points for the translation routes needed when the calls are sent to an IVR.
Finally, for Expert Advisor, we configure five CTI route points.
Adding all the CTI route point requirements together results in a total of 30, which is entered into the UCC Agents section (see Figure 3-37).
Figure 3-37 Unified Communications Manager—Applications Tab, UCC Agents Section
Viewing the Revised Output
We can now look at the Unified Communications Manager Output tab to view the impact of Unified Contact Center Enterprise configuration on our system (see Figure 3-38).
Figure 3-38 Output Updated for Unified CCE
Note the following:
• The utilization figures have been segregated between IPT and Unified CCE; this reflects the fact that different server pairs have been dedicated to each of these two types of call processing loads. We can change this behavior of the tool by selecting a different option for the "UCCE Deployment" parameter. As we look at different choices, notice how the utilization and server count figures change (see Figure 3-39).
Figure 3-39 Unified CCE Deployment—Changed to "Mixed Users and Agents"
• The Server section now presents a quantity of server pairs dedicated to the use of Unified Contact Center.
• In our scenario, the total number of clusters is still one. Design requirements may prompt us to dedicate a separate cluster to Unified Contact Center functionality. If this were the case, we would use the tool to carry out a sizing exercise dedicated to the needs of the Unified Contact Center users, independently of the IP Telephony cluster.
Viewing the Impact on Gateway Requirements
We can now click TDM Voice Gateways to see what impact the Contact Center configuration has on the gateway requirements of the system. We see that the tool automatically attributes all the Unified Contact Center traffic to Gateway Group 1 (see Figure 3-40), which happens to be the right group for Bonjour Networks.
Figure 3-40 TDM Voice Gateways after Contact Center Is Added
We need one additional gateway to satisfy the needs of our Contact Center (see Figure 3-41 and Figure 3-42).
Figure 3-41 Output for Gateway Group 1 before Adding Contact Center
Figure 3-42 Output for Gateway Group 1 after Adding Contact Center
Figure 3-43 shows the complete output for all the gateway groups.
Figure 3-43 Gateways Updated for Unified CCE
Viewing the Updated Solution Sizing Summary
The overall summary has been updated to account for all required hardware needed for Unified Contact Center Enterprise (see Figure 3-44 and Figure 3-45).
Figure 3-44 Solution Sizing Summary with Unified CCE (1)
Figure 3-45 Solution Sizing Summary with Unified CCE (2)
To view the online version of the User Guide, click the Help Book link on the My Solutions page (see Figure 3-46). Note that there is also a support link at the top of the page.
Figure 3-46 My Solutions Screen
Figure 3-47 shows the title page of the Unified CST User Guide.
Figure 3-47 Unified CST User Guide
The user guide provides background information about sizing solutions with the Unified CST and a systematic reference describing the meaning of each field in the user interface, such as the example shown in Figure 3-48.
Figure 3-48 Unified CST User Guide—Sample Page
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED "AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental. Cisco Unified CST Sizing Tutorial © 2008 Cisco Systems, Inc. All rights reserved.