Using the Cisco Unified Capacity Sizing Tool
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