Cisco Hosted Collaboration Solution, Release 10.6(1) End-to-End Planning Guide

Transcription

1 Cisco Hosted Collaboration Solution, Release 10.6(1) End-to-End Planning Guide First Published: June 30, 2015 Last Modified: October 26, 2015 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA Tel: NETS (6387) Fax:

2 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 following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense. The following information is for FCC compliance of Class B devices: This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If the equipment causes interference to radio or television reception, which can be determined by turning the equipment off and on, users are encouraged to try to correct the interference by using one or more of the following measures: Reorient or relocate the receiving antenna. Increase the separation between the equipment and receiver. Connect the equipment into an outlet on a circuit different from that to which the receiver is connected. Consult the dealer or an experienced radio/tv technician for help. Modifications to this product not authorized by Cisco could void the FCC approval and negate your authority to operate the product 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 and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) 2015 Cisco Systems, Inc. All rights reserved.

3 CONTENTS Preface End-to-End Planning Guide Change History xi End-to-End Planning Guide Change History xi CHAPTER 1 End-to-End Planning Overview 1 Cisco HCS End-to-End Planning Workflow 1 CHAPTER 2 Initial System Requirements Planned Growth 3 Prerequisites 3 Initial Requirements Workflow 4 Determine Initial Requirements 4 Complete Tenant Matrix 5 Deployment Comparison HCS 7 Determine Your HCS Data Center Deployment Model 9 Small Medium Business Solutions 11 Dedicated Instance 11 Shared Instance 11 Shared Instance and Management 13 Shared Instance and Cisco Unified Communications Manager 13 Shared Instance and Cisco Unified Communications Manager IM and Presence Service 14 Shared Instance and Telephony Aggregation 14 Partitioned Unity Connection 15 Identify Planned Services and Applications 15 Identify Regulatory Services 16 Plan for High Availability 16 Identify Geographical Locations for Customer Deployment for Planning 17 Identify Trunking Services 18 iii

4 Contents CHAPTER 3 Data Center 19 Prerequisites 19 Data Center Workflow 20 Determine Data Center Requirements 20 Gather Data for Initial Data Center Planning 20 Determine the Data Center Deployment Model 21 Determine Details About Applications 22 Identify the Various Networking Resources 22 IP Addressing for HCS Applications 23 NAT Planning Considerations 23 Grouping VLANs and VLAN Numbering 24 Determine Virtual Machine Distribution and Connectivity 25 Determine DMZ Requirements 25 Data Center Network Configuration Overview 25 Investigate Storage Planning 26 CHAPTER 4 License Planning 27 Prerequisite 27 License Planning Workflow 28 Related Documentation 28 License Planning Considerations 28 HCS License Manager (HLM) Planning Considerations 28 Prime License Manager Planning Considerations 29 Determine Data Center Infrastructure Licenses 30 Determine Data Center Storage Licenses 30 Determine VMware Licenses 30 Determine UC Applications 31 Determine HCS for Contact Center 31 Third-Party Software Licences 31 Determine HCS Management Licenses 32 License Activation Considerations 32 CHAPTER 5 Customer Premise Equipment 33 Prerequisites 33 iv

5 Contents Customer Premise Equipment Workflow 34 Determine the Type of Site(s) 34 Dedicated Server 34 Determine Customer Premise Equipment Router Model 34 Determine Services on Router Model and Location of Services 35 Determine Analog Gateways 35 Determine Endpoints 35 Determine Access Methods 36 Determine Standalone Firewalls 36 Determine Networks for Customer Premise Equipment 36 CHAPTER 6 Service Fulfillment Planning 39 Prerequisites 39 Service Fulfillment Workflow 40 HCM-F deployment models 40 Service Inventory planning considerations 41 Platform Manager Planning Considerations 41 Limitations and restrictions 42 Servers functionality classification 42 Server group usage 43 Limitation in server groups 43 Task creation 44 Data filtering 44 Best practices 45 Prime Collaboration Deployment for UC Applications 45 Infrastructure Platform Automation (IPA) Planning Considerations 48 Compatibility considerations 49 Call Detail Records 49 LDAP Integration Considerations 50 Single Sign On Considerations 50 Cisco Unified Communications Domain Manager Planning Considerations 50 Resource Requirements 51 CHAPTER 7 Service Assurance 53 Prerequisites 53 v

6 Contents Prime Collaboration Assurance Workflow 54 Prime Collaboration Assurance Architecture Considerations 54 Prime Collaboration Assurance Management Considerations 54 Northbound Interface to OSS/BSS Considerations 55 Interface to Cisco HCM-F Considerations 55 Prime Collaboration Assurance for all Deployments 56 Cisco Prime Collaboration Assurance NBI 57 NAT Planning Considerations 57 Provisioning Considerations 57 Estimate Prime Collaboration Assurance OVA Requirements 58 Estimate Prime Collaboration Assurance Scale Numbers 58 Acquire Prime Collaboration Assurance Licenses 58 Determine Required Bandwidth 58 Determine Necessary Ports/Protocols Requirements 58 Cisco Unified Border Element Naming Considerations 58 CHAPTER 8 Customer Specific Dial Plan 61 Prerequisites 61 Dial Plan Workflow 62 Determine Customer-Specific Dial Plan Requirements for Cisco Unified Communications Domain Manager 8.1(x) 62 Determine Dial Plan Model for Cisco Unified Communications Domain Manager 8.1(x) 63 Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 8.1(x) 65 Considerations When Deploying Multiple Service Providers 66 Determine Country-Specific Dial Plans for Cisco Unified Communications Domain Manager 8.1(x) 67 Plan a New Country Dial Plan 69 Determine Customer Dialing Requirements for Cisco Unified Communications Domain Manager 8.1(x) 72 Plan Path Selection 72 Determine Extension Addressing in Cisco Unified Communications Domain Manager 8.1(x) 72 Determine Emergency Calling 74 vi

7 Contents Determine Inter-site Calling Customization Requirements for Cisco Unified Communications Domain Manager 8.1(x) 74 Determine Intrasite Calling Customization Requirements Cisco Unified Communications Domain Manager 8.1(x) 75 Determine Short Code Dialing for Cisco Unified Communications Domain Manager 8.1(x) 75 Determine Voice Mail Numbering for Cisco Unified Communications Domain Manager 8.1(x) 76 Determine Enhanced Number Translation Template Use in Cisco Unified Communications Domain Manager 8.1(x) 76 Determine Time of Day Routing for Cisco Unified Communications Domain Manager 8.1(x) 78 Determine Class of Service and Restrictions for Cisco Unified Communications Domain Manager 8.1(x) 78 Determine Customer-Specific Dial Plan Requirements for Cisco Unified Communications Domain Manager 10.6(1) 79 Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 10.6(1) 80 Role-Based Access Control (RBAC) 80 Determine Country-Specific Dial Plans for Cisco Unified Communications Domain Manager 10.6(1) 82 Determine Customer Dialing Requirements for Cisco Unified Communications Domain Manager 10.6(1) 83 Determine Extension Addressing for Cisco Unified Communications Domain Manager 10.6(1) 84 Determine Voice Mail Numbering in Cisco Unified Communications Domain Manager 10.6(1) 85 Determine Time of Day Routing in Cisco Unified Communications Domain Manager 10.6(1) 86 Determine Class of Service and Restrictions in Cisco Unified Communications Domain Manager 10.6(1) 86 CHAPTER 9 Unified Communications Application Planning 87 Prerequisites 87 UC Applications Workflow 88 Determine UC Applications Requirements 88 vii

8 Contents CHAPTER 10 Mobility 91 Prerequisites 91 Mobility Workflow 92 Plan the Mobility Deployment 92 Plan Mobile IMS Integration 93 Plan Carrier-Integrated Mobile Integration 95 CHAPTER 11 Video 97 Prerequisites 97 Video Workflow 98 Plan the Video Network 98 CHAPTER 12 HCS for Contact Center 101 Prerequisites 101 HCS for Contact Center Workflow 102 Plan the HCS for Contact Center Deployment 102 Determine the HCS for Contact Center Deployment Model 103 Configuration Limits 104 Features & Options in Small Contact Center Deployment 109 Optional Component Considerations 110 Unified WIM and EIM Considerations 110 Unified WIM and EIM Deployment Options 110 Unified WIM and EIM Configuration Limits 111 HCS Support Matrix for Unified WIM and EIM 112 Cisco RSM Capabilities 112 Cisco MediaSense Capabilities 113 Voice Infrastructure 113 Optional Component Considerations 115 Unified WIM and EIM Considerations 115 Unified WIM and EIM Design Considerations 116 Unified WIM and EIM Deployment Options 116 Unified WIM and EIM Configuration Limits 117 HCS Support Matrix for Unified WIM and EIM 118 Unified WIM and WIM High Availability 118 viii

9 Contents Cisco WIM and EIM Bandwidth, Latency and QOS Considerations 123 Cisco RSM Considerations 123 Cisco RSM Design Considerations 123 Cisco RSM High Availability 123 Cisco RSM Capabilities 125 Cisco RSM Bandwidth, Latency and QOS Considerations 125 Cisco MediaSense Considerations 126 Cisco MediaSense Design Considerations 126 Cisco MediaSense Capabilities 126 Cisco MediaSense High Availability 127 Cisco MediaSense Bandwidth, Latency and QOS Considerations 127 Cisco Unified SIP Proxy Considerations 127 Performance Matrix for CUSP Deployment 128 Cisco SPAN based Monitoring Considerations 128 Silent Monitoring Bandwidth, Latency and QOS Considerations 128 Optional Component Bandwidth, Latency and QOS Considerations 128 Silent Monitoring Bandwidth, Latency and QOS Considerations 129 Cisco RSM Bandwidth, Latency and QOS Considerations 129 Cisco WIM and EIM Bandwidth, Latency and QOS Considerations 129 Cisco MediaSense Bandwidth, Latency and QOS Considerations 130 Determine the Hardware Requirements 130 Tested Reference Configurations 130 Specification-Based Hardware Support 131 Determine the Software Requirements 132 Plan Solution Serviceability 132 Virtual Machine Performance Monitoring 133 ESXi Performance Monitoring 134 Determine the Active Directory Deployment 136 AD at Customer Premises 136 AD at Service Provider Premises 137 Determine the Blade and Storage Placement Requirements 137 Determine High Availability Requirements 137 Plan the Solution for Handling Congestion Control 138 Plan the UCS Networking Requirements 138 Determine the Trunk Design 139 ix

10 Contents CUBE-Enterprise at Customer Premise 139 TDM Gateway at Customer Premise 139 Firewall Hardening Considerations 140 CHAPTER 13 Backup and Restore 141 Prerequisites 141 Backup and Restore Workflow 142 Determine Backup and Restore Requirements 142 Backup Strategy 144 x

11 End-to-End Planning Guide Change History End-to-End Planning Guide Change History, page xi End-to-End Planning Guide Change History Change Description Date NAT Planning Considerations, on page 23 Added information related to Prime Collaboration Assurance. October 26, 2015 xi

12 End-to-End Planning Guide Change History End-to-End Planning Guide Change History xii

13 CHAPTER 1 End-to-End Planning Overview Cisco HCS End-to-End Planning Workflow, page 1 Cisco HCS End-to-End Planning Workflow The following flow outlines the end-to-end procedures and considerations for planning your HCS deployment. All of these areas require some attention but analysis may not necessarily occur in this order. 1

14 Cisco HCS End-to-End Planning Workflow End-to-End Planning Overview 2

15 CHAPTER 2 Initial System Requirements Planned Growth Prerequisites, page 3 Initial Requirements Workflow, page 4 Determine Initial Requirements, page 4 Complete Tenant Matrix, page 5 Deployment Comparison HCS, page 7 Determine Your HCS Data Center Deployment Model, page 9 Identify Planned Services and Applications, page 15 Identify Regulatory Services, page 16 Plan for High Availability, page 16 Identify Geographical Locations for Customer Deployment for Planning, page 17 Identify Trunking Services, page 18 Prerequisites Before you plan the initial system requirements and planned growth for the Cisco Hosted Collaboration Solution (HCS). To make sure you have seen the Collaboration Sizing Tool at tools.cisco.com/cucst You should also review the following documents: Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide Cisco Hosted Collaboration Solution, Release 10.6(1) Capacity Planning Guide 3

16 Initial Requirements Workflow Initial System Requirements Planned Growth Initial Requirements Workflow Determine Initial Requirements The following steps guide you through the critical pieces of planning your initial system requirements and growth. These steps help to frame the overall architecture and design of your system. Be sure to address the prerequisites for this section before proceeding. Note The Guided System Selling ciscoadvisor.action?sfid=cisco&configsetavailable=&scflag=y questionnaire can provide many of the details discussed below. This section provides additional information for you to consider during planning, however if you have information about your system from this questionnaire, use that information as part of your deployment planning process. Procedure Step 1 Complete Tenant Matrix, on page 5 Step 2 Determine Your HCS Data Center Deployment Model, on page 9 Note Make sure that you determine the expected latency for the Cisco Unified Communications Domain Manager to UC Application delay tolerance in advance of planning your deployment. 4

17 Initial System Requirements Planned Growth Complete Tenant Matrix Step 3 Identify Planned Services and Applications, on page 15 Step 4 Identify Regulatory Services, on page 16 Step 5 Plan for High Availability, on page 16 Step 6 Identify Geographical Locations for Customer Deployment for Planning, on page 17 Step 7 Identify Trunking Services, on page 18 Step 8 Plan for growth and the customer premise equipment site. For more details, see Customer Premise Equipment Complete Tenant Matrix Collect information about the estimate size of your initial system and use the tenant matrix below to compute the average tenant size for a deployment, along with the total number of tenants. Note In the context of HCS, a Partner is a company that purchases or leases HCS equipment from Cisco. The Partner enlists customers on the same HCS system, and these customers of the Partner are referred to as tenants and therefore, one Partner will, in general, have multiple tenants. Each tenant is a separate entity/company. Procedure Step 1 Step 2 Determine Percent Distribution and Total Deployment size. Use the following tenant matrix to collect information about your planned system and to help develop your growth plans. Number of End Users Tenant Size ,000 2,500 5,000 7,500 10,000 15,000 25,000 30,000 Totals Percentage Distribution Weighted Average Number of Tenants Step 3 Enter the following information into the tables above: Number of End Users Represents the total number of users expected for the HCS deployment across all tenants and customers. Tenant Information Either the Number of Tenants or the Percentage Distribution for each tenant size. 5

18 Complete Tenant Matrix Initial System Requirements Planned Growth Weighted Average Computed average tenant size using the different percentages (distribution) in the table above. Step 4 Review the following results in the table: Average tenant size Total number of tenants This number is important for computing limits that are related to the routing table and security contexts, among others. The following examples can assist you with the construction of the table. Tenant matrix - Example 1 To deploy a Cisco HCS system for which the exact number of tenants of each size is known, update the Number of Tenants row directly in the table, as shown in the following table: Table 1: Details included after adding required information - Example 1 Tenant Size ,000 2,500 5,000 7,500 10,000 15,000 25,000 Totals Percentage Distribution Weighted Average Number of Tenants Table 2: Percentage distribution - Example 1 The total number of tenants in this example is 179. Because the number of tenants of each size is known, you can calculate the total deployment size (number of end users) as in the following equation: Number End Users = 10* * * * *1, *2, *5,000= , , , , , ,000 = 77,000 Therefore, the total number of end users is 77,000. The percentage distribution represents the proportion of tenants of a particular size. It is defined as follows: Percentage Distribution_Size_N = Number Tenants_Size_N / Total_Number_of_Tenants For example, Percentage Distribution_Size_50 = 10/179 = 5.6% By computing the Percentage Distribution for each of the tenant sizes, you receive the following results: Tenant Size ,000 2,500 5,000 7,500 10,000 15,000 25,000 Totals Percentage Distribution 0.0% 5.6% 11.2% 55.9% 2.8% 1.7% 0.6% 0.0% 0.0% 0.0% 0.0% 0.0% 100% Weighted Average Number of Tenants

19 Initial System Requirements Planned Growth Deployment Comparison HCS The final step involves computing the Weighted Average. This value represents the contribution of each tenant size to the total number of end users. The Weighted Average is defined as: Avg_Wt_Size_N = Percentage Distribution_Size_N * Tenant_Size Note Repeat this equation for each tenant size. This value would be zero if there were not any tenants for that size. In this example, the Weighted Average for the following tenant sizes would be zero: 20 7,500 10,000 15,000 25,000 Table 3: Weighted Average - Example 1 The final table can now be calculated: Tenant Size ,000 2,500 5,000 7,500 10,000 15,000 25,000 Totals Percentage Distribution 0.0% 5.6% 11.2% 55.9% 2.8% 1.7% 0.6% 0.0% 0.0% 0.0% 0.0% 0.0% 100% Weighted Average Number of Tenants* Deployment Comparison HCS You can deploy the Cisco HCS solution on any of the data center infrastructure models: Large PoD, Small PoD, or Micro Node. Review the following table to see a comparison of the different options available for each deployment model. 1 * Tota; Number of Users = Total Deployment Size. Therefore, (430.2) * (179) = 77, Previously, we had indicated that our Deployment Size was 77,000. The difference between this number and the one calculated from the table is because of rounding. 7

20 Deployment Comparison HCS Initial System Requirements Planned Growth Table 4: Comparison Data Center Infrastructure Models Function or Product Large PoD Small PoD Micro Node Number of tenants*** Aggregation Up to 940 Nexus 7000, Nexus 9396, Nexus 9508 Approximately 80 Note Storage switches such as Cisco MDS 9000 switches are optional and are not required for Small PoD deployments. Nexus 5500 Up to 20 Nexus 5500 Cisco Unified Compute System (UCS) UCS with B-series blades UCS with B-series blades UCS C-series servers Storage Fabric interconnect, SAN or NAS storage Fabric interconnect, SAN or NAS storage DAS (Local) storage Media/Signaling Anchoring Device Cisco Unified Border Element (SP Edition) or Perimeta SBC (Optional) Cisco Unified Border Element (SP Edition) or Cisco Unified Border Element Enterprise Edition** (Optional) Cisco Unified Border Element Enterprise Edition)** (Two if redundancy is required) or Perimeta SBC or Perimeta SBC Security (Optional) Site-to-Site VPN Concentrator (Optional) Line Side Access (Optional) Shared Cisco Expressway for Business to Business Dialing with Non HCS Enterprises over Internet (Optional) Cisco Expressway Cisco Prime Collaboration Assurance available (Optional) Shared Instance (Optional) Dedicated Instance (Optional) OTT Remote Access with Expressway ASA 5585-X ASR 1000 Cisco Unified Border Element Enterprise Edition for Cisco ASR 1000 Series Expressway-C and Expressway-E on UCS B-series Expressway-C and Expressway-E on UCS B-series Yes Yes Yes Yes ASA 5555-X ASR 1000 Cisco Unified Border Element Enterprise Edition for Cisco ASR 1000 Series Expressway-C and Expressway-E on UCS B-series Expressway-C and Expressway-E on UCS B-series Yes Yes Yes Yes ASA 5555-X ASR 1000 Cisco Unified Border Element Enterprise Edition for Cisco ASR 1000 Series Expressway-C and Expressway-E on UCS C-series Expressway-C and Expressway-E on UCS C-series Yes* Yes Yes Yes 8

21 Initial System Requirements Planned Growth Determine Your HCS Data Center Deployment Model Function or Product (Optional) Shared RMS with Expressway (Optional) Jabber Guest (Optional) WebEx CCA (Optional) Business to Business Video through Shared Expressway Large PoD Yes Yes Yes Yes Small PoD Yes Yes Yes Yes Micro Node **Cisco Unified Border Element Enterprise Edition for the enterprise version is suitable for a small number of clusters because a separate Cisco Unified Border Element Enterprise Edition is needed for each cluster (one Cisco Unified Border Element Enterprise Edition can support multiple customers in one shared instance cluster). When a large number of clusters are in the Micro Node, Cisco Unified Border Element (SP Edition) or Perimeta SBC with large enterprises, may provide better operational flexibility and cost benefits. *Micro Node deployments only support Cisco Prime Collaboration Assurance with two virtual machine server instances. Yes Yes Yes Yes Determine Your HCS Data Center Deployment Model Review the detailed descriptions of each type of deployment in the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide and the Cisco Hosted Collaboration Solution, Release 10.6(1) Capacity Planning Guide before proceeding. Your growth plans will help you determine the best solution for you. Procedure Step 1 Review decision-making factors for each of the following deployment models. Note The details you gathered using the Guided System Selling tool should define which deployment model is right for you. The following details are for reference only. a) Large PoD The Large PoD deployment supports a large number of tenants and can also support incremental additions of compute and storage resources. b) Small PoD The Small PoD deployment also supports a significant number of tenants, although fewer than the large PoD. This deployment supports incremental additions of compute and storage resources, has only a moderate initial CAPEX and has a smaller data center footprint. If the tenant capacity is used faster than expected, you will need to add another instance of Small PoD. Over time the additional compute resource CAPEX required to expand a Micro Node deployment will exceed the CAPEX for an equivalent Small PoD deployment. c) Micro Node Micro Node supports a smaller number of tenants. This deployment supports the incremental addition of compute and has a low initial CAPEX. It also has a smaller data center footprint and supports migration to Small PoD. The addition of compute resources, however, eventually exceeds the CAPEX cost beyond 9

22 Determine Your HCS Data Center Deployment Model Initial System Requirements Planned Growth a Small PoD deployment. Micro Node deployment does not support shared storage. Micro Node deployments only support Cisco Prime Collaboration Assurance (PCA) with two virtual machine server instances. Note Cisco NX-OS Release 6.2 software requires 8 GB of memory. If you plan to use a Cisco Nexus 7000 Series system you will need to 8 GB of memory. This does not provide any additional performance or scale. Based on the information that you have gathered and the parameters of each deployment model, you can determine which model is appropriate. Step 2 Step 3 Consider the following options site types for your deployment. Note Site type decisions are made based on a per customer basis. Depending on your customer requirements, you can have one or more site types as part of your HCS. For more detailed information on the different types of sites, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. a) Hosted Consider this option if you want all of the UC applications to reside in the HCS data center and endpoints located at one or more remote customer sites. This option is simplest to deploy and manage as all the call control and management servers are in the HCS data center. b) HCS Extender Consider this option if you want to have some or all of the Unified Communications applications on premises and some constraints on the server types, ESXi, C-series servers, and so on. Central breakout is also supported with this option. This option provides flexibility and is described in detail in the "HCS Extender" section of the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. c) Remote managed Consider this option if you want all Unified Communications applications on premises, with Cisco HCS providing central breakout if necessary, and remote management through Hosted Collaboration Mediation-Fulfillment and Cisco Unified Communications Domain Manager. You will also need a deployment of Small PoD size data center at the remote site to host the UC applications. d) Hosted Private Cloud/Large Enterprise Consider this option if you need support for a very large customer with multiple clusters, potentially multiple independent organizational units, geographically and distributed operations. Examples include financial institutions or retailers with national coverage or Government organization. This Private Cloud deployment has its own HCS license type (HCS-LE) for UC and Management, which unlike MSP cannot be shared i.e. cannot resell or offer managed services. This one customer typically owns the hardware and manages the system. This deployment may optionally have its aggregation system. Identify OVA sizes to help with growth plans. Important CPU oversubscription is only allowed for specific VMs where reservations are identified in the Cisco Hosted Collaboration Solution Compatibility Matrix. Otherwise, all VMs must map one VM vcpu core to one physical CPU core. The following are not supported in Cisco HCS: Memory (RAM) oversubscription Storage oversubscription Storage thin provisioning (at VM layer or storage array layer) Hyperthreading Consider expected customer growth when selecting the initial OVA file for deploying UC Applications. For example, if you do not expect to experience much growth over the next six to 12 months, selecting an OVA that fits your initial deployment should be adequate. If, however, you expect to grow beyond the initial OVA 10

23 Initial System Requirements Planned Growth Small Medium Business Solutions size over the next six to 12 months, Cisco recommends you select a larger OVA to fit the expected growth level and not an OVA that fits your initial deployment level. Initially, selecting a larger OVA for your deployment consumes more resources, however, the amount of time required to resize a virtual machine is significant. If you are unsure about your growth plans, however, you should evaluate whether the potential cost of allocating resources for a larger OVA is a suitable solution. A time-cost of downsizing also exists. If your assumptions and considerations do not help to identify the accurate OVA sizes, information from the Ordering Tool can help validate your system information. For more information about the tool, see Hosted_Collaboration_Solution.pdf. Small Medium Business Solutions The classic Cisco HCS data center infrastructure model includes Nexus 7000 switches, SAN, UCS with B-series blade servers, Cisco Unified Border Element (SP Edition) or Perimeta SBC, and so on, that support a large number of end users across a high number of customers. This involves considerable initial cost and is suitable for large partners. For service providers with less than 940 customers, there are a number of ways that you can deploy the data center infrastructure using smaller hardware components and shared application models to optimize scale and cost. You can deploy the Cisco HCS small/medium business solution on any of the data center infrastructure models: Large PoD, Small PoD, or Micro Node. The Cisco HCS small/medium business solution also supports both Dedicated Instance and Shared Instance models for applications. Dedicated Instance Dedicated instance refers to the model of applications where there is a separate application instance (Cisco Unified Communications Manager) for each customer. In one B or C-series server there can be different customer instances based on how applications are distributed in the server. Any reference to a UC application such as Cisco Unified Communications Manager, Cisco Unified Communications Manager IM and Presence Service, Cisco Unity Connection Cisco Emergency Responder, and CUAC, that does not include "Shared" or "Partitioned" as part of the title implies that it is a dedicated instance. Since the dedicated instance model is the same as in a large enterprise solution, no further description is provided here. Shared Instance In the HCS small-to-medium business environment, the Shared Instance model of applications is supported, where multiple small customers can be served by one Cisco Unified Communications Manager cluster. This approach reduces the hardware and operational costs for smaller customer sizes. The Cisco Unified Communications Domain Manager customer-based provisioning capability is used, along with the Shared Instance G3 dial plan. With Shared Instance, you get a much better resource utilization for smaller customer 11

24 Shared Instance Initial System Requirements Planned Growth deployments. You can enable Shared Instance on any of the data center infrastructure models: Large PoD, Small PoD, or Micro Node. Figure 1: Shared Instance Deployment In this approach, one Cisco Unified Communications Manager instance has multiple customers, each in their own partitions, and the dial plan forces inter-customer calls to go through the telephony aggregation layer and service provider softswitch. Similarly, one instance of Cisco Unified Communications Manager IM and Presence Service also can be shared by multiple customers. With the Share Instance deployments, OTT Remote access is supported through the Cisco Unified Border Element Enterprise Edition or the Cisco Expressway. 12

25 Initial System Requirements Planned Growth Shared Instance Note The Shared Instance approach has feature restrictions and customer requirements that should be carefully considered. For details on these restrictions, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Features for Cisco Unified Communications Manager. Shared Instance and Management When multiple customers are supported in one Cisco Unified Communications Domain Manager 8.1(x) cluster, the following management guidelines apply: In a Cisco HCS management, both Shared Instance clusters and Dedicated Instance clusters are supported. Cisco HCS Management services to customers on a Dedicated Instance Cisco HCS cluster are not affected. Cisco HCS Management services to customers on a Shared Instance cluster may not be fully available; refer to workarounds and restrictions described in the deployment model descriptions later in this chapter. A single Cisco Unified Communications Domain Manager 8.1(x) can manage both types of clusters (Dedicated and Shared Instance) in one Cisco HCS deployment. In order to support both shared and dedicated clusters on the same Cisco Unified Communications Domain Manager 8.1(x), Cisco recommends that you create two different service providers. You can, however, support a single customer in one cluster with the same Shared Instance dial plan with just one service provider created on Cisco Unified Communications Domain Manager 8.1(x). Shared Instance and Cisco Unified Communications Manager The following Cisco Unified Communications Manager guidelines apply to deployments with Shared Instance: In Shared Instance, customers are provisioned in their own partitions. Provisioning through Cisco Unified Communications Domain Manager with Shared Instance dial plan ensures customer separation. Dial plan is modified to support Shared Instance. A Shared Instance (G3) Dial Plan is added for Cisco Unified Communications Domain Manager 8.1(x), and there are some restrictions with the Shared Instance (G3) Dial Plan. For example, ISC trunks are not supported in G3. For more information, refer to the appropriate version of the Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 8.1(x) for your system, available at hosted-collaboration-solution-hcs/products-installation-and-configuration-guides-list.html. Dial plan is modified for Cisco Unified Communications Domain Manager 10.6(1). There are four basic pre-defined call types supported: Directory Number = Site Location Code (SLC) + Extension, no Inter Site Prefix (ISP) in SLC Directory Number = SLC + Extension with ISP as part of SLC Directory Number = SLC + Extension and without ISP, can be with or without Extension Dialing Prefix (EDP) Directory Number = Flat Dial Plan (no SLC) 13

26 Shared Instance Initial System Requirements Planned Growth The four dial plan model types supported in Cisco Unified Communications Domain Manager 10.6(1) encompass all the functionality that was available on the previous Dial Plan Model, but in order to offer flexibility for partners, the four types can be extended to develop custom schemas. Customization is managed through discrete, selectable elements in Cisco Unified Communications Domain Manager 10.6(1). Inter-customer calls on the Shared Instance are not natively completed, but routed through the PSTN aggregation layer for Lawful Intercept and regulatory reasons. Cisco Unified Communications Domain Manager provides customer separation for feature provisioning purposes. The features under Location in Cisco Unified Communications Domain Manager (hunt groups, pickup group, and so on) ensure that customer specific attributes (such as partitions and group codes) are used while provisioning the Cisco Unified Communications Manager. While the function of Cisco Unified Communications Domain Manager is the same for Dedicated or Shared Instance, it is essential for Shared Instance because Cisco Unified Communications Manager provides the separation between customers based only on these attributes (partitions, codes, and so on). In Dedicated Instance, the question of customer separation does not arise because there is only one customer. For more information on the Shared Instance features, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Features for Cisco Unified Communications Manager. Shared Instance and Cisco Unified Communications Manager IM and Presence Service The following restriction applies to Shared Instance and Cisco Unified Communications Manager IM and Presence Service: LDAP Directory is recommended for Cisco Jabber contact resolution. With Cisco Unified Communications Domain Manager 8.1(x), LDAP Directory must be in the service provider domain. With Cisco Unified Communications Domain Manager 10.1(x), LDAP Directory can be in the service provider domain or customer domain. Note that Cisco Unified Communications Domain Manager 10.1(x) supports syncing with multiple LDAP Directories, so each customer can have separate directories in the customer domain. Note that Expressway does not support LDAP for Directory lookup. Only UDS is supported and UDS-based directory lookup is served from Cisco Unified Communications Manager. For more information, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Features for Cisco Unified Communications Manager. Shared Instance and Telephony Aggregation The following optional telephony aggregation layer support is provided for the Shared Instance application model: Aggregation layer with Cisco Unified Border Element (SP Edition), Cisco Unified Border Element Enterprise Edition, Perimeta SBC or third-party SBC and PGW or service provider's softswitch is supported. Inter-customer routing goes through the aggregation layer softswitch. Cisco Unified Border Element (SP Edition) to service provider network routing is through a single aggregated trunk for the traffic of all customers on one Shared Instance Cisco Unified Communications Manager cluster. Per-customer SIP trunks are also supported when PGW is not used. PGW to service provider network routing is through a separate trunks for each Cisco Unified Communications Manager cluster for the traffic of all customers on one Shared Instance. 14

27 Initial System Requirements Planned Growth Partitioned Unity Connection Local Breakout (LBO) PSTN gateway is supported in cases where you do not wish to offer any other options or cannot comply or does not wish to comply with regulatory requirements of emergency or lawful intercept within the Cisco HCS network. Partitioned Unity Connection To help the Cisco HCS solution scale more customers on the same hardware, you can partition a single Cisco Unity Connection instance to support multiple customer domains. Cisco Unity Connection exposes the configuration and provisioning to support multiple customers by means of REST APIs. The Cisco HCS service fulfillment layer uses the partitioned Unity Connection REST APIs to allow Cisco HCS partners to configure and provision customers into the partitioned Unity Connection. Cisco HCS continues to support the dedicated Cisco Unity Connection in addition to the new partitioned instance. Partitioned Unity Connection is not a new product with a new SKU. The HCS administrator and domain managers must decide the role of Unity Connection as either regular or partitioned. The following deployment option is supported: Use Cisco Unified Communications Domain Manager to provision partitioned Cisco Unity Connection if you are running version Cisco Unified Communications Domain Manager 10.6(1). The current dedicated Cisco Unity Connection virtual machine (VM) uses an overlapping IP address. The same VM is used for partitioned Cisco Unity Connection with no change in the IP addressing. To provide access to multiple management devices such as Cisco Unified Communications Domain Manager and Prime Collaboration Assurance (which have global IP addresses) a hosted NAT device is required to perform address translations. You can leverage an existing NAT device that currently performs this function. Because UC applications are not multi-vrf capable, Cisco Unified Communications Manager and partitioned Cisco Unity Connection cannot have a direct interface when Unity Connection is interfacing with multiple instances of Cisco Unified Communications Manager. In that case, CUBESP or Perimeta SBC is needed. However, it is possible to have a direct inteface when only one instance of Cisco Unified Communications Manager is interfacing with Partitioned Unity Connection. The Cisco Unified Border Element (SP Edition) or Perimeta SBC is required to perform this aggregation. Identify Planned Services and Applications Procedure Review the Unified Communications applications and services to determine which you plan to use in your HCS deployment. a) Voice/Voic /IM Cisco Unified Communications Manager Unified Communications Manager is supported across Large PoD, Small PoD, and Micro Node in a dedicated deployment. Cisco Unified Communications Manager is supported across Large PoD, Small PoD, and Micro Node in a Shared Instance deployment. Cisco Unified Communications Manager IM and Presence Service 15

28 Identify Regulatory Services Initial System Requirements Planned Growth Unified Communications Manager IM and Presence is supported across Large PoD, Small PoD, and Micro Node in a dedicated instance deployment. Cisco Unity Connection Cisco Unity Connection is supported across Large PoD, Small PoD, and Micro Node in a dedicated deployment. Cisco Unity Connection is supported across Large PoD, Small PoD, and Micro Node in a Shared Instance deployment. b) Paging services c) Attendant Console (CUAC) (Server and serverless) d) Cisco Emergency Responder e) Video For more information on video planning, see Video. f) Mobility For more information on mobility planning, see Mobility. g) HCS for Contact Center For more information on HCS for Contact Center planning, see HCS for Contact Center. Identify Regulatory Services Procedure Step 1 Step 2 Determine whether you need to provide Lawful Intercept (LI) services. Verify the LI requirement for the country in which you want to deploy to determine which services you must provide. Determine whether you need to provide emergency services. Verify the emergency services requirements for the country in which you want to deploy to determine which services you must provide. Plan for High Availability When planning for high availability in a Cisco HCS deployment, complete the following Cisco HCS-specific planning steps: Infrastructure Redundancy (Steps 1-4) Procedure Step 1 Determine single versus multiple and geographic redundancy for data center deployments. Cisco recommends Layer 3 Geo-redundancy for HCS, deploying two data centers without SAN mirroring. If you use Layer 2 Geo-redundancy instead of clustering over the WAN, you will need to determine whether to deploy the two data centers as active-active (which requires LAN and SAN extension) or active-standby 16

29 Initial System Requirements Planned Growth Identify Geographical Locations for Customer Deployment for Planning Step 2 Step 3 Step 4 (which requires only SAN extension). This in turn will determine your DC interconnect requirements; active-standby required SAN extension, whereas active-active requires both LAN and SAN extension. Determine available VMware redundancy and HA options, such as VMware HA and VMware vmotion. Determine blade and chassis redundancy, including spares and distribution of VM. Determine data center redundancy, data center core, aggregation, access layer, data center UCS platform and data center SAN storage: Redundant Platforms (power, cards) Redundant Layers: box, box redundancy Redundant Fiber Channel storage Redundant connections and paths Virtualization VM tool set Application Redundancy (Step 5) Step 5 Plan for application redundancy, including failover redundancy and redundant links; again, Cisco recommends Layer 3 connectivity between UC applications. You will need to determine the desired round trip time delay for each application. Note Application redundancy applies to all UC applications as well as Cisco HCS Provisioning, Assurance, and Domain Management applications. If applications are deployed within a single data center, we recommend that you deploy the virtualized applications on a different Unified Communications chassis if possible or at least upon different VMware ESXi hosts (server blades). See the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide for more information and clustering recommendations for Cisco Unified Communications Manager, Cisco Unity Connection, and HCS for Contact Center. Identify Geographical Locations for Customer Deployment for Planning Procedure Identify geographical locations planning considerations for customer deployment. Consider the number of different locations you plan to have as this can impact your initial deployment as well as your options for further growth. In particular, the number of locations, for example can affect the sizing of your Cisco HCM-F. You should also consider distance between various locations as this could affect network latency or potential delay issues. 17

30 Identify Trunking Services Initial System Requirements Planned Growth Identify Trunking Services Procedure Depending on what type of provider you are, determine which trunking services you will need to provide, either central, local breakout or a combination of both. For additional details on these trunking choices, see Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Central Breakout Choosing central breakout may include additional obligations such as providing a carrier license, ability to provide emergency services, especially in situations where local breakout is not offered, and enabling Lawful Intercept (LI). With central breakout, you have a choice of using Cisco Unified Border Element (SP Edition), Perimeta SBC or an existing carrier grade session border controller. Additionally, if SS7 interconnect or softswitch functionality is required, you can use the Cisco vpgw in addition to Cisco Unified Border Element (SP Edition) or Perimeta SBC. For Large Enterprise deployments, Cisco Unified Border Element (SP Edition) or Perimeta SBC is optional. You also have a choice of using Cisco Integrated Services Router G2 Series offering SRST or BRI, PSTN and SIP trunking services. Local Breakout Local breakout is a simple set up, that allows you to rely on another organization to provide the regulatory services for you. Local breakout maybe a good alternative if you do not: 1 Want the expense of investing in centralized aggregation infrastructure such as session border controllers. 2 Want the additional burden of complying with and offering regulatory services. 3 Have the license or operating in jurisdictions that do not allow certain organizations to offer central interconnect services, such as SIP or SS7. 18

31 CHAPTER 3 Data Center Prerequisites, page 19 Data Center Workflow, page 20 Determine Data Center Requirements, page 20 Gather Data for Initial Data Center Planning, page 20 Determine the Data Center Deployment Model, page 21 Determine Details About Applications, page 22 Identify the Various Networking Resources, page 22 Determine Virtual Machine Distribution and Connectivity, page 25 Determine DMZ Requirements, page 25 Investigate Storage Planning, page 26 Prerequisites Before you plan the data center for your Cisco HCS installation, make sure that you: Review and have access to the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Complete the actions outlined in previous sections of this guide including: Initial system requirements and planned growth 19

32 Data Center Workflow Data Center Data Center Workflow Determine Data Center Requirements The following procedures lists the high-level steps required to determine your data center requirements. Procedure Step 1 Gather Data for Initial Data Center Planning, on page 20. Step 2 Determine the Data Center Deployment Model, on page 21. Step 3 Determine Details About Applications, on page 22. Step 4 Identify the Various Networking Resources, on page 22. Step 5 Determine Virtual Machine Distribution and Connectivity, on page 25. Step 6 Determine DMZ Requirements, on page 25. Step 7 Investigate Storage Planning, on page 26. Gather Data for Initial Data Center Planning Procedure Step 1 Collect and estimate the type of tenants using detailed information about your system. You should have already done this as part of Complete Tenant Matrix, on page 5. 20

33 Data Center Determine the Data Center Deployment Model Gather information about customers, customer average sizes, future growth, security requirements, local versus central break out, regulatory requirements, and access models. Step 2 Step 3 Step 4 Step 5 Determine if there are any other services that are offered from the same data center as Cisco HCS. Determine the locations and the number of data centers that you plan to deploy for Cisco HCS. Locations and number of data centers are determined based on target market proximity requirements, redundancy requirements, size, and access models. All of these factors can affect your costs. For UC applications, for example, you should determine whether all of your customers will have the same redundancy or whether the redundancy is determined on a per-customer basis. Determine whether you have a single or multiple data center setup. Choose your site deployment type. Based on decisions made in Determine Your HCS Data Center Deployment Model, on page 9, decide the type of site for your data center: Hosted Extender Remote managed Hosted Private Cloud/Large Enterprise Determine the Data Center Deployment Model Using the information collected about the locations, the number of data centers and the capital expenditure determines your deployment model, such as Large PoD, Small PoD or Micro Node. You may have already done this in Determine Your HCS Data Center Deployment Model, on page 9. For further information see the Cisco Hosted Collaboration Solution, Release 10.6(1) Capacity Planning Guide Procedure Step 1 Examine key attributes to determine the data center deployment model: Number of tenants Average tenant size Total dedicated UC instances Total shared UC instances Total UC instances and clusters Supported applications Step 2 Use the data and capacity requirements to determine the data center deployment model across one or more data centers. 21

34 Determine Details About Applications Data Center Determine Details About Applications Procedure Step 1 Step 2 Determine whether the management applications will be NATted into a Customer Domain. Review the Cisco Hosted Collaboration Solution Compatibility Matrix to determine the required application versions for the current release. For the most recent compatibility information, see the compatibility matrix from the Cisco HCS documentation page Identify the Various Networking Resources You need to build your network infrastructure with consideration of the following networking resources: Virtual machine templates: Details about these templates and other sizing considerations can be found in the Unified Communications Virtualization Sizing Guidelines. Service profiles on Cisco Unified Computing System (UCS) Manager: Decide how many service profiles you want for your system. From a hardware perspective, the best service profile choice is two profiles when you compare upgrade reduction versus hardware required. If hardware is not an issue, four service profiles is the best choice. Addressing scheme for the UC applications: For more details, refer to IP Addressing for HCS Applications, on page 23. Management domain addressing. NATted address pools in management domain for UC applications: For more details, refer to NAT Planning Considerations, on page 23. VLANs: Use the recommended numbering scheme. For more details, refer to Grouping VLANs and VLAN Numbering, on page 24. For details on dedicated virtual routing and forwarding (VRF) for Shared Instance, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Capacity Planning Guide. PSTN connectivity: For more details, refer to Identify Trunking Services, on page 18. Remote site access: Consider the following options for remote site access: 1 Site-to-Site VPN 2 Line Side access or Over-the-Top (OTT) VPN 3 Cisco Unified Border Element (SP Edition) or Perimeta SBC as a session border controller for SIP trunking 4 MPLS VPN 5 AnyConnect 22

35 Data Center IP Addressing for HCS Applications 6 FlexVPN 7 Plan for Expressway Deployment to allow roaming users to connect remotely. IP Addressing for HCS Applications One VLAN for each customer must be dedicated for each Cisco HCS Enterprise customer. Overlapping addresses for customer UC infrastructure applications of each customer is supported or one VLAN for each shared UC application instance for Shared Instance. The option to select the address pool from which addresses will be assigned for the customer's UC infrastructure applications (Cisco HCS Instance) is supported. This option is necessary to avoid any conflicts with customer-premises addressing schemes. Note When deploying Cisco HCS in the hosted environment, you must not have NAT between any end device (phone) and the Cisco Unified Communications Manager (UC application) on the line side, because some of the mid-call features may not function properly. However, when Over The Top access is supported (using Expressway, etc.), there can be NAT in front of the endpoint. It is also recommended that the HCS Management applications not be deployed within a NAT. Using NAT between the vcenter Server system and ESXi/ESX hosts is an unsupported configuration. For more details, see NAT Planning Considerations HCS-LE Deployment For an HCS-LE deployment (single customer only), implementing Network Address Translation (NAT) between your management applications and Unified Communications applications is not required. If you implement NAT in this scenario, the synthetic call feature of Cisco Unified Operations Manager is not available. Prime Collaboration Assurance Deployment Prime Collaboration Assurance supports static NAT. You can manage customer endpoints behind NAT in the following scenarios: Your voice or video endpoints are registered to the Call Controller and configured with the private IP address of the endpoints. You can manage these endpoints in Cisco Prime Collaboration with a public IP address (managed IP address). Your TelePresense endpoints are provisioned to the Cisco TelePresence Exchange System (CTX). You can manage these endpoints in Cisco Prime Collaboration with a public IP address (managed IP address). Note Cisco Unified Communications Manager cannot be shared and must be configured with the private IP addresses of the endpoints. The following limitations apply: The monitoring of TelePresence endpoint health, video session diagnostics, and medianet are supported with public IP addresses. 23

36 Grouping VLANs and VLAN Numbering Data Center Real Time Protocol-based diagnostic tests, such as synthetic tests, are not supported. Data from phone XML discovery is not available for phones. The autodiscovery and video test call features are not supported. Video session statistics and session information are not available for phones even when they are configured for full visibility. Sensor-based call quality reports are not supported. Media Path Analysis is not supported. For more information about features in Prime Collaboration Assurance MSP mode, see the Cisco Prime Collaboration Assurance Guide - Advanced: prime-collaboration/products-user-guide-list.html. Grouping VLANs and VLAN Numbering Cisco recommends that when you design Layer 2 for a Cisco HCS deployment, you group the VLANs based on their usage. The current Cisco HCS data center design assumes that each end customer consumes only two VLANs; however, it is possible to configure four VLANs for each end customer. Use the following VLAN numbering scheme if four VLANs are configured for each end customer: 0100 to 0999: UC Apps (100 to 999 are the customer IDs) 1100 to 1999: outside VLANs (100 to 999 are the customer IDs) 2100 to 2999: hcs-mgmt ( 100 to 999 are the customer IDs) 3100 to 3999: Services ( 100 to 999 are the customer IDs) Use all the unused VLANs x000 to x099 (where x is 1, 2, or 3) and VLANS 4000 to 4095 for other purposes Use the following number scheme if only two VLANs are configured for each end customer: 0100 to 1999: UC Apps (100 to 999 are the customer IDs for Group 1) 2100 to 3999: outside VLANs (100 to 999 are the customer IDs for Group 1) Use the following numbering scheme for additional end customers: 2100 to 2999: UC Apps (100 to 999 are the customer IDs for Group 2) 3100 to 3999: outside (100 to 999 are the customer IDs for Group 2) Use the unused VLANs for other purposes While this is the recommended grouping of VLANS to help you scale the number of customers that can be hosted on a Cisco HCS platform, you may reach the upper limit of customers due to limitations in other areas of the Cisco HCS solution. 24

37 Data Center Determine Virtual Machine Distribution and Connectivity Determine Virtual Machine Distribution and Connectivity Procedure Step 1 Determine the virtual machine distribution. For more information on recommendations, refer to the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Oversubscribed clusters Non oversubscribed clusters Step 2 Analyze the available bandwidth. Based on the deployment model, estimate: The bandwidth needed between data centers. The aggregate bandwidth needed between the data center and CPEs. The aggregate bandwidth needed between the datacenter and PSTN network. Step 3 Step 4 Determine the MPLS VPN peering arrangement between Cisco HCS Data Center and MPLS provider. Determine whether to use Over-The-Top access or site-to-site VPN for remote access through the Internet. Determine DMZ Requirements For information on determining DMZ requirements for Expressway configuration see Data Center Network Configuration Overview, on page 25. Data Center Network Configuration Overview This section provides a guide for configuring Collaboration Edge/OTT in the Cisco HCS data center (DC). Use this guide in conjunction with, but not as a replacement for, the Cisco Expressway documentation. Two additional VLANs are required to accommodate ASA contexts, global DMZ inside and outside. The customer inside and outside VLANs should already exist. Configuration is required in the Nexus 7000, Nexus 1000 (and, optionally, in the Nexus 5000, if deployed), UCS Manager, and ASA. The global DMZ inside VLAN (after Firewall) and the customer outside VLAN should be extended into the DC. These VLANs are used on the virtualized Cisco Expressway-E. Expressway in OTT Deployments: Cisco Expressway-E hosts the public IP address. The client accesses this address by way of the public Internet. Cisco Expressway-E typically sits in the DMZ of the enterprise network. In the HCS DC, Cisco Expressway-E runs on UCS behind the ASA. Cisco Expressway-C sits in the same IP address space as Cisco Unified Communications Manager. Communication between Cisco Expressway-C and Cisco Expressway-E is through the ASA, which provides the NAT and firewall functions. OTT for Shared Instance with Multiple Expressway: One Expressway (E and C) is required for each customer in a Shared Instance deployment. Each customer requires a separate domain. 25

38 Investigate Storage Planning Data Center Shared Expressway for Business to Business Dialing: Cisco Expressway-E hosts the public IP address. The non-hcs businesses access this address by way of the public Internet. Cisco Expressway-E typically sits in the DMZ of the shared network and is sandwiched between two firewall contexts on ASA (Common outside context and shared inside context) to create a DMZ. The Expressway-E is connected to the Expressway-C through the shared internal firewall context. Communication between Cisco Expressway-C and Cisco Expressway-E is through the ASA, which provides the NAT and firewall functions. The Expressway-C is peered with the session border controller (as a neighbor). For more information, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Investigate Storage Planning Consider the following for storage planning. Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Determine capacity needs. See Cisco Hosted Collaboration Solution, Release 10.6(1) Capacity Planning Guide for more information about capacity. Determine storage connectivity options such as such as FCOE (Fiber Channel over Ethernet), FC (Fiber Channel) or NAS. Micro Node deployments must use local storage. Important There is no shared storage array switch interoperability requirement for a Micro Node deployment. Micro Node leverages local Direct-attached storage (DAS) within the UCS C-series. Currently only UC on UCS Tested Reference Configuration servers are supported within HCS. Therefore, a shared storage array is not applicable for a Micro Node installation. A VMware Virtual SAN (VSAN), software-defined shared storage using the local DAS within the C-Series server for virtual machines, is not a supported deployment model and should not be implemented. Determine approved storage vendors for UCS with SAN or NAS. See UCS Hardware and Software Interoperability Technical References at support/servers-unified-computing/unified-computing-system/products-technical-reference-list.html for details on approved storage vendors for UCS with SAN or NAS. Determine storage tier, either multi-tier or single tier. Using tiers lets you distribute capacity across multiple tiers. Larger deployments should consider their capacity distribution carefully. Consider storage raid array recommendations. For more details, see Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide for more details. Determine LUN sizing. For more details, see Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. 26

39 CHAPTER 4 License Planning Prerequisite, page 27 License Planning Workflow, page 28 Related Documentation, page 28 License Planning Considerations, page 28 Determine Data Center Infrastructure Licenses, page 30 Determine Data Center Storage Licenses, page 30 Determine VMware Licenses, page 30 Determine UC Applications, page 31 Determine HCS for Contact Center, page 31 Third-Party Software Licences, page 31 Determine HCS Management Licenses, page 32 License Activation Considerations, page 32 Prerequisite This chapter provides a high-level overview of the planning that must be done prior to acquiring and activating licenses for applications and management components running on HCS. This plan covers: Identifying licenses that must be ordered for HCS Planning for other components or pieces that are not supported by Cisco Prime License Manager Determining the costs of licensing, and how those costs impact decision-making License planning involves the following steps: Determine data center infrastructure licenses. Determine data center storage licenses. Determine VMware licenses. Determine UC Application licenses. 27

40 License Planning Workflow License Planning 5 Determine HCS for Contact Center licenses. 6 Determine Third Party software licenses. 7 Determine HCS Management licenses. 8 Determine Cisco Expressway licenses. 9 Determine Rich Media Session licenses. 10 Determine Cisco Jabber Guest Server licenses. 11 License activation considerations. For more information on Licensing for Cisco HCS, see Cisco Hosted Collaboration Solution, Release 10.6(1) License Management License Planning Workflow Related Documentation Refer to the following documents for further information about related licensing applications and products: Cisco Hosted Collaboration Solution, Release 10.6(1) License Management Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide Cisco Prime License Manager User Guide, Release 10.5(1) License Planning Considerations HCS License Manager (HLM) Planning Considerations HCS License Manager (HLM) is an HCM-F service that provides centralized license management for HCS. HLM extends the functionality of Prime License Manager beyond the scope of one enterprise for use by service providers. HLM is used to assign each customer and its clusters to an Prime License Manager. HLM aggregates license usage by each cluster from each Prime License Manager into a License Summary report. In HCS 10.0(1) and later, Unified Communications Manager and Cisco Unity Connection are the only UC applications supported by HLM. 28

41 License Planning Prime License Manager Planning Considerations Consider the steps in the following procedure for HLM planning: Use one HLM for each installation of HCS. Set up each Prime License Manager in the HLM. Load HCS licenses on a Prime License Manager before configuring the Prime License Manager on an HLM When new customers are onboarded, they and their clusters must be assigned to an Prime License Manager through the HLM. Do not use the native management interface of Prime License Manager to assign a cluster. Always use the HLM to assign clusters to a Prime License Manager. Prime License Manager Planning Considerations Prime License Manager manages licensing for Unified Communications Manager clusters, and Cisco Unity Connection servers for multiple customers deployed in HCS. Typically, multiple customers are assigned to the same Prime License Manager server. If a customer has multiple clusters, all clusters for the customer must be assigned to the same Prime License Manager server (that is, you cannot assign some of the customer's clusters to one Prime License Manager server, and the rest to another Prime License Manager server). HCS licenses are registered to and loaded and activated onto the Prime License Managers deployed in HCS. The Prime License Managers deploy the HCS licenses to the UCM clusters and Unity Connection servers that are assigned by the HLM. Take the following actions for Prime License Manager planning: Procedure Step 1 Determine if you need multiple instances of Prime License Manager, which would be the case in either of the following scenarios: If a Service Provider has resellers and wants to segregate the HCS licenses it provides to each reseller If there will be more than 1000 Unified Communications application clusters in the HCS deployment Step 2 Step 3 Step 4 Install the Prime License Manager on the same management network as HCM-F so that Prime License Manager can access all Unified Communications application clusters. Install standalone Prime License Managers in the HCS Management domain. Set up each customer domain firewall to allow Prime License Manager to connect to UCM and Unity Connection through the HTTPS port 443 from the HCS management domain. Plan for appropriate usage of the Prime License Manager web interface: For initial configuration, to generate license requests, to load license files, and to display license usage by cluster if desired. To assign a cluster, when using only the HLM, to an Prime License Manager instance so that the HLM can aggregate license usage for all customers and clusters. 29

42 Determine Data Center Infrastructure Licenses License Planning Determine Data Center Infrastructure Licenses The following data center infrastructure components require specific licensing in conjunction with the hardware feature capabilities: Nexus switches (1000, 5500, 7000) ASA Perimeta SBC SAN UCS Manager ACS VNMC Prime Network Services Controller Adaptive Security Device Manager (ASDM) Device Manager Cisco Prime Network Registrar (formerly CNR) Open Source TACACS (alternate for ACS Appliance) For more information on these components, refer to the Cisco Hosted Collaboration Solution, Release 10.6(1) License Management. Determine Data Center Storage Licenses The following data center storage components require specific licensing: SAN Nexus switches (5000, 5500, 7000) MDS switches UCS Manager Note If you are using SAN-based storage, you must have storage access licensing for your Cisco components and for your SAN-based storage. For more information, contact your Cisco sales engineer. Determine VMware Licenses For VMware licensing information, refer to the License Management for Cisco Hosted Collaboration Solution. 30

43 License Planning Determine UC Applications Determine UC Applications The following UC applications require specific licensing: HCS software licensing bundles HCS end customer license Cisco Telepresence Jabber clients Jabber server Add-On licenses: CUAC (server based and serverless) CER Note Cisco Expressway Server, Jabber Guest and Cisco Expressway Rich Media Session Licenses are add-on, session based licenses. They are managed separately from HLM/PLM and installed in Cisco Expressway. For more information see tsd-products-support-series-home.html For information on determining licensing requirements for HCS License Manager and Prime License Manager, see License Planning Considerations, on page 28. Determine HCS for Contact Center HCS for Contact Center is an Add On license. For more information, see ps12796/prod_installation_guides_list.html. Third-Party Software Licences The following third-party software requires licensing: CUAC Cisco Paging Server (also known as Singlewire - InformaCast Basic Paging) Prime Collaboration Assurance VMware Virtual Center (vcenter) HCS for Contact Center Identity Providers - CA SiteMinder, Shibboleth, Microsoft AD FS, OpenAM, Oracle Identity Manager For more information on Third-Party Software Licenses, see Cisco Hosted Collaboration Solution, Release 10.6(1) License Management. 31

44 Determine HCS Management Licenses License Planning Determine HCS Management Licenses The following HCS Management components require specific licensing: Fulfillment licenses CCDM CUCDM HCM-F - HLM Assurance licenses Cisco Prime Collaboration Assurance For more information, see the License Ordering for Cisco Hosted Collaboration Solution guide. License Activation Considerations The following must be considered for license activation: efulfillment versus offline fulfillment - efulfillment uses an Enterprise License Manager or Prime License Manager to connect directly to the Cisco License web site to fulfill licenses from a PAK. Consequently, the Enterprise License Manager or Prime License Manager must have access to the Internet. If for security or other reasons, the Enterprise License Manager or Prime License Manager in the HCS deployment does not have direct access to the Cisco License website, then offline fulfillment can be used. For details on both methods, see Cisco Hosted Collaboration Solution, Release 10.6(1) License Management. For information on the conversion from ELM to PLM, see Cisco Prime License Manager User Guide, Release 10.5(1). Unified Communications Software Subscription (UCSS) activation - In HCS there are ways to purchase licenses and delay auto-activation. You need to consider UCSS activation when you are adding customers. For more information on license activation, refer to the Cisco Hosted Collaboration Solution, Release 10.6(1) License Management 32

45 CHAPTER 5 Customer Premise Equipment Prerequisites, page 33 Customer Premise Equipment Workflow, page 34 Determine the Type of Site(s), page 34 Determine Customer Premise Equipment Router Model, page 34 Determine Services on Router Model and Location of Services, page 35 Determine Analog Gateways, page 35 Determine Endpoints, page 35 Determine Access Methods, page 36 Determine Standalone Firewalls, page 36 Determine Networks for Customer Premise Equipment, page 36 Prerequisites Before you plan the customer premise equipment, make sure that you: Review and have access to the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Complete the actions outlined in previous sections of this guide including: Initial system requirements and planned growth Data center requirements Note Make sure to review the Cisco Hosted Collaboration Solution Compatibility Matrix for a full list of licensing details. 33

46 Customer Premise Equipment Workflow Customer Premise Equipment Customer Premise Equipment Workflow Determine the Type of Site(s) Dedicated Server Determine the type of site(s) that you plan to deploy. For detailed information on the different sites, refer to Determine Your HCS Data Center Deployment Model, on page 9. Dedicated server refers to an Cisco HCS model of applications available for Micro Node deployments where one C-series server contains only one customer, but may have one or more UC applications running on the same server for that customer (for example Cisco Unified Communications Manager or Cisco Unity Connection). Determine Customer Premise Equipment Router Model Procedure Determine your router model based on the following UC application criteria: Cisco Unified Survivable Remote Site Telephony (SRST) Cisco Unified Border Element Enterprise Edition PSTN Local Breakout - VoiceXML gateway Cisco Unified Communications Domain Manager media resources such as conferencing, transcoding and Media Termination Point 34

47 Customer Premise Equipment Determine Services on Router Model and Location of Services Your HCS system needs a router, such as ISR G2 series. Make sure you have accurate cards, licensing and so forth for this router. You should take all of these considerations into the type of router you choose as this device does many of the key functions of your customer premise system. Many different models are available with a wide range of performance and scale capacities. For more details, refer to isr. Determine Services on Router Model and Location of Services Procedure Step 1 Determine what services you need to run on your router model: Cisco Unified Border Element Enterprise Edition SRST Step 2 Step 3 Determine if these services will reside on your router model, typically ISR G2, or on other standalone routers. Determine customer premise conferencing resources. Determine Analog Gateways Procedure Determine the analog gateways that you need based on the devices that will be used: ATA series VG series ISR router models Determine Endpoints Procedure Determine the TelePresence and video endpoints that will be used: Desktop hard phones Desktop clients Mobile clients 35

48 Determine Access Methods Customer Premise Equipment Video endpoints Determine Access Methods Procedure Determine access methods: MPLS: This is typical preferred choice for an HCS deployment. Site-to-Site VPN: The customer premise router must be enabled and capable of supporting IPsec VPN. Flex VPN: FlexVPN is deployed in HCS as a site-to-site VPN, between the customer site and the hosted HCS datacenter. AnyConnect: Cisco AnyConnect VPN Client provides secure SSL connections for remote users. Expressway OTT Line Side for Cisco Unified Border Element Enterprise Edition Determine Standalone Firewalls Procedure Determine your standalone firewalls. Consider the following for customer premise equipment: NATting is or is not performed at the customer premise Multiple routers or single router at customer premise IP addressing at customer premise Make sure that whatever set up you choose, that all ports are open for the Cisco HCS system, refer to Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Determine Networks for Customer Premise Equipment Procedure Step 1 Determine LAN network, refer to support_protocol_home.html for more information. 36

49 Customer Premise Equipment Determine Networks for Customer Premise Equipment Step 2 Determine wireless LAN (WLAN) network including Access Points (APs), refer to wiki/internetworking_technology_handbook#lan_technologies for more information. 37

50 Determine Networks for Customer Premise Equipment Customer Premise Equipment 38

51 CHAPTER 6 Service Fulfillment Planning Prerequisites, page 39 Service Fulfillment Workflow, page 40 HCM-F deployment models, page 40 Service Inventory planning considerations, page 41 Platform Manager Planning Considerations, page 41 Prime Collaboration Deployment for UC Applications, page 45 Infrastructure Platform Automation (IPA) Planning Considerations, page 48 Compatibility considerations, page 49 Call Detail Records, page 49 LDAP Integration Considerations, page 50 Single Sign On Considerations, page 50 Cisco Unified Communications Domain Manager Planning Considerations, page 50 Resource Requirements, page 51 Prerequisites Before you plan Service Fulfillment for your Cisco HCS installation, make sure that you: Review and have access to the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide available here: implementation_design_guides_list.html. Complete the actions outlined in previous sections of this guide including: Initial system requirements and planned growth Data center requirements Licensing requirements Customer premise equipment requirements 39

52 Service Fulfillment Workflow Service Fulfillment Planning Plan to use the Cisco Unified Communications Domain Manager for Service Fulfillment tasks. Gather credentials for vcenter, UCSM, and CUCDM for provisioning into HCM-F. Network planning Include these elements for L2 and L3 network design planning. Management Network design (with complete VLAN/VRF) Management Network implementation and validation (vcenter where required) Have a security strategy or plan, including a list of certificates needed. Evaluate the list of available language localizations for HCM-F and determine if you want to use one. Service Fulfillment Workflow HCM-F deployment models HCM-F scales to the following deployment models: 1 Default Deployment Node 1: SDR + Core HCM-F applications No API Gateway Proxy HCM-F NBI access via Cisco Unified Communications Domain Manager 10.6(1) SBI (apps + dm ) direct access 2 Transitional Deployment (2 Nodes (transition to 3 nodes or API trial) 40

53 Service Fulfillment Planning Service Inventory planning considerations Node 1: SDR + Core HCM-F applications (App Node) SBI and HCM-F NBI access via API Gateway Proxy HCM-F API access directly to NBI-WS 3 Full Deployment (N Nodes (3 or more HCM-F nodes) Node 1: SDR + Core HCM-F applications Node 2: API Gateway Proxy (memory cache of routing information) Node 3: API Gateway Proxy (memory cache of routing information) Load Balancer SBI and HCM-F NBI access via LB which distributes traffic across API Gateway Proxy nodes Service Inventory planning considerations Service Inventory is a Cisco HCM-F service that queries Cisco Unified Communications Domain Manager 10.6(1) daily and reports detailed configurations of customers, subscribers, and devices for all Unified Communications Manager and Cisco Unity Connection application instances. The Service Inventory report also provides a summary of all customers, UC clusters, users, and end devices deployed within HCS. Note For deployments of both Cisco Unified Communications Domain Manager 8.x and Cisco Unified Communications Domain Manager 10.x, Service Inventory pulls customer information from both and generates a report file (or files) for all customers. Complete the following steps when planning service inventory: Procedure Step 1 Step 2 Step 3 Plan to deploy an SFTP server (and an optional backup SFTP server) with adequate capacity to receive Service Inventory report files. A typical compressed file size would be 8-10 MB for 200,000 users. Decide whether the files will be pushed or pulled, scheduled or automatic. Decide which application you will use to parse the detailed inventory data into a form that can be used by your business system. Note For details on Service Inventory reports and their formatting, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Maintain and Operate Guide. Platform Manager Planning Considerations Platform Manager is a Cisco Hosted Collaboration Mediation Fulfillment service that allows you to schedule and monitor the automated installation, upgrade, restart and backup of multiple application instances across customers for the following applications: 41

54 Limitations and restrictions Service Fulfillment Planning Cisco Unified Communications Manager Cisco Unity Connection Cisco Unified Presence / Cisco Unified IM and Presence Take the following actions for Platform Manager planning as you onboard each customer or cluster: Determine the number of server groups needed. Select server groups for backup tasks that will avoid overloading blade hardware or I/O bandwidth to data storage LUNs. Put all servers (for example, Publishers) on a specific ESXi-Host or blade into a common server group. This way the backup of the servers on the host is done serially, minimizing the backup CPU load on the host. Spread the SFTP servers assigned to backup groups across different storage LUNs so that backup transfer load is spread out. Ensure that no more than two applications are backed up on a specific blade at any one time. For details on Platform Manager, see the Cisco Hosted Collaboration Mediation Fulfillment Install and Configure Guide, Release 10.6(2). Limitations and restrictions The following list describes the current limitations for Platform Manager. Platform Manager is not a diagnostic tool. An error message does appear on the task list page if a task fails; however, you should use your usual set of tools and procedures to diagnose and correct the problem. The SOAP services do not replace the existing OS Administration and CLI upgrade processes. You can still upgrade your servers using the application GUIs, or CLI commands. Platform Manager is just another way to upgrade, restart, or switch versions on the application servers. Servers functionality classification Platform Manager offers a wide range of different user-defined servers types to accommodate the management of potentially thousands of servers. You can tag servers with one or more roles such as publisher, subscriber, TFTP, music on hold, secondary TFTP, secondary music on hold to help classify the different servers in your system. You can then tag your servers with one or more server roles for easier identification. Server roles allow you to classify each server in your Platform Manager, making your task creation and viewing more efficient. Server roles include: Call Processing Backup Call Processing Music on Hold TFTP Backup TFTP 42

55 Service Fulfillment Planning Limitations and restrictions Primary Presence Secondary Presence Primary Voic Secondary Voic Note Server roles are labels to help users identify a server. Setting a server role does not activate any services. Mislabeling a server does not cause any service outages. Server group usage Server groups allow you to logically join together different servers that you want to perform tasks on as a group. You have the flexibility to group servers to accommodate the varied requests for installation, backup, upgrades and restart tasks. Note A task is applied to all servers under the same server group. If you do not want to lose a service, do not put your Active Call Control server in the same server group as its backup when you run a switch version or reboot task. Server groups allow you to logically combine various servers; for example, you can create server groups for the following areas: Server Group by Role - Create call processing server groups and a backup processing server group. Server Group by Product - Create product A and product B groups. Server Group by Customer and Product - Create customer A-product A and customer A-product B groups. Note You can have as many servers as you like in a group; however, all servers must be of the same product type. A server can be a member of more than one group. Limitation in server groups The following limitations apply when you create server groups: You cannot have multiple products in the same server group. For example, if you have a customer that has Cisco Unified Communications Manager and Cisco Unified Communications Manager IM and Presence Service, you must create two groups for this customer. You cannot have publisher servers in the same group as subscriber servers if you want to run upgrade or switch version tasks on the group. For example, if you want to upgrade all of a customer s services, you must create at least two groups: a publisher server group and at least one subscriber server group to execute the task on the publisher servers before the subscriber servers. This does not apply to restart 43

56 Limitations and restrictions Service Fulfillment Planning server tasks. Publishers and subscribers can be in the same group if that group is used for restart server task. Task creation Tasks are the main function of Platform Manager. After you have configured all of your servers and server groups within Platform Manager, you can create a variety of tasks that help you streamline any upgrade, switch version, or restart process. These tasks also help you to sequence various actions based on specific options you select. For example, you may want your publisher servers to upgrade before your subscriber servers within a certain application group. Or you may want a specific group to upgrade before any other group. The create tasks pages can help you with this. The Backup Schedule task feature provides a central location to schedule and monitor backups while reusing of the existing backup infrastructure-the Disaster Recovery System. This feature also enables backup load balancing. Data filtering Platform Manager has a powerful filtering capabilities to allow you to view specific information. The following pages have filter options available: Servers Server Groups File Servers Task List Field Quick Filter Advanced Filter Set Default Filter Description View the data by any column on the page. For example, if you want to only see a specific customer servers, you can filter on a customer name. If you want to see all of your Unified Communications Manager servers, you can filter on product and only your Unified Communications Manager servers appear. View data by multiple columns and multiple terms in the same column. For example, perhaps you want to see all the Unified Communications Manager and Cisco Unified Presence server groups for customer A and customer B. Add all of the details in the search boxes and your results appear. Set a default view for your content. For example, you may want the Quick Filter screen to be the default view on the servers page to it does not have to load all of servers every time to you go the page. 44

57 Service Fulfillment Planning Best practices Best practices The following are recommendations for configuring your systems as suggested by Cisco development and testing teams. Use the SDR Synchronization or the Server Import functionality to populate the servers in your system if possible. Use your standard pre- and post- upgrading procedures when performing this action. Platform Manager simplifies this process for you. Create groups with multiple servers that you perform similar tasks on. When you name groups, keep the terminology simple and use easy-to-recognize names. Use the sequencing feature in a task when you want a second group of servers to wait until the first group is done before performing that task. Use the Backup Schedule task for a more efficient and powerful way to run backups. It helps to control multiple servers that are backed up at the same time and enables load balancing. SFTP servers for DRS backup are configured in Disaster Recovery System (DRS). All the first nodes that use the same SFTP server should be assigned to the same server group for backup, or should be scheduled for backups on different days of the week. For more information, refer to Scheduling Backups and Upgrades of UC Applications. Prime Collaboration Deployment for UC Applications Cisco Prime Collaboration Deployment helps you manage Unified Communications (UC) applications (release 10.x and later). Its primary high-level functions are to: Migrate a cluster of UC servers to a new cluster (such as MCS to virtual, or virtual to virtual). Tip Cisco Prime Collaboration Deployment does not delete the source cluster VMs after migration is complete. You can fail over to the source VMs if there is a problem with the new VMs. When you are satisfied with the migration, you can manually delete the source VMs. Perform operations on clusters (9.2(1) SU2 or later), such as: Upgrade Switch version Restart Fresh install a new release 10.x UC cluster Change IP addresses or hostnames in release 10.x clusters (for a network migration). Cisco Prime Collaboration Deployment supports simple migration and network migration. Changing IP addresses or hostnames is not required for a simple migration. For more information, see the Cisco Prime Collaboration Deployment Administration Guide. 45

58 Prime Collaboration Deployment for UC Applications Service Fulfillment Planning The following tables identify the functions supported by Cisco Prime Collaboration Deployment, Platform Manager, and Infrastructure Platform Automation. Each table identifies the UC applications and versions that the functions support. Support for UC applications and their versions are irrespective of Cisco HCS releases. Table 5: Cisco Prime Collaboration Deployment Functions for UC Applications 10.x and later Product and Functions Cluster Discovery Migration to 10.x Cluster Upgrade Task (Upgrade Application Server or Install COP Files) Restart Task Switch Version Task Fresh Install a New 10.x Cluster Readdress Task (Change Hostname or IP Addresses for One or More Nodes in a Cluster) Cisco Unified Communications Manager 9.1(2) SU2, 10.0(1), 10.5(1), 10.5(2) 9.1(2) SU2, 10.0(1), 10.5(1), 10.5(2) 9.1(2) SU2, 10.0(1), 10.5(1), 10.5(2) 9.1(2) SU2, 10.0(1), 10.5(1), 10.5(2) 9.1(2) SU2, 10.0(x), 10.5(1), 10.5(2) 10.x, 10.5(1), 10.5(2) 10.x Cisco Unified IM and Presence Service 9.1(1) SU1 or optionally 9.1(1) SU2, 10.5(2b), ( ) 9.1(1) SU1 or optionally 9.1(1) SU2, 10.5(2b), ( ) 9.1(1) SU1 or optionally 9.1(1) SU2, 10.5(2b), ( ) 9.1(1) SU1 or optionally 9.1(1) SU2, 10.5(2b), ( ) 9.1(1) SU1 or optionally 9.1(1) SU2, 10.5(2b), ( ) 10.x, 10.5(1), 10.5(2) Not Supported Cisco Unified Contact Center Express 10.0(1), 10.x Not Supported 10.0(1), 10.x 10.0(1), 10.x 10.0(1), 10.x 10.6(x) 10.6(x) Cisco Unity Connection 9.1(2) SU2, 9.x, 10.x Not Supported From 9.x to 9.x 8.6(1), 8.6(2), 9.x, 10.x 9.1(2) SU2, 9.x, 10.x 10.5(x) 10.5(x) From 10.0(1) to 10.x Table 6: HCM-F Platform Manager Functions (for pre-10.x UC Applications) Product and Functions Cluster Discovery Migration to 10.x Cluster Upgrade Task (Upgrade Application Server or Install COP Files) Restart Task Switch Version Task Fresh Install a New 10.x Cluster Readdress Task (Change Hostname or IP Addresses for One or More Nodes in a Cluster) Cisco Unified Communications Manager 9.0.(1), 9.1(1), 9.1(2), 10.0(1 ), 10.5 (2) Not Supported 9.0.(1), 9.1(1), 9.1(2), 10.0(1), 10.5 (2) 9.0.(1), 9.1(1), 9.1(2), 10.0(1), 10.5 (2) 9.0.(1), 9.1(1), 9.1(2), 10.0(1), 10.5 (2) Not Supported Not Supported 46

59 Service Fulfillment Planning Prime Collaboration Deployment for UC Applications Product and Functions Cluster Discovery Migration to 10.x Cluster Upgrade Task (Upgrade Application Server or Install COP Files) Restart Task Switch Version Task Fresh Install a New 10.x Cluster Readdress Task (Change Hostname or IP Addresses for One or More Nodes in a Cluster) Cisco Unified IM and Presence Service 9.0.(1), 9.1(1), 9.1(2), 10.0(1) Not Supported 9.0.(1), 9.1(1), 9.1(2), 10.0(1) 9.0.(1), 9.1(1), 9.1(2), 10.0(1) 9.0.(1), 9.1(1), 9.1(2), 10.0(1) Not Supported Not Supported Cisco Unified Contact Center Express Not Supported Not Supported Not Supported Not Supported Not Supported Not Supported Not Supported Cisco Unity Connection 9.x, 10.0(1), 10.5 (2) Not Supported From 9.x to 9.x 9.x, 10.0(1 ), 10.5 (2) 9.x, 10.0(1), 10.5 (2) Not Supported Not Supported From 9.x to 10.x From 10.0(1) to 10.x Table 7: Infrastructure Platform Automation Functions UC Application Cisco Unified Communications Manager Cisco Unified Presence IM and Presence Service Cisco Unified Contact Center Express Cisco Unity Connection VMware Cloning from Golden Template 9.0.(1), 9.1(1), 9.1(2), 10.0(1) Not Supported 10.0.(1) Not Supported 9.x and 10.0.(1) Readdress Task (Change Hostname or IP Addresses for One or More Nodes in a Cluster) 9.0.(1), 9.1(1), 9.1(2), 10.0(1 ) Not Supported 10.0.(1) Not Supported 9.x and 10.0(1) Cisco supports virtualized deployments of Cisco Prime Collaboration Deployment. The application is deployed using an OVA that contains the pre-installed application. This OVA is obtained with a licensed copy of Cisco Unified Communications Manager software. For information about how to extract and deploy the PCD_VAPP.OVA file, see the Cisco Prime Collaboration Administration Guide. In your Cisco HCS environment, install only one instance of Cisco Prime Collaboration Deployment, which must have the following: 47

60 Infrastructure Platform Automation (IPA) Planning Considerations Service Fulfillment Planning Access to all Cisco Unified Communications Manager clusters for all customers, including those behind a NAT A fixed, non-overlapping IP address Use the Cluster Discovery feature to find application clusters on which to perform fresh installs, migration, and upgrade functions. Perform this discovery on a blade-by-blade basis. Note If you use Cisco Prime Collaboration Deployment to migrate Cisco Unified Communications Manager and Cisco Unified Communications Manager IM and Presence Service to the 10.5(x) (or later) version of those applications, remember to update the version in Cisco Unified Communications Domain Manager. Select the new version in the Version drop list for each application in the Cisco Unified Communications Domain Manager user interface. For more information about features, installation, configuration and administration, best practices, and troubleshooting, see the following documents: Cisco Prime Collaboration Administration Guide: unified-communications/unified-communications-manager-callmanager/ products-maintenance-guides-list.html Release Notes for Cisco Prime Collaboration Deployment: unified-communications/unified-communications-manager-callmanager/products-release-notes-list.html Infrastructure Platform Automation (IPA) Planning Considerations Infrastructure Platform Automation (IPA) is an application designed to be an optional tool used to assist in the automation of the provisioning steps for on-boarding customers inside both the Cisco Unified Communications Manager application and the Cisco Unity Connection by using an XML configuration file that is loaded in Infrastructure Manager within the Cisco HCM-F interface. The automation process includes Virtual Machine cloning from golden templates and running change identity on the Cisco Unified Communications Manager or Cisco Unity Connection Publisher and Subscriber Virtual Machines. If the Virtual Machines are pre-cloned, for example by Cloud-O or manually, IPA performs only identity operations on Virtual Machines. IPA supports deployment of IM and Presence nodes in a Cisco Unified Communications Manager cluster. Golden templates are master copies of Cisco Unified Communications Manager and Cisco Unity Connection that you can reuse or install on multiple virtual machines. They are built on a source system controlled by a service provider. Golden templates are built one for publisher and one for subscriber. After golden templates are built, IPA automates the process of cloning, identity, and post-installation operations of the virtual machine. Note IPA requires the Cisco Nexus 1000V Switch for VMware vsphere and vsphere Enterprise Plus to function. This impacts Micro Node deployments which only require a vnetwork Standard Switch (vswitch) and vsphere Standard. For more information on vnetwork Distributed Switch concepts see Overview of vnetwork Distributed Switch concepts ( ) at the VMware Knowledge Base. Take the following actions for IPA planning: 48

61 Service Fulfillment Planning Compatibility considerations Procedure Step 1 Step 2 Create golden templates one time for the Cisco Unified Communications Manager Publisher, Cisco Unified Communications Manager Subscriber, and Cisco Unity Connection nodes for IPA use. For details on creating golden templates, see the Cisco Hosted Collaboration Mediation Fulfillment Install and Configure Guide, Release 10.6(2). Carefully gather the detailed configuration defined by the XML configuration file. The XML configuration file requires details for the customer organization, Cisco Unified Communications Manager and Cisco Unity Connection applications, and Virtual Machines. Note IPA can only be used in data center deployments. On-premises setup is not supported by IPA because there is no access to the EXSi host. Note Be aware that IPA version does not create the IM and Presence server; you need to create it manually. For details on IPA, see the Cisco Hosted Collaboration Mediation Fulfillment Install and Configure Guide, Release 10.6(2). Compatibility considerations Call Detail Records See the Service Fulfillment compatibility table in Cisco Hosted Collaboration Solution Compatibility Matrix. Service Providers (SPs) can use Usage-based billing, using call detail records (CDRs) or Call Manager Management Records (CMRs) for the enterprise. If a service provider is interested in usage type billing, they can direct CDRs from Unified Communications Manager to their billing system. If Cisco Prime Collaboration Assurance is configured as a management application, the Cisco HCS Provisioning Adapter (CHPA) service configures any CUCM (release 9.0(1) or higher) to send CDRs to Cisco Prime Collaboration Assurance. The option also exists to work with our third-party vendor to consume CDRs and CMRs to produce necessary billing information or invoices. Note NCisco Prime Collaboration Assurance uses CDR and CMR for diagnostic purpose only (not for billing). The Cisco TelePresence Exchange System collects and displays call detail records (CDRs) for calls that are placed on the system. From the administration console, you can view CDR details for the system and export a comma-separated value (.csv) file of that information. The Cisco TelePresence Exchange System retains CDRs for up to 30 days from the recorded end time of the CDR. The system automatically purges CDRs that exceed this 30-day limit. If the total number of CDRs retained by the system reaches 100,000, the system retains only the most recent 100,000 records and automatically purges the rest. The Cisco TelePresence Exchange System also provides an Application Programming Interface (API) for managing and retrieving call records. For more details, see the API User Guide for the Cisco TelePresence Exchange System. 49

62 LDAP Integration Considerations Service Fulfillment Planning LDAP Integration Considerations If you intend to integrate LDAP users into Cisco Unified Communications Domain Manager, you need to identify the LDAP servers that will be used. LDAP servers can be integrated at the provider, reseller, customer, or site level in Cisco Unified Communications Domain Manager. The User Distinguished Name and Base Distinguished Name for LDAP search must be identified for LDAP servers being integrated. Single Sign On Considerations If you intend to deploy Single Sign On (SSO) in Cisco Unified Communications Domain Manager 10.6(1), you need to identify the Identity Provider (IdP) servers that will be used. IdPs can be located at the provider, reseller, or customer levels in Cisco Unified Communications Domain Manager 10.6(1). You will need to be able to upload Service Provider metadata to the IdP and also download IdP metadata. Cisco Unified Communications Domain Manager Planning Considerations Cisco Unified Communications Domain Manager is an integral part of the service fulfillment subsystem. It is primarily responsible for the configuration and registration of users, subscribers, and endpoints with the back-end Cisco Unified Communications Manager, Cisco Unity Connection, and IM and Presence Service servers. Cisco Unified Communications Domain Manager provides the day-to-day service and device provisioning and management tools. One instance supports all deployment sizes up to 200,000 subscribers. Consider the steps in the following procedure for Cisco Unified Communications Domain Manager planning: Procedure Step 1 Step 2 Determine if WebEx and Contact Center will be integrated. Cisco Unified Communications Domain Manager is deployed either as a single node, or a cluster of multiple nodes with High Availability (HA) and/or Disaster Recovery (DR) qualities. Each node can be assigned one or more of the following functional roles: WebProxy load balancing across multiple application roles Application transactional business logic Database persistent storage of data The following combined roles are defined: Standalone combines the Application and Database roles for use in a non-clustered environment Unified similar to the Standalone role combining Application and Database roles, but clustered with other nodes to provide HA and DR capabilities. 50

63 Service Fulfillment Planning Resource Requirements Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Determine which dial plan to use. See the "Customer specific dial plan" section in this document For user activations, decide if you will use automated system activations based on system inventory or the Cisco Unified Communications Domain Manager admin interface. Decide if you want to use the Cisco Unified Communications Domain Manager user self-care portal. If yes, you need to allow access for customers or end users. Check to see what the static deployment requirements are on Cisco Unified Communications Manager clusters before managing a cluster from Cisco Unified Communications Domain Manager. Gather the following information: a) Location of the Cisco Unified Communications Domain Manager b) Determine latency between Cisco Unified Communications Domain Manager and UC applications, which must be within defined limits. The maximum supported latency is 200 ms Round Trip Time (RTT). Note A higher latency (e.g. 250 ms RTT) may work in certain instances, but this must be tested prior to deployment. Determine if additional languages are required for the system other than English. Determine if custom branding is desired. For a Shared Instance deployment: a) A single Cisco Unified Communications Domain Manager can manage both types of clusters (dedicated and shared instance) in one HCS deployment. b) You can provision a single Cisco Unified Communications Domain Manager with separate service providers for a shared instance cluster and a standard cluster. Note License Manager and SI reporting do not provide tenant-specific information. Resource Requirements The following table lists the resource requirements for the listed SF components. HCS 10.6(1) Fulfillment component vcpu RAM (GB) Storage IOPS OS 51

64 Resource Requirements Service Fulfillment Planning HCS 10.6(1) CUCDM Multi-node 2GHz 8GB 370GB partitioned as follows: 20GB for OS GB for application 10GB for logs 50GB for compressed backups 250GB for database WebProxy Nodes 2GHz 4GB 150GB HCM-F 4 x 1.8 GHz 16 (Res) PLM 1 vcpu x 1.8 GHz CCDM (DB server) 565 (web server) Microsoft Windows The Database storage partition is sized at the initial installation to support the maximum deployment size for the release. Further increase in the size of the partition is not required as new customers are on-boarded. To set up the disk requirements, the disk should be set up on the VMWare GUI Resources tab where a disk can be created. This task should be done after the OVA import but prior to the boot of the system. 52

65 CHAPTER 7 Service Assurance Prerequisites, page 53 Prime Collaboration Assurance Workflow, page 54 Prime Collaboration Assurance Architecture Considerations, page 54 Prime Collaboration Assurance Management Considerations, page 54 Northbound Interface to OSS/BSS Considerations, page 55 Interface to Cisco HCM-F Considerations, page 55 Prime Collaboration Assurance for all Deployments, page 56 Prerequisites Before you plan the service assurance subsystem for your Cisco HCS installation, make sure that you: Review and have access to the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide Complete the actions outlined in previous sections of this guide including: Initial system requirements and planned growth Data center requirements Licensing Customer premise equipment Service fulfilment requirements 53

66 Prime Collaboration Assurance Workflow Service Assurance Prime Collaboration Assurance Workflow Prime Collaboration Assurance Architecture Considerations As you develop your plan for Prime Collaboration Assurance consider these key aspects : Required interfaces to the Cisco Hosted Collaboration Fulfilment system. Cisco Prime Collaboration Assurance NBI. Information on the Prime Collaboration Assurance northbound interfaces, and how to use them is available at: Service assurance management when using Cisco Prime Collaboration Assurance. Prime Collaboration Assurance Management Considerations Prime Collaboration Assurance helps you manage Cisco Hosted Collaboration Solution components. Features include: Support for Unified Communications components including Cisco Unified CM, Unity Connection, and Cisco IM and Presence End to end monitoring and real-time diagnostics Multi-customer support in Prime Collaboration voice and video assurance Customer summary dashboard for per customer summaries- devices and endpoints, alarms, video sessions with alarms, and voice calls with poor quality Voice and Video assurance - Telepresence Exchange dashboard shows the health of TelePresence Hosted Infrastructure; CTX cluster, SBC, MCU, IVR, Regions, and Resource Pools Full Contact Center View - dashboard and topology 54

67 Service Assurance Northbound Interface to OSS/BSS Considerations Northbound Interface to OSS/BSS Considerations The Northbound interface to OSS/BSS systems is a key aspect of service assurance as it provides an interface between Prime Collaboration Assurance and MSP systems such as trouble ticketing, and manager of managers (MoM). Its functions include delivering events to MSP systems regardless of the component or device manager from which the event originated. This includes: The ability to integrate with a MoM to proactively notify operators of issues and facilitates rapid resolution of problems. SNMP Traps integrate with existing MoM MoM integration for trouble ticketing In addition event correlation with alarms computed using: Time-based correlation Threshold-based correlation Root cause correlation Voice, Video, and Contact Center Correlation with Built-in rules for the most common use cases. Custom Correlation relation rules feature: The ability to configure correlation engine to generate events based on user defined criteria (for example selecting metrics and setting up violation rules based on an expected range of values). The ability to add event correlation rules on-demand. Interface to Cisco HCM-F Considerations When planning, the relationship between service assurance and service fulfilment is a key relationship to consider. Key functions of this relationship are: HCM-F through DMA-SA interacts with the Shared Data Repository (SDR) to a source of information about services, devices, and relationships used by Prime Collaboration Assurance. HCM-F interacts directly with Prime Collaboration Assurance to provide information from SDR about users. To monitor the Prime Collaboration Assurance device discovery process and to highlight any errors that take place during this discovery process. 55

68 Prime Collaboration Assurance for all Deployments Service Assurance Note Information about devices added directly through the Prime Collaboration Assurance GUI will not be propagated back through HCM-F to the SDR and as a result HCS will not be aware of these devices. Changes made in the Prime Collaboration Assurance GUI to an existing device may be overwritten by subsequent updates to the device from HCM-F. Basic IP phones (non-telepresence) are discovered and monitored directly by Prime Collaboration Assurance. TelePresence devices are configured in HCM-F and information about these devices is provided to Prime Collaboration Assurance through DMA-SA. For information on the interface to between Prime Collaboration Assurance and HCM-F see the Cisco Hosted Collaboration Mediation Fulfillment Planning Guide, Release 10.6(2). Prime Collaboration Assurance for all Deployments For all HCS deployments Cisco Prime Collaboration Assurance is a required component. Prime Collaboration Assurance is used in the Cisco Hosted Collaboration Solution (HCS) and interacts with the service assurance domain manager (DMA-SA) on the Hosted Collaboration Mediation Fulfillment (HCM-F) system to collect information about customers, clusters, and applications. Planning considerations: Prime Collaboration Assurance runs on any VMware-certified hardware with ESXi 4.1, 5.0, and 5.1 installed. Large and very large deployment models require ESXi 5.0 or later. One virtual machine is required to install Prime Collaboration Assurance. Northbound Interfaces are via Web Services API and SNMP gateway. For provisioning customers and devices are added through HCM-F. Cisco recommends that Prime Collaboration Assurance be installed in the management VLAN. Hyperthreading must be disabled in the server (BIOS level) for better performance of Prime Collaboration. This is to avoid CPU-related issues that may occur if hyperthreading is enabled. See your hardware documentation for information about disabling hyperthreading. vcpu speed is dependent on the UCS server or the virtualized hardware. We do not support oversubscribing server parameters (not using a 1:1 ratio of physical to virtual resources), such as, vcpu and memory. 56

69 Service Assurance Cisco Prime Collaboration Assurance NBI Note The OVA defines configuration of the virtual machine that includes the CPU, memory, disk, and network resources. We recommend that you install and run Prime Collaboration on Cisco Unified Computing System (UCS), which is VMware-certified. Prime Collaboration Assurance allows you to configure a second NIC (network adapter). To understand how to configure a second NIC, see prime_collaboration. Cisco Prime Collaboration Assurance NBI Cisco Prime Collaboration Assurance NBI support is available for the following: Managing devices Viewing and deleting device credentials. Listing all video sessions based on the filtering criteria. Troubleshooting video sessions. Get the endpoint count from the Unified CM cluster. Lists the alarms based on the filtering criteria. To access the NB API documentation, log in to the Cisco Prime Collaboration Assurance server with the administrator privilege and enter in the browser URL. The pc-server-ip is the Cisco Prime Collaboration Assurance server IP address. In addition to these NBIs, you can configure to send SNMP traps (CISCO-EPM-NOTIFICATION-MIB) to the trap receiver, whenever an alarm or event is raised. See the Configure Alarm and Event Notification section in the Cisco Prime Collaboration Assurance Guide - Standard for more information. NAT Planning Considerations In an HCS-LE deployment (single customer only), implementing a NAT between your management applications and Unified Communications applications is not required. Be aware that if a NAT is implemented in this scenario that the synthetic call feature will not be available. Provisioning Considerations When you are planning an HCS installation, provisioning is an important consideration. Determine if auto or manual provisioning will be used. Auto-provisioning of customers and services is available using HCM-F as opposed to manual provisioning. For Cisco Prime Collaboration Assurance to monitor Unified Communications applications and customer equipment devices, these devices must be configured with event destinations (SNMP trap, syslog, or RTMT 57

70 Estimate Prime Collaboration Assurance OVA Requirements Service Assurance API) to the Prime Collaborations Assurance server. The Cisco HCS Provisioning Adapter (CHPA) service automatically configures event destinations on the Cisco Unified Communications Manager. You must manually set up other applications and devices to forward events to the Prime Collaboration Assurance server. Estimate Prime Collaboration Assurance OVA Requirements For information on the OVA requirements for Prime Collaboration Assurance application, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Capacity Planning Guide at support/unified-communications/hosted-collaboration-solution-hcs/ products-implementation-design-guides-list.html. Estimate Prime Collaboration Assurance Scale Numbers For Prime Collaboration Assurance scale numbers see the Cisco Hosted Collaboration Solution, Release 10.6(1) Capacity Planning Guide at hosted-collaboration-solution-hcs/products-implementation-design-guides-list.html. Acquire Prime Collaboration Assurance Licenses As a part of service assurance planning, be sure to acquire the necessary Cisco Prime Collaboration Assurance license files. Prime Collaboration Assurance images are delivered using the Cisco electronic software delivery site and are delivered the same way as the Cisco Unified Communication Manager software. The licenses are also pulled from this site as a PAK to be registered to the PC server MAC. Licensing is ordered based on the endpoint type (Phone or Cisco TelePresence) and the quantity of those endpoints. The type of an endpoint determines which licenses you need, and the quantity of the endpoints determines the tier and number of licenses that you need to purchase to manage your network. Determine Required Bandwidth Bandwidth considerations are particularly relevant when considering a split data center with on-premise equipment. For more information on bandwidth considerations, see the Data center requirements chapter. Determine Necessary Ports/Protocols Requirements For details on ports and protocols see the System Security chapter in the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. For details on ports and protocols see Cisco Unified Border Element Naming Considerations When planning for service assurance, creating and following a standard naming convention can simplify troubleshooting in the future. For example, use a convention such as Customer name, Cluster ID, Interface ID. Using this convention a name would look like PSTN_CustA_CUCM1_1. 58

71 Service Assurance Cisco Unified Border Element Naming Considerations Following the naming convention and creating unique names allows for quick identification of the trouble spot and speeds fault diagnosis. 59

72 Cisco Unified Border Element Naming Considerations Service Assurance 60

73 CHAPTER 8 Customer Specific Dial Plan Prerequisites, page 61 Dial Plan Workflow, page 62 Determine Customer-Specific Dial Plan Requirements for Cisco Unified Communications Domain Manager 8.1(x), page 62 Determine Customer-Specific Dial Plan Requirements for Cisco Unified Communications Domain Manager 10.6(1), page 79 Prerequisites Note This section of the document starts the planning part that is repeated with each on-boarding. Before you plan the dial plan processes for your Cisco HCS installation, make sure that you: Review and have access to the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Complete the actions outlined in previous sections of this guide including: Initial system requirements and planned growth Data center requirements Licensing requirements Customer premise equipment requirements Service fulfillment requirements Service assurance requirements 61

74 Dial Plan Workflow Customer Specific Dial Plan Dial Plan Workflow Determine Customer-Specific Dial Plan Requirements for Cisco Unified Communications Domain Manager 8.1(x) For end customers, the dial plan is designed to handle a significant portion of the corporate dialing schemes. The Cisco HCS Dial Plan for Cisco Unified Communications Domain Manager 8.1(x) (Unified CDM) includes a standardized model on how to handle intrasite, intersite, and PSTN calls, generally using a site + extension methodology. It also spans advanced routing requirements of elements like central versus local breakout for PSTN calls and also handles the different numbering requirements across multiple countries. The intersection point between the dial plan and Unified CDM comes in the definition of standard telephony services that abstract Unified Communications Manager configurations into simpler choices that correspond to the feature plans a service provider wants to offer, and end customer wants to consume. For example, the partitions, calling search spaces, and translation patterns are predefined based on a choice of simple outbound, inbound, call forwarding, and time of day settings, which in Unified CDM are exposed as service types. These services are combined into feature packages and templates that define a user or line telephony services. Certain aspects of dial plan are decided on per customer basis while other parts are determined globally. Consider all of these factors when planning for dial plan as part of your deployment. See the latest version of the Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 8.1(x) Guide for more detailed information about dial plans. Procedure Step 1 For each customer, do the following: a) Determine Dial Plan Model for Cisco Unified Communications Domain Manager 8.1(x), on page 63 for each customer: Generic (G1) dial plan Flat (G2) dial plan Shared Instance (G3) dial plan b) Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 8.1(x), on page 65, if required. 62

75 Customer Specific Dial Plan Determine Dial Plan Model for Cisco Unified Communications Domain Manager 8.1(x) c) Determine Country-Specific Dial Plans for Cisco Unified Communications Domain Manager 8.1(x), on page 67, if required. d) Plan a New Country Dial Plan, on page 69, if required. e) Determine Customer Dialing Requirements for Cisco Unified Communications Domain Manager 8.1(x), on page 72. f) Plan Path Selection, on page 72. g) Determine Extension Addressing in Cisco Unified Communications Domain Manager 8.1(x), on page 72. h) Determine Emergency Calling, on page 74. i) Determine Inter-site Calling Customization Requirements for Cisco Unified Communications Domain Manager 8.1(x), on page 74. j) Determine Intrasite Calling Customization Requirements Cisco Unified Communications Domain Manager 8.1(x), on page 75. k) Determine Short Code Dialing for Cisco Unified Communications Domain Manager 8.1(x), on page 75. l) Determine Voice Mail Numbering for Cisco Unified Communications Domain Manager 8.1(x), on page 76. m) Determine Enhanced Number Translation Template Use in Cisco Unified Communications Domain Manager 8.1(x), on page 76. Step 2 Define the following at the global level: a) Determine Time of Day Routing for Cisco Unified Communications Domain Manager 8.1(x), on page 78. b) Determine Class of Service and Restrictions for Cisco Unified Communications Domain Manager 8.1(x), on page 78. Determine Dial Plan Model for Cisco Unified Communications Domain Manager 8.1(x) Depending on the dial plan model that you select, the Cisco HCS dial plan creates directory numbers (Cisco Unified Communications Manager Internal DNs) consisting of a Site Location Code (SLC) + extension number, or just the extension number on Cisco Unified Communications Manager clusters. You can configure the SLC with or without an intersite prefix (ISP). Procedure Review the key differences outlined in the following table to determine which dial plan model to use based on the dial plan characteristics you require. If you require multiple dial plan support, you must create individual service providers for each dial plan. Refer to Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 8.1(x), on page 65 for more information. 63

76 Determine Dial Plan Model for Cisco Unified Communications Domain Manager 8.1(x) Customer Specific Dial Plan Table 8: Key Differences in Cisco Unified Communications Domain Manager 8.1(x) G1 and G2 Dial Plan Models Dial Plan model Generic (G1) Flat (G2) Description The G1 dial plan allows you to customize your dial plan. All directory numbers, voice mail pilots, and mailbox numbers follow the SLC plus extension format. Flat dialing consists of extension dialing of up to 11 digits across all locations. The dial plan supports unique directory number assignment across locations. All directory numbers, voice mail pilots and mailbox numbers follow the extension format when they are provisioned from the Cisco Unified Communications Manager. Key differences A standalone ISP is not supported, but rather, the ISP is implemented as the first digit of the SLC (for example, 8). For sample G1 numbering, refer to Determine Extension Addressing in Cisco Unified Communications Domain Manager 8.1(x), on page 72. The SLC is removed from the Cisco Unified Communications Manager internal number format. For sample G2 numbering, refer to Determine Extension Addressing in Cisco Unified Communications Domain Manager 8.1(x), on page 72. No short code dialing within a site (location). Need to group subscribers for emergency dialing and administrative purposes. No need for intersite prefix (ISP) across locations. For a flat dial plan, the extensions and the internal DNs are the same. Extensions under flat dial plan cannot overlap and must be unique across all locations for a customer. 64

77 Customer Specific Dial Plan Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 8.1(x) Table 9: Shared Instance Key Differences in Dial Plan Models Dial Plan model Shared Instance Dial Plan (G3) Description Used for the market. In small medium business deployments, multiple customers are deployed on one instance of Cisco Unified Communications Manager Virtual Machine. Key differences Available from 9.2(1) SU1 onwards. Based on G2 plan which is modified to support customer-specific dialing and routing. IMS ISC trunk is not available. Forced on-net feature is not available. For sample G3 numbering, refer to Determine Extension Addressing in Cisco Unified Communications Domain Manager 8.1(x), on page 72. Useful for Shared Instance application model, where multiple customers are served by one application cluster. For more information on the Shared Instance feature, see Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 8.1(x) The Cisco Unified Communications Domain Manager supports one Cisco HCS dial plan model per service provider, but you can configure it to support multiple service providers (SPs) by creating multiple logical SP domains. The multiple service provider configuration can support two or more dial plans. If you require several dial plans, use the multiple service provider configuration described in this section. The following figure shows a logical representation of multiple service providers. Customers 1, 2, and 3, and any future customers added under SP1 use the G1 generic dial plan (SLC+Extension) configuration. Customers 65

78 Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 8.1(x) Customer Specific Dial Plan 4, 5, and 6 and any future customers added under SP2 use the G2 or Shared Instance flat dial plan (Extension only) configuration. Figure 2: Multiple Service Provider Support Considerations When Deploying Multiple Service Providers Role-based access control (RBAC) stays within a service provider domain. Cisco Unified Communications Domain Manager maintains different hierarchy levels at which configuration objects are managed. As a service provider you can plan for the following hierarchy levels as required: Provider Reseller Customer Division Location Building 66

79 Customer Specific Dial Plan Determine Country-Specific Dial Plans for Cisco Unified Communications Domain Manager 8.1(x) User (end user) Figure 3: Hierarchy levels Use these guidelines to plan the hierarchy levels: The internal system super user maintains visibility and control of all service provider hierarchical domains for the entire system. Each service provider domain can have administrators at the different provider, reseller, customer, and location levels but are constrained to their parent service provider. For example, service provider Admin1 in service provider 1 cannot manage or provision elements for service provider 2 and vice versa. Determine Country-Specific Dial Plans for Cisco Unified Communications Domain Manager 8.1(x) In Cisco HCS, a country dial plan consists of translation and route patterns to handle the following: All local, long distance, and international calls Emergency calls Service calls Special calls such as Freephone, Premium, Mobile Call blocking based on class of service Call routing through local gateway and or central breakout At the provider level, you need to determine the countries to be supported. By default, the base data and country dial plan model file package contains the dial plan model files for North America and Great Britain. If you are a service provider with a customer in another country, you must also plan to use country-specific dial plan model files. 67

80 Determine Country-Specific Dial Plans for Cisco Unified Communications Domain Manager 8.1(x) Customer Specific Dial Plan If you are multi-country provider who requires multiple country dial plans, you need to determine the additional country dial plans required. If a country-specific dial plan model file does not exist for the country, you can download the dial plan model file for a country that has a similar dial plan, and then customize it, or you can contact your Cisco representative to have a new country dial plan created. Table 10: Country Dial Plans Available for Cisco Unified Communications Domain Manager 8.1(x) Argentina (ARG) Australia (AUS) Austria (AUT) Belgium (BEL) Brazil (BRA) China (CHN) Czech Republic (CZE) Denmark (DNK) Finland (FIN) France (FRA) Germany (DEU) Great Britain (GBR) Hong Kong (HKG) India (IND) Indonesia (IDN) Italy (ITA) Japan (JPN) Mexico (MEX) Netherlands (NLD) Norway (NOR) Poland (POL) Portugal (PRT) Russia (RUS) Singapore (SGP) Spain (ESP) Sweden (SWE) Switzerland (CHE) Thailand (THA) Turkey (TUR) United States (USA) Ireland (IRL) Israel (ISR) Ireland (IRL) If a new country dial plan is required, contact your Cisco representative for assistance. Provide the information that is outlined in Plan a New Country Dial Plan, on page 69 to your Cisco representative. Additional country-specific Dial Plan templates are released to Cisco partners as they become available. 68

81 Customer Specific Dial Plan Plan a New Country Dial Plan Note The available country dial plans adhere to the specific country dial plan rules and Cisco HCS model best practices. However, it is a partner's responsibility to validate and fully test these country modules in the specific country prior to any commercial launch. Plan a New Country Dial Plan You can build your own country dial plan instead of using one of the country dial plan templates. Note Do not modify the default models; contact Cisco for assistance. If you need to create a new customized country dial plan, determine the information about your plan using this procedure. Contact your Cisco representative and provide the following information. Procedure Step 1 Gather basic contact information: Company name and ID Primary contact name, telephone number and address Step 2 Gather basic country dial plan information: ISO 3166 Alpha-3 country code. This is a 3-digit code. Example: Australia = AUS. Refer to countrycodes.org/. ISO Numerical country code, for example Belize = 84. Refer to Dialing plan type: OPEN Uses different dialing arrangement for local and long distance telephone calls. CLOSED The subscriber's full number is used for all calls, even in the same area. Step 3 Step 4 Step 5 Determine the user locale for the country. flowid=33682&softwareid= &release=9.0% %29& relind=available&rellifecycle=&reltype=all Determine the network locale for the country. These are the tones and cadence for a particular country. Default is English, United States. Network locale is identified in the Cisco Unified Communications Manager. Determine the PSTN access number used in the country. The PSTN prefix is defined on a country basis. It is specified for each service provider for each country and applies to all customer locations in a country. When the caller dials a PSTN number with a PSTN access prefix (typically a 9 in the United Kingdom and United States), this tells the dial plan that the caller is making an 69

82 Plan a New Country Dial Plan Customer Specific Dial Plan Step 6 Step 7 Step 8 off-net call. When the caller dials the PSTN breakout number, the dial plan routes the call to the correct PSTN breakout location, whether it is a central or a local PSTN gateway. Determine National Dialing prefix (NDD) used in the country. The NDD prefix is the access code used to place a call within that country from one city to another (when calling another city in the same vicinity, this may not be necessary). Refer to telephone_codes/international_dialcode.html. Determine International Dialing prefix (International Direct Dialing) used in the country. An international call prefix is the part of a telephone number used to dial out of a country when making an international call. It is synonymous with international access code or exit code. Refer to wiki/list_of_international_call_prefixes. Determine which of the following call types will be used for local breakout (LBO): International Dialing Dialing to another country National Dialing Dialing within the country Subscriber Dialing Local dialing Emergency Dialing Dialing to emergency services such as police, fire, ambulance Freephone/Toll free Dialing/Special Services Any customers can dial the same number to reach a business subscribing to a number with no charge to the calling party. For example, 800 or 866 toll-free dialing in Canada and the United States, or Freephone service in most other countries. Mobile Dialing In many countries, mobile phones are assigned dedicated mobile phone codes within the country's telephone numbering plan. Some countries that do not use area codes allocate specific number ranges to mobile phones that are easily distinguishable from landlines. One exception is the North American Numbering Plan which assigns subscriber numbers to mobile phones within geographic area codes, and are not easily distinguishable from landlines. Personal Communications Service (PCS) networking Several types of wireless voice and wireless data communications systems, typically incorporating digital technology, providing services similar to advanced cellular mobile or paging services. PCS can also be used to provide other wireless communications services, including services that allow people to place and receive communications while away from their home or office, as well as wireless communications to homes, office buildings and other fixed locations. Premium Rate Dialing (blocked) Telephone numbers for telephone calls during which certain services are provided that create additional charges to the caller's bill. Blocking services are offered to allow telephone customers to prevent access to these number ranges from their telephones. Service Calls Number assignments that are typically distributed to public safety professionals in order to resolve, correct or assist in a particular situation. This may be emergency services, or information or assistance services such as Operator assistance. Step 9 For each of the selected Call Types, determine which of the following prefixes you require (as many as apply): Carrier Access Code (CAC) Gives telephone users the possibility of opting for a different carrier on a call-by-call basis - sometimes called calls. Calling Line Identification Presentation (CLIP) Transmits a caller's number to the called party's telephone equipment during the ringing signal or when the call is being set up but before the call is answered. 70

83 Customer Specific Dial Plan Plan a New Country Dial Plan Step 10 Step 11 Step 12 Step 13 Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20 Step 21 Step 22 Step 23 Calling Line Identification Restriction (CLIR) Enables restriction of the per-line calling line identification presentation setting. Combination CAC and CLIR. Combination CAC and CLIP. For each pattern, determine if you want AllDay hours or StandardHours in this partition. The generic Cisco HCS model supports two time periods: AllDay (Monday - Sunday: 00:00 to 24:00) or StandardHours (Monday - Friday: 07:00 to 18:00). For each pattern, determine if you want blocking in this partition. Determine Carrier Access Code (CAC) if applicable. Gives telephone users the possibility of opting for a different carrier on a call-by-call basis. These consist of the digits 101 followed by the four-digit CIC. The CAC is dialed as a prefix immediately before dialing a long-distance phone number. Determine subscriber (local dialing) dial plan patterns. Determine service codes dial plan pattern, if applicable. Determine Freephone /Toll Free dial plan patterns, if applicable. Determine Premium Dialing dial plan patterns, if applicable. Determine Mobile Dialing dial plan patterns, if applicable. Determine Carrier Select dial plan patterns, if applicable. Determine Special Rate dial plan patterns, if applicable. Determine Personal Communications Service (PCS) Number dial plan patterns, if applicable. Determine if you require Calling Line Identification Presentation (CLIP) If applicable. Transmits a caller's number to the called party's telephone equipment during the ringing signal or when the call is being set up but before the call is answered. Determine your Primary Emergency Number. Different countries around the world have a single emergency number that is used throughout the entire country; for example, 911 in the USA, 999 in the UK, and 000 in Australia. If your country has several emergency numbers, you need to know the most important emergency number. Determine the three highest priority emergency numbers. Step 24 Determine the rest of the emergency numbers required (as many as apply to a maximum of 12). Step 25 Step 26 Determine whether each pattern is needed for Survivable Remote Site Telephony (SRST). Determine if you plan to enforce E.164 rules for a new country dial plan. If yes, determine the following: Minimum area code length Maximum area code length Minimum local number length Maximum local number length Step 27 Step 28 Step 29 Step 30 Determine if you want outgoing prefix digits converted to E.164. Determine if you want Cisco to manage routing transformation for the called number. Note If you want customized routing, you will need to contact Cisco Advanced Services. Determine if you want Cisco to generate a Plus Dialing National pattern. Determine if you want Cisco to generate a Plus Dialing International pattern. 71

84 Determine Customer Dialing Requirements for Cisco Unified Communications Domain Manager 8.1(x) Customer Specific Dial Plan Determine Customer Dialing Requirements for Cisco Unified Communications Domain Manager 8.1(x) 1 If you selected Generic (G1) Dial Plan model (in Determine Dial Plan Model for Cisco Unified Communications Domain Manager 8.1(x), on page 63), determine Site Location Code (SLC) for the customer. 2 Determine if intersite prefix (ISP) is used (Optional) and the ISP number for the customer. This information will be required during customer onboarding. The ISP is a single digit number in the range 0 to 9 and must be unique within the customer's network. The ISP is deployment-configurable to any value, but must not overlap with the PSTN dialing prefix or emergency number. The ISP is an optional configurable value within a customer's dial plan. Note Customer-wide means that the same ISP must be used for all of a customer's sites. If the first site that is provisioned begins with the digit 8, then all other sites should also begin with the digit 8. Under one service provider, you can have the ISP as 7 for one customer and 8 for another customer. Plan Path Selection Procedure Step 1 Step 2 Determine if you will use a local gateway on a site basis or use centralized breakout (CBO) through aggregation. Once at aggregation, the call is routed by the service provider. If a local gateway is added, then determine the call types that will be used to route calls through local breakout (LBO) at each site. The remaining call types are routed by CBO (aggregation). For more information on the call types, refer to Plan a New Country Dial Plan, on page 69. Determine Extension Addressing in Cisco Unified Communications Domain Manager 8.1(x) When planning to add a site, determine extension addressing to specify how many digits are used to identify extensions. Extension number ranges chosen should not overlap with the intersite prefix (for the G1 dial plan) or with the PSTN access number. To prevent overlap, do not use extension number ranges starting with a PSTN access prefix such as 9, or the chosen intersite prefix, commonly 8. Overlap between extension numbers and the emergency number at any location must be avoided. Refer to the following table for an example directory number format for the Generic (G1) dial plan. Note that a standalone ISP is not supported, but instead, you would implement the ISP as the first digit of the Site 72

85 Customer Specific Dial Plan Determine Extension Addressing in Cisco Unified Communications Domain Manager 8.1(x) Location Code (SLC) (shown as 8 in the table). You can also have various digits as the first digits of the SLC; an ISP does not have to be used. Table 11: Generic (G1) Dial Plan example directory number format Customer SLC Extension Cisco Unified Communications Manager Configured DN range Customer 1 Location Location Customer 2 Location Location Refer to the following table for an example directory number format for the Flat (G2) dial plan. Note that the number range is not site-specific. Extension numbers can be comingled; some of the numbers from Location 1 can be assigned to Location 2 and vice versa. Table 12: Flat (G2) Dial Plan example directory number format Customer Customer 1 Location 1 Location 2 Customer 2 Location 1 Location 2 Extension Example of a DN configured on Cisco Unified Communications Manager Refer to the following table for an example directory number format for the Shared Instance dial plan. Note that you can overlap the extension range across locations, but the same extension cannot be assigned at another location. If the same extension is used across locations, you will need to provision it as a shared line in Cisco Unified Communications Manager. 73

86 Determine Emergency Calling Customer Specific Dial Plan Note Short code dialing from voice mail is not supported. Table 13: Shared Instance Dial Plan Example Directory Number Format Customer Customer 1 Location 1 Location 2 Customer 2 Location 1 Location 2 Extension , , , , Example of a DN configured on Cisco Unified Communications Manager , , , 2050, 2055, , , Determine Emergency Calling Determine how emergency calling will be handled. The available options are: local PSTN handoff central PSTN handoff Cisco Emergency Responder (CER) For more information on CER, see the latest version of Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Determine Inter-site Calling Customization Requirements for Cisco Unified Communications Domain Manager 8.1(x) You can customize these intersite dialing requirements: If an Intersite Prefix (ISP) is required and it is included in the Site Location Code (SLC), then directory numbers will include the ISP. If an ISP is not required for intersite dialing, then the directory numbers do not include ISPs. If an ISP is required, but it is not included in the SLC, then directory numbers do not include ISPs. Determine your intersite calling customization requirements. Intersite requirements are set using Enhanced Number Translation templates in Cisco Unified Communications Domain Manager 8.1(x). For more 74

87 Customer Specific Dial Plan Determine Intrasite Calling Customization Requirements Cisco Unified Communications Domain Manager 8.1(x) information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 8.1(x). In Cisco Unified Communications Domain Manager 10.6(1), intersite calling customization requirements are specified by the administrator when creating a customer dial plan. For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 10.6(x). Determine Intrasite Calling Customization Requirements Cisco Unified Communications Domain Manager 8.1(x) You can create translation patterns for extension dialing with or without an extension prefix. Extension Prefix is used if the first digit of an extension conflicts with PSTN prefix or any other dialing. For example, if extension range 9xxx conflicts with PSTN prefix 9. In order to avoid conflict, another digit is prefixed to the extension. Extension prefix is not included in the DN. Determine your intrasite calling customization requirements. Intrasite requirements are set using Enhanced Number Translation templates in Cisco Unified Communications Domain Manager 8.1(x). For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 8.1(x). In Cisco Unified Communications Domain Manager 10.6(1), intrasite calling customization requirements are specified by the administrator when creating a customer dial plan. For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 10.6(x). Determine Short Code Dialing for Cisco Unified Communications Domain Manager 8.1(x) Short code dialing (internal group speed calling) is used at a customer site for commonly used services such as help, operator, and maintenance. You might want to set up short code dialing to reach commonly used services quickly. For more information on short code dialing, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 8.1(x). Note Only intracompany short code dialing is available. Determine your short code dialing plan. Short code dialing requirements are set using Enhanced Number Translation templates in Cisco Unified Communications Domain Manager 8.1(x). For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 8.1(x). In Cisco Unified Communications Domain Manager 10.6(1), short code dialing customization requirements are specified by the administrator when creating a customer. For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 10.6(x). 75

88 Determine Voice Mail Numbering for Cisco Unified Communications Domain Manager 8.1(x) Customer Specific Dial Plan Determine Voice Mail Numbering for Cisco Unified Communications Domain Manager 8.1(x) Determine the voice mail numbering scheme for forwarding calls to voice mail and accessing voice mail messages from the PSTN. For each Cisco Unified IP Phone line that exists on the leaf cluster that requires voic , there is also a voice mailbox definition on the Cisco Unity Connection. On Cisco Unity Connection, the voice mailbox definition is associated to the telephony integration/leaf cluster that contains the line definition. The leaf clusters have a voic Pilot Number defined that helps to route calls to the Cisco Unity Connection. With this scenario, each leaf cluster can use the same number for the voic pilot number. Determine if you require a short code (internal speed call number) for voice mail access. Short code dialing requirements are set using Enhanced Number Translation templates in Cisco Unified Communications Domain Manager 8.1(x). For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 8.1(x). Determine Enhanced Number Translation Template Use in Cisco Unified Communications Domain Manager 8.1(x) Enhanced Number Translation (ENT) templates allow you to customize translation and route patterns on a customer basis, or on a customer location basis when using the Cisco Unified Communications Domain Manager 8.1(x). You can create additional templates based on customer needs. Contact your Cisco representative for support. Refer to the Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 8.1(x) for details on how to customize and use the templates. Refer to the following table to determine which of the templates you require for a customer or customer location. Template name Intrasite G1 Template Intersite G1 Template Intrasite ExtPfx Template Allow Call Template Description Sets up extension dialing (no extension prefix). This is the current capability provided by the standardized G1 model. Sets up Intersite dialing when ISP is included in the SLC. This is the current capability provided by the standardized G1 model. You can also use this template for customers that do not require ISP for intersite calls. Creates translation patterns for extension dialing that requires an extension prefix. This is a variation of extension dialing translation patterns. Creates translation patterns to allow calls to certain numbers (per customer) even when a particular call type is blocked. For example, if a user is blocked from making national (long distance) calls, this template allows calls to certain destinations. Used by which dial plans? G1 G1 G1 All 76

89 Customer Specific Dial Plan Determine Enhanced Number Translation Template Use in Cisco Unified Communications Domain Manager 8.1(x) Template name Block Call Template Short Call (SC) Template Voice Mail (VM) Dialing Template ICT RP Template TEHO RP Template IMS VM RP Template Local Calling Template Description Creates blacklist or blocking translation patterns (per customer or location as required). This is similar to the Allow Call Template; however, this template is used to block calls to certain destinations. Creates short codes (group speed calling internal only) to commonly used services such as help, operator, and maintenance. Creates a short code for voice mail access. Creates intercluster route patterns for a multicluster customer. In the G2 flat dial plan or G3 plan, the intercluster route patterns are not created by the standardized model. Creates per-country route patterns used in Tail End Hop Off (TEHO) environments. TEHO allows you to yield significant savings by routing a call across the Cisco global WAN to the gateway at the local site, then the call 'hops off' to the PSTN and completes as a local call. Use this template to identify the specific voice mail route pattern to allow internal voice mail access for IMS-Integrated Mobile clients. Several countries have variable length local dialing. For example, in India and Mexico, the length of area code plus the local number is fixed at 10, but they have variable length area codes from two to four digits. If the length of the area code is two digits, then the length of the local number is eight digits. If the length of the area code is three digits, then the length of the local number is seven digits. And if the length of the area code is four digits, then the length of the local number is six digits. You can use the local template to customize translation patterns for each location. Used by which dial plans? All All All G2, G3 All G1, G3 Note All This particular template is not available to Shared Instance (G3) dial plan subscribers. Enhanced Number Translation templates are not used in. To customize translation patterns and route patterns on a customer basis, you can create custom schemas or use one of the default schemas predefined in Cisco Unified Communications Domain Manager 10.6(1). For more information on custom schemas, refer to Cisco 77

90 Determine Time of Day Routing for Cisco Unified Communications Domain Manager 8.1(x) Customer Specific Dial Plan Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 10.6(x) Determine Time of Day Routing for Cisco Unified Communications Domain Manager 8.1(x) The Dial Plan Model in Cisco Unified Communications Domain Manager 8.1(x) supports two time periods and schedules. Choices are as follows: AllDay (Monday - Sunday: 00:00 to 24:00) StandardHours (Monday - Friday: 07:00 to 18:00) Select one or the other depending on when most calls are made. Time of Day is defined at a global level. For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 8.1(x). Determine Class of Service and Restrictions for Cisco Unified Communications Domain Manager 8.1(x) Cisco Unified Communications Domain Manager 8.1(x) uses class of service to assign calling restrictions to an end user. The class of service is mapped by the dial plan model to a calling search space and partitions that are understood by Cisco Unified Communications Manager. For Cisco Unified Communications Domain Manager 8.1(x) customers, the classes of service map to partitions, calling service spaces, and time periods and are defined in an Excel worksheet. Plan the class of service types that are required for your users: Temporary Out of Service Class of Service Only allows emergency dialing International 24 hours Enhanced No Restrictions International 24 hours Standard Premium Rate and Personal Communication Service (PCS) calls are blocked International Working Hours Enhanced No restrictions during standard working hours International Working Hours Standard where Premium Rate calls and PCS calls are blocked during standard working hours National 24 hours Enhanced where International calls are blocked National 24 hours Standard where Premium Rate, PCS, and International calls are blocked National 24 hours Restricted when Premium Rate, PCS, International, and Mobile calls are blocked National Working hours Enhanced where International calls are blocked during standard working hours National Working hours Standard where Premium Rate, PCS, and International calls are blocked during standard hours National Working hours Restricted when Premium Rate, PCS, International, and Mobile calls are blocked during standard working hours 78

91 Customer Specific Dial Plan Determine Customer-Specific Dial Plan Requirements for Cisco Unified Communications Domain Manager 10.6(1) Local 24 hours Enhanced where the Premium Rate, PCS, International, Mobile, and National calls are blocked Internal only where only on-net calls are allowed Internal Calls with CLIR where only on-net calls with Calling Line Identification Restriction are allowed For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 8.1(x). Determine Customer-Specific Dial Plan Requirements for Cisco Unified Communications Domain Manager 10.6(1) The Dial Plan Model is completely redesigned for Cisco Unified Communications Domain Manager 10.6(1) to leverage templates and workflows using json files to implement the model. The new model is flexible and is designed to simplify dial plan management wherever possible. The Dial Plan Model in Cisco Unified Communications Domain Manager 10.6(1) consists of four basic, predefined call types: Directory Number = Site Location Code (SLC) + Extension, no Inter Site Prefix (ISP) in SLC Directory Number = SLC + Extension with ISP as part of SLC Directory Number = SLC + Extension and without ISP, can be with or without Extension Dialing Prefix (EDP) Directory Number = Flat Dial Plan (no SLC) These four dial model types encompass all the functionality that was available on the previous Dial Plan Model, but in order to offer flexibility for partners, the four types can be extended to develop custom schemas. Customization is managed through discrete, selectable elements in Cisco Unified Communications Domain Manager 10.6(1). The Dial Plan Model provides flexible features such as Dynamic Class of Service (COS) Country Dial Plans Blocked / Non-blocked numbers Call manager groups Flexible routing Per-site PSTN prefix In Cisco Unified Communications Domain Manager 10.6(1), the administrator is asked at either the customer or site level to fill in a template which determines the Dial Plan model that is delivered to the Cisco Unified Communications Manager and sites. For more information, see the sections listed here, or refer to Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 10.6(x). 79

92 Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 10.6(1) Customer Specific Dial Plan Procedure Step 1 Step 2 For each customer, do the following: a) Determine which type(s) of dial plans (Type 1 to Type 4) you require. b) Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 10.6(1), on page 80, if required. c) Determine Country-Specific Dial Plans for Cisco Unified Communications Domain Manager 10.6(1), on page 82, if required. d) Plan a New Country Dial Plan, on page 69, if required. e) Determine Customer Dialing Requirements for Cisco Unified Communications Domain Manager 10.6(1), on page 83. f) Plan Path Selection, on page 72. g) Determine Extension Addressing for Cisco Unified Communications Domain Manager 10.6(1), on page 84. h) Determine Emergency Calling, on page 74. i) Determine Inter-site Calling Customization Requirements for Cisco Unified Communications Domain Manager 8.1(x), on page 74. j) Determine Intrasite Calling Customization Requirements Cisco Unified Communications Domain Manager 8.1(x), on page 75. k) Determine Short Code Dialing for Cisco Unified Communications Domain Manager 8.1(x), on page 75. l) Determine Voice Mail Numbering in Cisco Unified Communications Domain Manager 10.6(1), on page 85. Define the following: This step is performed at the customer level in Cisco Unified Communications Domain Manager 10.6(1). a) Determine Time of Day Routing in Cisco Unified Communications Domain Manager 10.6(1), on page 86. b) Determine Class of Service and Restrictions in Cisco Unified Communications Domain Manager 10.6(1), on page 86. Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 10.6(1) There is no support for multiple service providers in. Cisco Unified Communications Domain Manager 10.6(1) Role-Based Access Control (RBAC) Partners deploying Cisco HCS require the ability to be able to restrict certain management actions to a specific set of users. The following roles are predefined for use in Cisco HCS: 80

93 Customer Specific Dial Plan Plan Multiple Service Provider Support for Cisco Unified Communications Domain Manager 10.6(1) Role FF SA Read Permission Update Permission Partner Admin Y Y Y Y Partner Operator Y Y Y N Partner FF Admin Y N Y Y Partner FF Operator Y N Y N Partner SA Admin N Y Y Y Partner SA Operator N Y Y N Partner Admin Y Y Y Y Partner Operator Y Y Y N Partner FF Admin Y N Y Y Partner FF Operator Y N Y N Partner SA Admin N Y Y Y Partner SA Operator N Y Y N Partner Admin Y Y Y Y Partner Operator Y Y Y N Partner FF Admin Y N Y Y Partner FF Operator Y N Y N Partner SA Admin N Y Y Y Partner SA Operator N Y Y N 81

94 Determine Country-Specific Dial Plans for Cisco Unified Communications Domain Manager 10.6(1) Customer Specific Dial Plan Figure 4: Role-Based Access Control Hierarchy In the preceding figure, note that administrators of each level have access to the information in all hierarchy levels below them. See the Cisco Hosted Collaboration Solution, Release 10.6(1) Customer Onboarding Guide for more information. Determine Country-Specific Dial Plans for Cisco Unified Communications Domain Manager 10.6(1) In Cisco Unified Communications Domain Manager 10.6(1), a country dial plan consists of translation and route patterns to handle the following: All local, long distance, and international calls Emergency calls Call blocking based on class of service Call routing through local gateway and or central breakout 82

95 Customer Specific Dial Plan Determine Customer Dialing Requirements for Cisco Unified Communications Domain Manager 10.6(1) At the provider level, you need to determine the countries to be supported. By default, the base data and country dial plan model file package contains the dial plan model files for North America and Great Britain. If you are a service provider with a customer in another country, you must also plan to use country-specific dial plan model files. If you are multi-country provider who requires multiple country dial plans, you need to determine the additional country dial plans required. If a country-specific dial plan model file does not exist for the country, you can download the dial plan model file for a country that has a similar dial plan, and then customize it, or you can contact your Cisco representative to have a new country dial plan created. Table 14: Country Dial Plans Available for Cisco Unified Communications Domain Manager 10.6(1) Great Britain (GBR) United States (USA) If a new country dial plan is required, contact your Cisco representative for assistance. Provide the information that is outlined in Plan a New Country Dial Plan, on page 69 to your Cisco representative. Note The available country dial plans adhere to the specific country dial plan rules and Cisco HCS model best practices. However, it is a partner's responsibility to validate and fully test these country modules in the specific country prior to any commercial launch. Determine Customer Dialing Requirements for Cisco Unified Communications Domain Manager 10.6(1) 1 If you selected Type 1 to Type 3 Dial Plan model (in Determine Dial Plan Model for Cisco Unified Communications Domain Manager 8.1(x), on page 63), determine Site Location Code (SLC) for the customer. 2 For Type 1 Dial Plan, determine if intersite prefix (ISP) is used (Optional) and the ISP number for the customer. For Type 2, determine the ISP number for the customer. This information will be required during customer onboarding. The ISP is a single digit number in the range 0 to 9 and must be unique within the customer's network. The ISP is deployment-configurable to any value, but must not overlap with the PSTN dialing prefix or emergency number. The ISP is an optional configurable value within a customer's dial plan. Note Customer-wide means that the same ISP must be used for all of a customer's sites. If the first site that is provisioned begins with the digit 8, then all other sites should also begin with the digit 8. Under one service provider, you can have the ISP as 7 for one customer and 8 for another customer. 83

96 Determine Extension Addressing for Cisco Unified Communications Domain Manager 10.6(1) Customer Specific Dial Plan Determine Extension Addressing for Cisco Unified Communications Domain Manager 10.6(1) When planning to add a site, determine extension addressing to specify how many digits are used to identify extensions. Extension number ranges chosen should not overlap with the intersite prefix or with the PSTN access number. To prevent overlap, do not use extension number ranges starting with a PSTN access prefix such as 9, or the chosen intersite prefix, commonly 8. Overlap between extension numbers and the emergency number at any location must be avoided. Refer to the following table for an example directory number format for the Type 1 to 3 dial plans. Note that a standalone ISP is not supported, but instead, you would implement the ISP as the first digit of the Site Location Code (SLC) (shown as 8 in the table). You can also have various digits as the first digits of the SLC; an ISP does not have to be used. Table 15: Type 1 to Type 3 Dial Plan example directory number format Customer SLC Extension Cisco Unified Communications Manager Configured DN range Customer 1 Location Location Customer 2 Location Location Refer to the following table for an example directory number format for the Type 4 dial plan. Note that the number range is not site-specific. Extension numbers can be comingled; some of the numbers from Location 1 can be assigned to Location 2 and vice versa. Table 16: Type 4 Dial Plan example directory number format Customer Customer 1 Location 1 Extension Example of a DN configured on Cisco Unified Communications Manager

97 Customer Specific Dial Plan Determine Voice Mail Numbering in Cisco Unified Communications Domain Manager 10.6(1) Customer Location 2 Customer 2 Location 1 Location 2 Extension Example of a DN configured on Cisco Unified Communications Manager Refer to the following table for an example directory number format in a Shared Instance dial plan deployment, using the Type 4 dial plan. Note that you can overlap the extension range across locations, but the same extension cannot be assigned at another location. If the same extension is used across locations, you will need to provision it as a shared line in Cisco Unified Communications Manager. Note Short code dialing from voice mail is not supported. Table 17: Shared Instance Deployment (Type 4) Dial Plan Example Directory Number Format Customer Customer 1 Location 1 Location 2 Customer 2 Location 1 Location 2 Extension , , , , Example of a DN configured on Cisco Unified Communications Manager , , , 2050, 2055, , , Determine Voice Mail Numbering in Cisco Unified Communications Domain Manager 10.6(1) Determine the voice mail numbering scheme for forwarding calls to voice mail and accessing voice mail messages from the PSTN. For each Cisco Unified IP Phone line that exists on the leaf cluster that requires voic , there is also a voice mailbox definition on the Cisco Unity Connection. On Cisco Unity Connection, the voice mailbox definition is associated to the telephony integration/leaf cluster that contains the line 85

98 Determine Time of Day Routing in Cisco Unified Communications Domain Manager 10.6(1) Customer Specific Dial Plan definition. The leaf clusters have a voic Pilot Number defined that helps to route calls to the Cisco Unity Connection. With this scenario, each leaf cluster can use the same number for the voic pilot number. Determine if you require a short code (internal speed call number) for voice mail access. For Cisco Unified Communications Domain Manager 10.6(1), short code dialing customization requirements are specified by the administrator at the customer level. For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 10.6(x). Determine Time of Day Routing in Cisco Unified Communications Domain Manager 10.6(1) The Dial Plan Model in Cisco Unified Communications Domain Manager 10.6(1) is completely customizable at the customer level. Each custom time schedule appears on the Cisco Unified Communications Manager Admin Time Schedule as a customer ID-name given to the schedule (for example CU7-workdayschedule). For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 10.6(x). Determine Class of Service and Restrictions in Cisco Unified Communications Domain Manager 10.6(1) Cisco Unified Communications Domain Manager uses class of service to assign calling restrictions to an end user. The class of service is mapped by the dial plan model to a calling search space and partitions that are understood by Cisco Unified Communications Manager. For Cisco Unified Communications Domain Manager 10.6(1) customers, Classes of Service are defined at the customer level and can be used site-to-site. Call Types and Route Options (Allowed, Blocked) are defined for the Class of Service. When Class of Service is specified for a particular site (must have been previously defined in "Add a Class of Service" and "Define Call Types" at the site level, this sends partitions, translation patterns and calling search spaces to the Cisco Unified Communications Domain Manager. For more information, see Cisco Hosted Collaboration Solution, Release 10.6(1) Dial Plan Management Guide for Cisco Unified Communications Domain Manager, Release 10.6(x). 86

99 CHAPTER 9 Unified Communications Application Planning Prerequisites, page 87 UC Applications Workflow, page 88 Determine UC Applications Requirements, page 88 Prerequisites Before you plan the UC applications processes for your Cisco HCS installation, make sure that you: Review and have access to the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Have completed the actions outlined in previous sections of this guide including: Initial system requirements and planned growth Data center requirements Licensing Customer premise equipment Service fulfillment Service assurance Customer-specific dial plan 87

100 UC Applications Workflow Unified Communications Application Planning UC Applications Workflow Determine UC Applications Requirements Procedure Step 1 Step 2 Step 3 Step 4 Identify customer size. This size relies on the choice of deployment model. For instance, if your deployment model includes Shared Instance, this affects how you deploy your Cisco Unified Communications Manager. For instance, if you anticipate a low usage for voic , for example, consider partitioning Cisco Unity Connection while keeping Cisco Unified Communications Manager and Cisco Unified Communications Manager IM and Presence Service dedicated to one server. Based on criteria collected, determine if the system requires central aggregation or if only local breakout is required. Determine redundancy consideration based on your data center. Based on previous steps, you should have made some decisions about redundancy for your system. You will also need to take these factors into consideration specific to your customers. To streamline your processes, you may decide to have every customer set up the same. Alternatively, if you need more flexibility, you may decide to address each customer and each customer site on a case-by-case basis. For local sites, be sure to consider using SRST. Determine requirements for applications and services Detailed background information about each of these applications is described in the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. a) Cisco Unified Communications Manager You can set up your Cisco Unified Communications Manager in a number of different ways, depending on your deployment model. Consider the following: 88

101 Unified Communications Application Planning Determine UC Applications Requirements Decide if you want the Cisco Unified Communications Manager to reside on a dedicated server or a shared server. For more information on the different deployment models and the differences, see Determine Your HCS Data Center Deployment Model, on page 9. Decide if you want a Shared Instance deployment. For more information on Cisco Unified Communications Manager and Shared Instance see Shared Instance, on page 11. For restriction information as well as other feature details, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Features for Cisco Unified Communications Manager. Call admissions control Dial Plan Voice gateways SIP trunks Media resources Consider these factors concerning media resources: LDAP The various resources for either local Customer Premise Equipment (ISR based), data center-based or software-based system deployment. MCU for ad-hoc video conferencing. Bandwidth considerations for non-local resources. Decide if you plan to have LDAP synchronization enabled. With synchronization, consider what information you want to synchronize initially and what information comes across in the subsequent synchs. If the LDAP server does not have synchronization enabled, then the administrator should ensure consistent configurations across Unified Communications Manager and LDAP when configuring user directory number associations. You also need to consider LDAP for endpoints as well as authentication purpose, and location of LDAP, whether on premises provided by customers or in your data center. There are also NAT considerations for location of LDAP. Extension Mobility Attendant Console Cisco Paging Server - also known as Singlewire - InformaCast Basic Paging b) Cisco Unity Connection You can set up your Unity Connection in a number of different ways, depending on your deployment model. Consider the following: Decide if you want the Unity Connection to reside on a dedicated server or a shared server. For more information on the different deployment models and the differences, Determine Your HCS Data Center Deployment Model, on page 9. Partitioned Unity Connection Decide if you want to partition Unity Connection to support multiple small medium businesses as tenants on a single Cisco Unity Connection installation. For more information on partitioned Unity Connection, see Partitioned Unity Connection, on page 15. Voice messaging. 89

102 Determine UC Applications Requirements Unified Communications Application Planning Depending on how flexible you want the system to be, consider integrated messaging versus unified messaging. c) Cisco Unified Communications Manager IM and Presence Service Your Cisco Unified Communications Manager IM and Presence Service can be set up in a number of different ways, depending on your deployment model. You will want to consider aspects such as compliance and logging. Also, consider the following: Cisco Unified Communications Manager IM and Presence Service and federation consideration for MSFT. Note For more information on Cisco Unified Communications Manager IM and Presence Service and Shared Instance, see Shared Instance, on page 11. For restriction information as well as other feature details, see the Cisco Hosted Collaboration Solution, Release 10.6(1) Features for Cisco Unified Communications Manager. Cisco Unified Communications Manager IM and Presence Service inter-domain federation. Step 5 d) Cisco Emergency Responder. e) Attendant Console (CUAC). Determine requirements for software endpoints, such as Jabber. a) Determine E911 support for mobile clients, factoring in capacity impacts. You can find more details about capacity in the Cisco Hosted Collaboration Solution, Release 10.6(1) Capacity Planning Guide. You have two different choices for determining the support for E911: Inform users if 911 will not work. Force users to identify the location. With the location information, the system can either find an location to connect the emergency services or have the phone alert the user that they are not allowed to place the call. Make sure that you understand what you are required to do from a legal perspective. Your requirements will depend on the size of company, type of service, and so forth. b) Determine support for software install and upgrade of mobile and desktop clients. Phone support: Determine the clients that you plan to support, such as user downloading clients from the Apple app store or Google Play. Desktop client support: Determine the software applications that you plan to support. These applications are stored on servers, and will factor into your data center planning. For more details on data center requirements, see Determine Data Center Requirements, on page

103 CHAPTER 10 Mobility Prerequisites, page 91 Mobility Workflow, page 92 Plan the Mobility Deployment, page 92 Plan Mobile IMS Integration, page 93 Plan Carrier-Integrated Mobile Integration, page 95 Prerequisites Before you plan the mobility deployment, make sure that you: Review and have access to the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Review these specific sections: Mobility in the Applications chapter IMS network integration in the Network infrastructure chapter Complete the actions outlined in previous sections of this guide including: Initial system requirements and planned growth Data Center requirements Licensing Customer premise equipment Service fulfillment Service assurance Unified Communications applications 91

104 Mobility Workflow Mobility Mobility Workflow Plan the Mobility Deployment Procedure Step 1 Step 2 Step 3 Determine which mobile networks that you will support. Cisco HCS offers the following network choices: Carrier-integrated mobile IP Multimedia Subsystem (IMS) VoLTE and 4G WiFi Determine the mobility offerings for your Cisco HCS deployment model. Determine how you want to implement mobility in your deployment. Determine how Cisco HCS integrates with the mobile network. Different integrations have different ways of obtaining the call from the mobile network, for example, Intelligent Network trigger or routing configuration. Determine the mobility endpoints that will be provisioned. Jabber. Users will want a VPN when they are outside of the enterprise network. Carrier-integrated mobile. IMS clients. Cisco HCS integrates with the IMS network through the IMS phone types. The subscriber provisioned in the IMS network must be provisioned as an IMS client in HCS so that HCS can act as Application Server for the IMS subscribers. WiFi. 92

105 Mobility Plan Mobile IMS Integration Step 4 Step 5 See the Cisco Hosted Collaboration Solution, Release 10.6(1) Features for Cisco Unified Communications Manager at for more information on endpoints. Note The Cisco Hosted Collaboration Solution, Release 10.6(1) Features for Cisco Unified Communications Manager does not include carrier-integrated mobile or IMS-supported endpoints. Identify the UC application-based mobility features to be implemented. Dial via Office Reverse Callback Dial via Office Forward Reroute Remote Destination Call to enterprise network Mobile Connect IVR Enterprise Feature Access Redial Hand-in Hand-out Least Cost Routing with Dial via Office Reverse Callback Least Cost Routing with Dial via Office Forward Send Call to Mobile Session Handoff Identify the cloud-based collaboration applications to implement with Cisco HCS. Cisco WebEx, the Cisco Collaboration cloud-based infrastructure, is a collaboration solution that does not require any hardware deployment on the enterprise premises. All services (audio, video, and content sharing) are securely hosted in the Internet or the cloud. All the content, voice, and video traffic from every client traverses the Internet and is mixed and managed in the cloud at the WebEx data center. The Cisco Collaboration cloud infrastructure provides WebEx capabilities to mobile clients and devices. WebEx Meetings provides web-based voice and video conferencing with content sharing. WebEx Messenger provides XMPP-based IM and presence as well as point-to-point audio and video calling. Step 6 If you plan to integrate with IMS, see Plan Mobile IMS Integration, on page 93. Step 7 If you plan to integrate with carrier-integrated mobile, Plan Carrier-Integrated Mobile Integration, on page 95. Plan Mobile IMS Integration Procedure Step 1 Identify considerations for the Home Subscriber Server (HSS): 93

106 Plan Mobile IMS Integration Mobility The public ID of the IMS client is provisioned in the HSS with the subscriber profiles. The HSS provisioning should have Cisco HCS as the name of the application server. Step 2 See the Cisco HCS documentation for information on how to set up ISC trunks, the Cisco Unified Border Element-Service Provider (CUBE-SP or Perimeta SBC), and IMS clients on Cisco Unified Communications Manager. Setup considerations include: IMS network operators must provision their equipment and provide the Cisco HCS administrator with all the required data to provision Cisco HCS. The trunk between the S-CSCF and Cisco HCS should be configured in the IMS network with the DNS name of the CUBE-SP or Perimeta SBC. When the CUBE-SP or Perimeta SBC resolves that name within the Cisco HCS internal network, it must point to Cisco Unified Communications Manager. Step 3 Step 4 Step 5 Identify any CUBE-SP or Perimeta SBC media anchoring requirements. Determine if additional application servers must be included. If you are chaining together more than one application server, review the feature interaction. Review Unified Mobility offerings and IMS client features for IMS clients. The IMS client features are: Originating Identification Presentation Terminating Identification Presentation Originating Identification Restriction Terminating Identification Restriction Communication Diversion Unconditional Communication Diversion on not Logged in Communication Diversion on Busy Communication Diversion on not Reachable Communication Diversion on No Reply Barring of All Incoming Calls Barring of All Outgoing Calls Barring of All Incoming Calls When Roaming Barring of Outgoing International Calls Communication Hold Communication Retrieve Call Forward All Activation 3rd Party Registration Message Waiting Indication Communication Waiting Ad-Hoc Multi Party Conference 94

107 Mobility Plan Carrier-Integrated Mobile Integration Call Transfer Step 6 Step 7 Determine the CDR Billing parameters. Consider the P-Charging-Vector support in Cisco HCS. Determine the IMS licensing requirements. Plan Carrier-Integrated Mobile Integration Carrier-integrated mobile is a device type introduced in the Cisco Unified Communications Manager that extends mobility features outside of your UC network without the requirement to provision Cisco Jabber. This device sends and receives calls through the SIP trunk. The Unified Mobility features available in Unified Communications Manager are applicable to this device. This device type offers mobility in the same way as a remote destination offers mobility and uses fixed mobile convergence (FMC). Determine your mobility requirements for carrier integrated mobile. Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Identify requirements for the Intelligent Network trigger. The call must be directed to the CUBE-SP or Perimeta SBC. Identify requirements for SIP trunks. The P-Charging-Vector value must be set. Identify any CUBE-SP or Perimeta SBC media anchoring requirements. Determine if an application server will be included. Review the Unified Mobility offerings for carrier-integrated mobile clients. Determine the CDR Billing parameters. Determine carrier-integrated mobile licensing requirements. 95

108 Plan Carrier-Integrated Mobile Integration Mobility 96

109 CHAPTER 11 Video Prerequisites, page 97 Video Workflow, page 98 Plan the Video Network, page 98 Prerequisites Before you plan the video deployment, make sure that you: 1 Review and have access to the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Review these specific sections: HCS Video in the Applications chapter Cisco TelePresence Exchange System in the Applications chapter 2 Complete the actions outlined in previous sections of this guide including: Initial system requirements and planned growth Data center requirements Licensing Customer premise equipment Service fulfillment Service assurance 97

110 Video Workflow Video Video Workflow Plan the Video Network Procedure Step 1 Step 2 Step 3 Cisco Hosted Collaboration Solution Release 10.6(1) supports dedicated deployment of Video Conferencing on a per tenant basis using TMS, Conductor, and Telepresence Servers (virtual and Physical). Determine whether you intend to offer dedicated TP services along with Centralized TP services using CTX. Plan the capacity requirements for dedicated and shared deployment. Determine the inter-enterprise and intra-enterprise networking requirements for point-to-point video dialing. Determine if you want to allow point-to-point video calls between enterprises. To allow video calls outside of the enterprise, you must set up your video network and set up the SBCs to allow users to place calls outside of the enterprise. Decide if you want to do the inter-enterprise routing within the CUBE-SP or in the service provider's softswitch. Consider policies on selectively enabling inter-enterprise video dialing. Investigate and understand the limitations of Lawful Intercept (LI) for inter-enterprise video dialing and the LI exemption for video dialing. Step 4 Step 5 Determine if you will use scheduled conferencing or virtual meeting rooms. Cisco offers virtual meeting rooms only for Cisco HCS. Scheduled meetings with Cisco HCS are done through a third-party portal. This portal is supported, but is not validated. Scheduled Conferencing, Rendezvous Conferencing, and Adhoc Video Conferencing is supported when there are dedicated deployments of Conductor, TMS, and TelePresence servers. For CTX-based Video deployment, Scheduled Video Conferencing is not natively supported in HCS. However, with the use of a third party portal with CTX, Scheduled Conferencing can be supported. If you are planning for a third-party portal, evaluate the third-party portal and validate it against your requirements. Determine your port capacity for video conferencing based on the following estimations. These estimates should provide you with an accurate estimate of the number of users that are expected to take part in a video 98

111 Video Plan the Video Network conference at any given time. These considerations should be based on whether a centralized or dedicated video conferencing solution is being planned. Number of customers using video conferencing Number of video endpoints each customer will use Number of simultaneous video conferences that you expect Average number of participants in each video conference Average duration of video conference Use the following calculation to determine the port capacity: Number of ports needed = (number of video-enabled customers) x (number of simultaneous video meetings per customer) x (number of participants per meeting) x ( average number of ports per participant) For example, (10 customers) x ( 2 simultaneous meetings per customer) x ( 6 participants per meeting) x ( 1 port per participant) = 120 ports The average number of ports per participant must take into account the distribution of different types of endpoints (number of screens), the quality of the video (HD, SD, Audio only), and presentation sharing. Each port is assumed to provide a 1080p HD quality video. Step 6 Determine the type of video endpoints supported in the network. Immersive video endpoints Non-immersive video endpoints Immersive video endpoints enable the best possible in-person TelePresence video collaboration experience, where attendees across multiple locations feel as though they are in the same room. Due to the high quality of the video media, immersive video endpoints consume higher amounts of bandwidth and network resources than non-immersive video endpoints. Step 7 Step 8 Step 9 Step 10 Determine whether you will provide video dialing between different service providers. To provide video dialing between different service providers, you must set up the CUBE-SP to provide connectivity between the different service providers. Make sure that agreements and routing policies are in place for interprovider video dialing. Determine whether you want to support over-the-top (OTT) connectivity for guest clients from other enterprises and integrate Microsoft Lync along with Dedicated Video Conferencing with Conductor/TMS/Virtual TS. You can use Cisco Expressway to set up connectivity. Determine if you will need to transcode codecs within your video network. If yes, you will need to implement the Cisco TelePresence MSE 8710 server for transcoding. If no, you can use Cisco TelePresence Multipoint Switch (CTMS). CTMS is a less expensive option than the MSE, but DTLS is not supported with CTMS so any CTX-based calls will be unsecure if you choose CTMS. Determine your bandwidth and QoS requirements for video, using the following information: Number of ports 99

112 Plan the Video Network Video Number of endpoints Immersive or non-immersive video. Note Immersive video has higher bandwidth requirements. Types of endpoints Use the following guidelines to evaluate bandwidth requirements: For every (shared) three-screen TelePresence room at 1080p, add 16.7 Mbps (assumes 100 percent utilization because these are shared services ) For every single-screen TelePresence at 1080p, add 4.5 Mbps (assumes 100 percent utilization, see above) For every single-screen TelePresence at 720p, add 1.68 Mbps (assumes 100 percent utilization) For shared EX-90 at 720p, add 1.5 Mbps (assumes 100 percent utilization) For personal (nonshared) EX-90 at 720p, add 136 Kbps (assumes much lower utilization) Step 11 Step 12 Determine your security requirements for signaling and media. TLS for signaling encryption DTLS for media encryption SRTP media encryption Determine the CTX model to use. Starter Package If you choose the Starter Package, there is a maximum of 250 ports with no active meeting management license. Active video calls are not preserved. ACE is not required with the Starter Package. Classic Package If you choose the Classic Package, ACE will be implemented. Step 13 Consider the following when determining networking requirements: Data Center Network for video infrastructure VLANs Virtual routing and forwarding (VRF) TPaas network devices and applications which are deployed in a shared environment 100

113 CHAPTER 12 HCS for Contact Center Prerequisites, page 101 HCS for Contact Center Workflow, page 102 Plan the HCS for Contact Center Deployment, page 102 Determine the HCS for Contact Center Deployment Model, page 103 Determine the Hardware Requirements, page 130 Determine the Software Requirements, page 132 Plan Solution Serviceability, page 132 Determine the Active Directory Deployment, page 136 Determine the Blade and Storage Placement Requirements, page 137 Determine High Availability Requirements, page 137 Plan the Solution for Handling Congestion Control, page 138 Plan the UCS Networking Requirements, page 138 Determine the Trunk Design, page 139 Firewall Hardening Considerations, page 140 Prerequisites Before you plan the HCS for Contact Center deployment, review the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide and Installing and Configuring Cisco HCS for Contact Center. Consider the following carefully: Initial system requirements and planned growth Data center requirements Licensing Customer premise equipment Service fulfillment 101

114 HCS for Contact Center Workflow HCS for Contact Center 6 Service assurance HCS for Contact Center Workflow Plan the HCS for Contact Center Deployment The following sections provide HCS for Contact Center deployment planning details: Determine the HCS for Contact Center Deployment Model, on page 103 Determine the Hardware Requirements, on page 130 Determine the Software Requirements, on page 132 Plan Solution Serviceability, on page 132 Determine the Active Directory Deployment, on page 136 Determine the Blade and Storage Placement Requirements, on page 137 Determine High Availability Requirements, on page 137 Plan the Solution for Handling Congestion Control, on page 138 Plan the UCS Networking Requirements, on page 138 Determine the Trunk Design, on page 139 Firewall Hardening Considerations, on page

115 HCS for Contact Center Determine the HCS for Contact Center Deployment Model Determine the HCS for Contact Center Deployment Model Procedure Step 1 Identify the number of agents that you require: 100 or less, 500, 1000, 4000 or 12,000. Step 2 Step 3 Review the Configuration Limits, on page 104 for agents, supervisors, teams, and reporting users of each deployment model. Consider your initial requirements as well as any planned growth. Identify any optional Cisco components to include in the deployment. AW-HDS-DDS server (Administration Server, Real-Time and Historical Data Server, and Detail Data server). The AW-HDS-DDS server is a core component for the 4000-agent deployment. SPAN-based monitoring Cisco Unified Web Interaction Manager (WIM) and Unified Interaction Manager (EIM) Cisco Remote Silent Monitoring (RMS) Cisco MediaSense Step 4 Step 5 Review the Optional Component Considerations, on page 110. Consider your initial requirements as well as any planned growth. Identify any third-party components to include in the deployment. Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) Recording Wallboard Workforce Management 103

116 Configuration Limits HCS for Contact Center Configuration Limits Table 18: Agents, Supervisors, Teams, Reporting Users Group Resource 500 Agent Deployment 1000 Agent Deployment 4000 Agent Deployment Agent Deployment Small Contact Center Deployment Agents Active Agents* Configured Agents* Agents with Trace ON 50* 100* 400* * Agent Desk Settings* Active Mobile Agents See, Mobile Agent Support, on page 105 See, Mobile Agent Support, on page 105 See, Mobile Agent Support, on page 105 Configured Mobile Agents Outbound Agents Agents per team 50* 50* 50* 50 50* Queues per Agent (Skill Groups and Precision Queues combined) 15* 15* 15* 15 15* Agents per skill group No limit No limit No limit No limit No limit Attributes per agent*

117 HCS for Contact Center Configuration Limits Group Resource 500 Agent Deployment 1000 Agent Deployment 4000 Agent Deployment Agent Deployment Small Contact Center Deployment Supervisors Active Supervisors* Configured Supervisors* Active teams* Configured teams* Supervisors per Team 10* 10* 10* 10 10* Teams per supervisor 20* 20* 20* 20 20* Agents per supervisor Reporting Active Reporting users Configured Reporting users Access Control Administrator (Users) Mobile Agent Support Follow the below calculation to determine mobile agent capacity: Each mobile agent for a nailed connection (nailed-up configuration) = two local agents Note Total number of agents should be less than deployment limits For 500 and 1000 agent deployments if active mobile agent requirement exceeds the specified limit, use the above formula to determine mobile agent capacity 105

118 Configuration Limits HCS for Contact Center Note 1 Preview, Direct Preview, Progressive and Predictive dialing modes are supported. 2 For SIP Outbound Dialer in HCS for Contact Center deployment, if CUSP is not used only one gateway can be connected. If CUSP is not used in the deployment the maximum configured ports are 500 dialer ports in the ICM and in the IOS gateway. If CUSP is used in the deployment the maximum configured ports are 1500 dialer ports. 3 The Symbol * indicates that the configuration limits for the above resources are enforced through CCDM. 4 Number of active and configured mobile agents are considered from the total supported active and configured mobile agents. 5 Number of active and configured outbound agents are considered from the total supported active and configured outbound agents. Group Resource 500 Agent Deployment 1000 Agent Deployment 4000 Agent Deployment Agent Deployment Small Contact Center Deployment Outbound Dialer per system Number of Campaigns (Agent/IVR based) Campaign skill groups per campaign Queues per Agent (Skill Groups and Precision Queues combined) Total Numbers of Agents Port Throttle

119 HCS for Contact Center Configuration Limits Group Resource 500 Agent Deployment 1000 Agent Deployment 4000 Agent Deployment Agent Deployment Small Contact Center Deployment Precision Queues Precision Queues* Precision Queue steps* Precision Queue term per Precision Queue* Precision steps per Precision Queue* Unique attributes per Precision Queue*

120 Configuration Limits HCS for Contact Center Group Resource 500 Agent Deployment 1000 Agent Deployment 4000 Agent Deployment Agent Deployment Small Contact Center Deployment General Attributes* Bucket Intervals Active Call Types Configured Call Types* Call Type Skill Group per Interval Active Routing Scripts Configured Routing Scripts Network VRU Scripts * Reason Codes Skill Groups* Persistent Enabled Expanded Call Variables * Persistent Enabled Expanded Call Variable Arrays Nonpersistent Expanded Call Variables(Bytes)* Bulk Jobs CTI All event Clients 9/PG 9/PG 9/PG 9/PG 9/PG 108

121 HCS for Contact Center Features & Options in Small Contact Center Deployment Group Resource 500 Agent Deployment 1000 Agent Deployment 4000 Agent Deployment Agent Deployment Small Contact Center Deployment Dialed Number Dialed Number (External Voice) Dialed Number (Internal Voice) Dialed Number (Multichannel) Dialed Number (Outbound Voice) Load VRU Ports Calls per second Agent Load 30 BHCA 30 BHCA 30 BHCA 30 BHCA 30 BHCA Reskilling Dynamic (operations/hr.) Features & Options in Small Contact Center Deployment The following table lists the Features and Optional component Multi tenancy capabilities in a Small Contact Center Deployment. Features/Optional Components Outbound Dialer Outbound Campaigns WIM and EIM Remote Silent Monitoring Notes A single Outbound Dialer per Sub customer is supported, not exceeding 32 sub customers. Each sub-customer supports 30 campaigns and total campaigns supported is 300. A single WIM and EIM instance per sub customer is supported, not exceeding 74 sub customers. A single RSM instance will support up to 6 sub customers and 120 concurrent sessions supported per RSM. A single RSM instance per sub customer is supported. Media Sense A single Media Sense instance per sub customer, not exceeding 149 sub customers. 109

122 Optional Component Considerations HCS for Contact Center Optional Component Considerations This section describes the capabilities of the following Cisco Optional Components: Unified WIM and EIM Considerations, on page 110 Cisco RSM Considerations, on page 123 Cisco MediaSense Considerations, on page 126 Cisco Unified SIP Proxy Considerations, on page 127 Cisco SPAN based Monitoring Considerations, on page 128 Unified WIM and EIM Considerations This section describes the following considerations for Unified WIM and EIM. Unified WIM and EIM Design Considerations, on page 116 Unified WIM and EIM Deployment Options, on page 110 Unified WIM and EIM Configuration Limits, on page 111 HCS Support Matrix for Unified WIM and EIM, on page 112 Unified WIM and WIM High Availability, on page 118 Cisco WIM and EIM Bandwidth, Latency and QOS Considerations, on page 123 Unified WIM and EIM Deployment Options Due to the modular, component-based nature of the architecture, Cisco WIM and EIM has the ability to cater to the growing demands for concurrent user loads. To provide the flexibility to suit deployments of varied sizes, Cisco WIM and EIM supports various components that may be distributed across various servers in a deployment. Collocated Deployment In Collocated deployment option, the web server is installed on a separate machine and all other components are installed on one machine. The web server may be installed outside the firewall, if required. Figure 5: Collocated Deployment 110

123 HCS for Contact Center Optional Component Considerations Distributed-Server Deployment In this configuration, each component is on a separate machine, with the web server installed outside the firewall. The application, messaging, services, and web servers in this configuration can be restarted without restarting any other servers. Figure 6: Distributed-Server Deployment Unified WIM and EIM Configuration Limits Unified WIM and EIM Configuration Limits Table 19: Unified WIM and EIM Configuration Limits Group Resource Unified WIM and EIM Distributed server Deployment Unified WIM and EIM Collocated Deployment Multimedia Agents (any combination of , Chat and Web callback activities) 1250 # 200 ## Maximum Number of s per agent per hour 5 12 Maximum Number of chats per agent per hour 5 10 Maximum Number of Web Callback per agents per hour

124 Optional Component Considerations HCS for Contact Center Note The Symbol "#" indicates that the Unified WIM and EIM Distributed server Deployment allows combination of maximum 600 concurrent Web Callback and for the remaining it allows any combination of or Chat activities. The Symbol "##" indicates that the Unified WIM and EIM Collocated Deployment allows combination of maximum 100 concurrent Web Callback and for the remaining it allows any combination of or Chat activities. HCS Support Matrix for Unified WIM and EIM HCS Support Matrix for Unified WIM and EIM Table 20: HCS Support Matrix for Unified WIM and EIM HCS for CC Deployment HCS for CC 500 Agent Deployment HCS for CC 1000 Agent Deployment HCS for CC 4000 Agent Deployment HCS for CC Agent Deployment HCS for CC Small Contact Center Agent Deployment Unified WIM and EIM Distributed server Deployment Support can't exceed 500 Multimedia agents Support can't exceed 1000 Multimedia agents Yes Yes No Unified WIM and EIM Collocated Deployment Yes Yes Yes Yes Yes Cisco RSM Capabilities Platform Call Flow Desktop Voice Codec Concurrent Monitoring Sessions Monitored Calls (per minute) Capabilities The Supervisor can only monitor agents who are in talking state. CTIOS Between Agent and RSM: G.729 (RTP) Between RSM and VXML Gateway: G.711 (RTSP)

125 HCS for Contact Center Optional Component Considerations Platform Maximum Configured Agents per PG SimPhone Start line Number Range Capabilities Four to fifteen digits Cisco MediaSense Capabilities Platform Phone Supported Model Voice Codec Session Media Forking Network Capabilities All HCS supported Phone. See list of supported phones in Voice Infrastructure, on page 113 section. 2vCPU, 4vCPU and 7vCPU profiles. G.711 and G.729 See session related details in for_cisco_mediasense#version_10.x. CUBE, Phone and TDM Inter cluster communication over WAN is not supported. Voice Infrastructure The following table lists the voice infrastructure. Table 21: Voice Infrastructure Voice Infrastructure Music on Hold HCS for Contact Center Deployment Unicast Multicast Unified CM Subscriber source only Notes This sizing applies to agent node only, for both agent and back-office devices, with all agent devices on the same node pair. 113

126 Optional Component Considerations HCS for Contact Center Voice Infrastructure Proxy HCS for Contact Center Deployment SIP Proxy is optionally supported. Notes High Availability (HA) and load balancing are achieved using these solution components: Time Division Multiplexing (TDM) gateway and Unified CM, which use the SIP Options heartbeat mechanism to perform HA. Unified CVP servers, which use the SIP server group and SIP Options heartbeat mechanism to perform HA and load balancing. Ingress Gateways Protocol Proxy /Cisco Unified SIP Proxy (CUSP) ISR G2 Cisco Unified Border Element with combination VXML Session Initiation Protocol (SIP) over TCP SIP Proxy is optionally supported. 3925E and 3945E are the supported GWs. For SPAN based Silent Monitoring, the Ingress gateway is spanned. You must configure the gateway MTPs to do a codec pass-through because the Mobile Agent in HCS is configured to use G729 and the rest of the components in HCS support all the codecs. See CVP SRND for list of supported gateway models and corresponding sizing. SIP over UDP, H323, Media Gateway Control Protocol (MGCP) are not supported. Outbound Option: The Outbound dialer can connect to only one physical gateway, if SIP proxy is not used. See Configuration Limits, on page

127 HCS for Contact Center Optional Component Considerations Voice Infrastructure Codec HCS for Contact Center Deployment IVR: G.711ulaw and G.711alaw Agents: G.711ulaw, G.711 alaw, and G729r8 Notes G.722, isac, and ilbc are not supported. Media Resources Gateway-based: Conference bridges Transcoders and Universal Transcoders Hardware and IOS Software Media Termination Points. Unified CM-based (Cisco IP Voice Media Streaming Application) that are not supported: Conference bridges MTPs Optional Component Considerations This section describes the capabilities of the following Cisco Optional Components: Unified WIM and EIM Considerations, on page 110 Cisco RSM Considerations, on page 123 Cisco MediaSense Considerations, on page 126 Cisco Unified SIP Proxy Considerations, on page 127 Cisco SPAN based Monitoring Considerations, on page 128 Unified WIM and EIM Considerations This section describes the following considerations for Unified WIM and EIM. Unified WIM and EIM Design Considerations, on page 116 Unified WIM and EIM Deployment Options, on page 110 Unified WIM and EIM Configuration Limits, on page 111 HCS Support Matrix for Unified WIM and EIM, on page 112 Unified WIM and WIM High Availability, on page 118 Cisco WIM and EIM Bandwidth, Latency and QOS Considerations, on page

128 Optional Component Considerations HCS for Contact Center Unified WIM and EIM Design Considerations Figure 7: Unified WIM and EIM Design Considerations Note Cisco Media Blender is used only for Web/Scheduled Callback feature. Unified WIM and EIM Deployment Options Due to the modular, component-based nature of the architecture, Cisco WIM and EIM has the ability to cater to the growing demands for concurrent user loads. To provide the flexibility to suit deployments of varied sizes, Cisco WIM and EIM supports various components that may be distributed across various servers in a deployment. Collocated Deployment In Collocated deployment option, the web server is installed on a separate machine and all other components are installed on one machine. The web server may be installed outside the firewall, if required. Figure 8: Collocated Deployment 116

129 HCS for Contact Center Optional Component Considerations Distributed-Server Deployment In this configuration, each component is on a separate machine, with the web server installed outside the firewall. The application, messaging, services, and web servers in this configuration can be restarted without restarting any other servers. Figure 9: Distributed-Server Deployment Unified WIM and EIM Configuration Limits Unified WIM and EIM Configuration Limits Table 22: Unified WIM and EIM Configuration Limits Group Resource Unified WIM and EIM Distributed server Deployment Unified WIM and EIM Collocated Deployment Multimedia Agents (any combination of , Chat and Web callback activities) 1250 # 200 ## Maximum Number of s per agent per hour 5 12 Maximum Number of chats per agent per hour 5 10 Maximum Number of Web Callback per agents per hour

130 Optional Component Considerations HCS for Contact Center Note The Symbol "#" indicates that the Unified WIM and EIM Distributed server Deployment allows combination of maximum 600 concurrent Web Callback and for the remaining it allows any combination of or Chat activities. The Symbol "##" indicates that the Unified WIM and EIM Collocated Deployment allows combination of maximum 100 concurrent Web Callback and for the remaining it allows any combination of or Chat activities. HCS Support Matrix for Unified WIM and EIM HCS Support Matrix for Unified WIM and EIM Table 23: HCS Support Matrix for Unified WIM and EIM HCS for CC Deployment HCS for CC 500 Agent Deployment HCS for CC 1000 Agent Deployment HCS for CC 4000 Agent Deployment HCS for CC Agent Deployment HCS for CC Small Contact Center Agent Deployment Unified WIM and EIM Distributed server Deployment Support can't exceed 500 Multimedia agents Support can't exceed 1000 Multimedia agents Yes Yes No Unified WIM and EIM Collocated Deployment Yes Yes Yes Yes Yes Unified WIM and WIM High Availability The following table contains the Cisco Unified WIM and EIMhigh availability during the failover of Unified CCE processes. 118

131 HCS for Contact Center Optional Component Considerations Component PG Failover scenario Unified Communications Manager PG Failover New session (Web Callback/ Delayed callback/ Chat/ ) impact Web Callback - The new call is lost, because there is no Longest Available agent during the failure of PG. Delayed Callback - The new call reaches the customer and the agent after the PG on the other side becomes active and the delay that the customer specifies gets complete. Chat - The new chat initiated by the customer reaches the agent after the other side of the PG becomes active. - The new sent by the customer reaches the agent. Active session (Web Callback/ Delayed callback/ Chat/ ) impact Active Web Callback, Delayed callback, Chat, and sessions continue uninterrupted. Post recovery action Agent receives the Call, Chat or after the PG becomes active and the agent logins again. 119

132 Optional Component Considerations HCS for Contact Center Component PG Failover scenario MR PG Failover New session (Web Callback/ Delayed callback/ Chat/ ) impact Web Callback - The new call is established between the customer and the agent after the PG becomes active. Delayed Callback - The new call reaches the customer and the agent after the PG on the other side becomes active and the delay that the customer specifies gets complete. Chat - The new chat initiated by the customer reaches the agent once the other side of the PG becomes active. - The new sent by the customer reaches the agent. Active session (Web Callback/ Delayed callback/ Chat/ ) impact Active Web Callback, Delayed callback, Chat, and sessions continue uninterrupted. Post recovery action Agent receives the Call, Chat or once the PG becomes active. 120

133 HCS for Contact Center Optional Component Considerations Component CG Failover scenario CTI Failover New session (Web Callback/ Delayed callback/ Chat/ ) impact Web Callback -The new call cannot be placed and the customer receives the message, "System cannot assign an Agent to the request." Delayed Callback - The new call reaches the customer and the agent after the CG on the other side becomes active and the delay that the customer specifies gets complete. Chat - The new chat initiated by the customer reaches the agent after the other side of the CG process becomes active. - The new sent by the customer reaches the agent. Active session (Web Callback/ Delayed callback/ Chat/ ) impact Active Web Callback, Delayed callback, Chat, and sessions continue uninterrupted. Post recovery action Agent receives the Call, Chat or once the process becomes active. 121

134 Optional Component Considerations HCS for Contact Center Component CTI OS Failover scenario CTI OS Server Failure New session (Web Callback/ Delayed callback/ Chat/ ) impact Web Callback - The new call is established without any impact. Delayed Callback - The new call is established without any impact after the delay that the customer specifies gets complete. Chat - The new chat reaches the agent without any impact. - The new sent by the customer reaches the agent. Active session (Web Callback/ Delayed callback/ Chat/ ) impact Active Web Callback, Delayed callback, Chat, and sessions continue uninterrupted. Post recovery action Seamless. Router Router fails Web Callback - The new call is established through other side of the router process. Delayed Callback - The new call is established through other side of the router process and once the delay mentioned by the customer completes. Active Web Callback, Delayed callback, Chat and sessions continue uninterrupted. Agent gets the Call, Chat or with other side of the router process. Chat - The new chat reaches the agent through other side of the router process. - The new sent by the customer reaches the agent through other side of the router process. 122

135 HCS for Contact Center Optional Component Considerations Cisco WIM and EIM Bandwidth, Latency and QOS Considerations The minimum required network bandwidth for an agent connecting to the Cisco Interaction Manager servers on login is 384 kilobits/second or greater. After login in a steady state an average bandwidth of 40 kilobits/second or greater is required. An attachment of size up to 50 KB is supported within this required bandwidth. For attachments of size greater than 50 KB, you may experience slow speed temporarily in the agent user interface during download of the attachments. Cisco RSM Considerations Cisco RSM Design Considerations, on page 123 Cisco RSM High Availability, on page 123 Cisco RSM Capabilities, on page 112 Cisco RSM Bandwidth, Latency and QOS Considerations, on page 125 Cisco RSM Design Considerations Figure 10: Cisco RSM Design Considerations Cisco RSM High Availability The following table shows the Cisco RSM High Availability. 123

136 Optional Component Considerations HCS for Contact Center Table 24: Cisco RSM High Availability Component RSM Server CTI OS Server CTI VLEngine PhoneSim Unified CM JTAPI Unified CVP Failover/Failure Scenario RSM server (hardware) fails CTI OS Server Failure Active CTI Gateway process fails VLEngine fails PhoneSim fails Active Subscriber fails JTAPI gateway fails Active CVP fails New Call Impact Attempts to contact the RSM server fail Supervisor can monitor new calls without any failure Supervisor can establish new monitoring sessions until the secondary CTI process becomes active Supervisor can establish new monitoring sessions when VLEngine becomes active Supervisor can monitor new calls when PhoneSim becomes active New calls cannot be established until the secondary subscriber becomes active Supervisor can establish new calls without any failure New calls cannot be established until the Unified CVP becomes active Active Call Impact Active monitoring sessions terminate and supervisor is directed to the main menu Active monitoring sessions will continue normally Active monitoring sessions continue normally Active monitoring sessions terminate and supervisor is directed to the main menu Active monitoring sessions continue normally Active monitoring sessions continue normally Active monitoring sessions continue normally Active monitoring sessions terminate Post-recovery Action Supervisor can monitor calls after the RSM server becomes active Failover is seamless After the CTI Gateway becomes active the supervisor can establish new monitoring sessions After the VLEngine becomes active the supervisor can establish new monitoring sessions After the PhoneSim becomes active the supervisor can establish new monitoring sessions After the secondary subscriber becomes active the supervisor can establish new monitoring sessions Failover is seamless After the Unified CVP becomes active the supervisor can establish new monitoring sessions 124

137 HCS for Contact Center Optional Component Considerations Cisco RSM Capabilities Platform Call Flow Desktop Voice Codec Concurrent Monitoring Sessions Monitored Calls (per minute) Maximum Configured Agents per PG SimPhone Start line Number Range Capabilities The Supervisor can only monitor agents who are in talking state. CTIOS Between Agent and RSM: G.729 (RTP) Between RSM and VXML Gateway: G.711 (RTSP) Four to fifteen digits Cisco RSM Bandwidth, Latency and QOS Considerations RSM Peer Purpose Protocols Used Data Format Relative Bandwidth Requirements Link Latency Requirements VRU Service Requests and Responses TCP (HTTP) Textual Minimal < 500 ms avg. VRU Requested Voice Data from PhoneSim to VRU TCP (HTTP) G711, chunked transfer mode encoding High (about 67 to 87 kbps per session) < 400 ms avg. Unified CM Issuance of Agent Phone Monitoring TCP (JTAPI) Binary (JTAPI stream) Minimal < 300 ms avg. CTI OS Server (PG) Environment Events and Supervisor Logins TCP (CTI OS) Binary (CTI OS stream) Minimal < 300 ms avg. Agent Phones Simulated Phone Signaling TCP or UDP (SIP) Textual Minimal < 400 ms avg. Agent Phones Monitored Phone Voice Data UDP (RTP) Binary (G.711) High (about 67 to 87 kbps per session) < 400 ms avg 125

138 Optional Component Considerations HCS for Contact Center Cisco MediaSense Considerations Cisco MediaSense Design Considerations, on page 126 Cisco MediaSense Capabilities, on page 113 Cisco MediaSense High Availability, on page 127 Cisco MediaSense Bandwidth, Latency and QOS Considerations, on page 127 Cisco MediaSense Design Considerations Figure 11: Cisco MediaSense Design Considerations Cisco MediaSense Capabilities Platform Phone Supported Model Voice Codec Capabilities All HCS supported Phone. See list of supported phones in Voice Infrastructure, on page 113 section. 2vCPU, 4vCPU and 7vCPU profiles. G.711 and G

139 HCS for Contact Center Optional Component Considerations Platform Session Media Forking Network Capabilities See session related details in for_cisco_mediasense#version_10.x. CUBE, Phone and TDM Inter cluster communication over WAN is not supported. Cisco MediaSense High Availability Component Recording Sever Database Failover/Failure Scenario Primary Recording Sever is down Secondary Recording Server Either Primary or Secondary server goes down New Call Impact Distributes the incoming load across the remaining severs. No Impact No Impact Active Call Impact Unified CM sets a time limit beyond which, if the recording hasn't begun, it will stop trying, and Active calls will not get recorded till CM established the connection with Recording server. No Impact No Impact Postrecovery Action Call will get recorded on failed recording sever once it becomes active. No Impact Data Replication begins automatically. Cisco MediaSense Bandwidth, Latency and QOS Considerations MediaSense requires gigabit LAN connectivity with 2ms or less between servers within a cluster. Cisco Unified SIP Proxy Considerations Consists of 2 gateways for redundancy, geographically separated, 1 proxy module each, using SRV priority for redundancy of proxies, no HSRP CUSP can co-reside with VXML or TDM gateways. In earlier versions of Unified CVP due to platform validation restriction co-residency was not supported, and a dedicated ISR was required for proxy functionalities TDM gateways are configured with SRV or with Dial Peer Preferences to use the primary and secondary CUSP proxies CUSP is set with Server Groups to find primary and back up Unified CVP, Unified CM and VXML gateways Unified CVP is set up with Server Group to use the primary and secondary CUSP proxies 127

140 Optional Component Considerations HCS for Contact Center Cisco Unified CM is set up with a Route Group with multiple SIP Trunks, to use the primary and secondary CUSP proxies Performance Matrix for CUSP Deployment CUSP baseline tests were done in isolation on the proxy, and capacity numbers (450 TCP transactions per second) should be used as the highest benchmark, and most stressed condition allowable. A CVP call, from the proxy server perspective, entails on average, 4 separate SIP calls: Caller inbound leg VXML outbound leg Ringtone outbound leg Agent outbound leg When a consult with CVP queuing occurs, an additional 4 SIP transactions will be incurred for the session, effectively doubling the number of calls. Note Always turn the Record Route setting off on the proxy server to avoid a single point of failure and allow fault tolerance routing, as well as increase the performance of the Proxy server. Using record route setting on the proxy server doubles the impact to performance, as shown in the CUSP baseline matrix, and also breaks the high availability model since the proxy becomes a single point of failure for the call, if the proxy were to go down. Record Route is turned off by default on CUSP. Cisco SPAN based Monitoring Considerations Silent Monitoring Bandwidth, Latency and QOS Considerations With Silent Monitoring supervisors can listen to the agent calls in Unified CCE call centers that use CTI OS. Voice packets sent to and received by the monitored agent's IP hardware phone are captured from the network and sent to the supervisor desktop. At the supervisor desktop, these voice packets are decoded and played on the supervisor's system sound card. Silent Monitoring of an agent consumes approximately the same network bandwidth as an additional voice call. If a single agent requires bandwidth for one voice call, then the same agent being silently monitored requires bandwidth for two concurrent voice calls. To calculate the total network bandwidth required for your call load, multiply the number of calls by the per-call bandwidth figure for your particular codec and network protocol. Optional Component Bandwidth, Latency and QOS Considerations This section describes the bandwidth and QOS considerations for Cisco HCS for Contact Center Optional components. Silent Monitoring Bandwidth, Latency and QOS Considerations, on page 128 Cisco RSM Bandwidth, Latency and QOS Considerations, on page 125 Cisco WIM and EIM Bandwidth, Latency and QOS Considerations, on page 123 Cisco MediaSense Bandwidth, Latency and QOS Considerations, on page

141 HCS for Contact Center Optional Component Considerations Silent Monitoring Bandwidth, Latency and QOS Considerations With Silent Monitoring supervisors can listen to the agent calls in Unified CCE call centers that use CTI OS. Voice packets sent to and received by the monitored agent's IP hardware phone are captured from the network and sent to the supervisor desktop. At the supervisor desktop, these voice packets are decoded and played on the supervisor's system sound card. Silent Monitoring of an agent consumes approximately the same network bandwidth as an additional voice call. If a single agent requires bandwidth for one voice call, then the same agent being silently monitored requires bandwidth for two concurrent voice calls. To calculate the total network bandwidth required for your call load, multiply the number of calls by the per-call bandwidth figure for your particular codec and network protocol. Cisco RSM Bandwidth, Latency and QOS Considerations RSM Peer Purpose Protocols Used Data Format Relative Bandwidth Requirements Link Latency Requirements VRU Service Requests and Responses TCP (HTTP) Textual Minimal < 500 ms avg. VRU Requested Voice Data from PhoneSim to VRU TCP (HTTP) G711, chunked transfer mode encoding High (about 67 to 87 kbps per session) < 400 ms avg. Unified CM Issuance of Agent Phone Monitoring TCP (JTAPI) Binary (JTAPI stream) Minimal < 300 ms avg. CTI OS Server (PG) Environment Events and Supervisor Logins TCP (CTI OS) Binary (CTI OS stream) Minimal < 300 ms avg. Agent Phones Simulated Phone Signaling TCP or UDP (SIP) Textual Minimal < 400 ms avg. Agent Phones Monitored Phone Voice Data UDP (RTP) Binary (G.711) High (about 67 to 87 kbps per session) < 400 ms avg Cisco WIM and EIM Bandwidth, Latency and QOS Considerations The minimum required network bandwidth for an agent connecting to the Cisco Interaction Manager servers on login is 384 kilobits/second or greater. After login in a steady state an average bandwidth of 40 kilobits/second or greater is required. An attachment of size up to 50 KB is supported within this required bandwidth. For attachments of size greater than 50 KB, you may experience slow speed temporarily in the agent user interface during download of the attachments. 129

142 Determine the Hardware Requirements HCS for Contact Center Cisco MediaSense Bandwidth, Latency and QOS Considerations MediaSense requires gigabit LAN connectivity with 2ms or less between servers within a cluster. Determine the Hardware Requirements Procedure Step 1 Step 2 Determine the hardware requirements by using one of the following hardware configurations: Tested Reference Configurations, on page 130. You must use UCS B230 M2 blade servers in a specific configuration. Specification-Based Hardware Support, on page 131. You can use UCS B2XX blade servers with a Cisco Unified Border Element (Enterprise edition). If the deployment includes optional Cisco or third-party components, determine if you require additional hardware. See the storage and blade placement considerations section in Installing and Configuring Cisco HCS for Contact Center at hosted-collaboration-solution-contact-center/products-installation-guides-list.html. Tested Reference Configurations This section lists the specifications for the UCSB200 M3 Blade server. The source system at the partner or service provider uses one core server for the golden template environment. The customer destination system must run in a duplexed environment using a pair of core Unified Computing System (UCS) UCSB200 M3 blade servers known as Side A and Side B. Table 25: B200 M3 Blades Server Model CPU Type CPU Cores Memory Disks Cisco UCS B200 M3 Tested Reference Configuration (TRC) blade server Intel(R) Xeon(R) 2.80 GHz E v2/15w 10C/25MB Cache Two 10-core CPUs 16 X [16GB DDR MHz-RDIMM/PC /dual rank/x4/1.5v] Diskless 130

143 HCS for Contact Center Specification-Based Hardware Support Server Model Virtual Interface Part Number Cisco UCS B200 M3 Tested Reference Configuration (TRC) blade server Cisco UCS VIC 1240 modular LOM for M3 blade servers UCS-EZ7-B200-P Specification-Based Hardware Support Cisco HCS for Contact Center supports specification-based hardware, but limits this support to only UCS B-Series blade hardware. This section provides the supported server hardware, component version, and storage configurations. Table 26: Hardware Requirements Server Cisco UCS B2XX Blade Server, such as Cisco UCS-B200M2-VCS1 Blade Server Cisco UCS-B200M3 Blade Server Cisco UCS-B230M2-VCDL1 Blade Server Cisco Unified Border Element Enterprise Gateway Cisco Unified Border Element SP Component CPU Type Memory Virtual Interface Card Description Intel Xeon 5600 family 2.40 GHz physical core speed minimum Intel Xeon 7500 family 2.40 GHz physical core speed minimum Intel Xeon E family 2.4 GHz physical core speed minimum Intel Xeon E family 2.4 GHz physical core speed minimum Intel Xeon E family 2.4 GHz physical core speed minimum Intel Xeon E family 2.4 GHz physical core speed minimum Intel Xeon E family 2.4 GHz physical core speed minimum 128 GB minimum In addition to legacy M71KR-Q support, all Cisco Virtual Interface Cards (VICs) are also supported. ISR G2 with a combination of TDM and VXML. Cisco supports ISR G2, which includes 3925E and 3945E gateways. Cisco ASR 1000 series with Unified model 131

144 Determine the Software Requirements HCS for Contact Center Server Cisco Unified SIP Proxy Adaptive Security Appliance Component Description Services Module with Services Ready Engine Cisco ASA 5585 Note For specification-based hardware, total CPU reservations must be within 65 percent of the available CPU of the host and total memory reservations must be within 80% of the available memory of the host. Determine the Software Requirements Before You Begin Review the Cisco Hosted Collaboration Solution Compatibility Matrix at partner/products/ps11363/products_device_support_tables_list.html. Review the required software section in Installing and Configuring Cisco HCS for Contact Center at hosted-collaboration-solution-contact-center/products-installation-guides-list.html. Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Identify the required software for Cisco HCS for Contact Center for the required and optional components. Identify the requirements for automation software. Identify any requirements for third-party software. Identify the requirements for software licenses according to the agent deployment model. Identify any requirements for configuration software. Plan Solution Serviceability Procedure Step 1 Step 2 Review the specified limits for the virtual machine performance counters. See Virtual Machine Performance Monitoring, on page 133. Review the specified limits for the EXSi performance counters. See ESXi Performance Monitoring, on page

145 HCS for Contact Center Virtual Machine Performance Monitoring Virtual Machine Performance Monitoring The virtual machines must operate within the specified limits of the Virtual Machine performance counters listed in the following table. Table 27: Virtual Machine Performance Counters Category Counter Description Threshold CPU CPU Usage (Average) The CPU usage average in percentage for the VM and for each of the vcpus. 60% CPU Usage in MHz (Average) The CPU usage average in MHz. 95 percentile is less than 60% of the total MHz available on the VM. Total MHz = vcpus x (Clock Speed). CPU Ready The time a virtual machine or other process waits in the queue in a ready-to-run state before it can be scheduled on a CPU. 150 msec. Memory Memory Usage (Average) Memory Usage = Active / Granted * % Memory Active (Average) Memory that the guest OS and its applications actively use or reference. The server starts swap when it exceeds the amount of memory on the host. 95 percentile is less than 80% of the granted memory. Memory Balloon (Average) ESXi uses balloon driver to recover memory from less memory-intensive VMs so it can be used by those with larger active sets of memory. 0 Memory Swap used (Average) ESX Server swap usage. Use the disk for RAM swap

146 ESXi Performance Monitoring HCS for Contact Center Category Counter Description Threshold Disk Disk Usage (Average) Disk Usage = Disk Read rate + Disk Write rate Ensure that your SAN is configured to handle this amount of disk I/O. Disk Usage Read rate The rate of reading data from the disk. Ensure that your SAN is configured to handle this amount of disk I/O. Disk Usage Write rate The rate of writing data to the disk. Ensure that your SAN is configured to handle this amount of disk I/O. Disk Commands Issued The number of disk commands issued on this disk in the period. Disk IO per second IOPS = Disk Commands Issued / 20 Ensure that your SAN is configured to handle this amount of disk I/O. Stop Disk Command The number of disk commands aborted on this disk in the period. The disk command aborts when the disk array takes too long to respond to the command. (Command timeout). 0 Network Network Usage (Average) Network Usage = Data receive rate + Data transmit rate 30% of the available network bandwidth. Network Data Receive Rate The average rate at which data is received on this Ethernet port. 30% of the available network bandwidth. Network Data Transmit Rate The average rate at which data is transmitted on this Ethernet port. 30% of the available network bandwidth. ESXi Performance Monitoring The virtual machines must operate within the specified limits of the ESXi performance counters listed in the following table. The counters listed apply to all hosts that contain contact center components. Table 28: ESXi Performance Counters Category Counter Description Threshold CPU CPU Usage (Average) CPU Usage Average in percentage for ESXi Server overall and for each of the CPU processors. 60% CPU Usage in MHz (Average) CPU Usage Average in MHz for ESXi server overall and for each of the CPU processors. 60% of the available CPU clock cycles. 134

147 HCS for Contact Center ESXi Performance Monitoring Category Counter Description Threshold Memory Memory Usage (Average)* Memory Usage = Active / Granted * % Memory Used by VMKernel Memory Used by VMKernel 95 percentile is less than 80% of 2GB. Memory Balloon (Average) ESX use balloon driver to recover memory from less memory-intensive VMs so it can be used by those with larger active sets of memory. 0 SwapUsed ESX Server swap usage. Use the disk for RAM swap. 0 Disk Disk Commands Issued Number of disk commands issued on this disk in the period. Disk IO per second IOPS = Disk Commands Issued / 20 Disk Commands Aborts Number of disk commands aborted on this disk in the period. 0 Disk command aborts when the disk array is taking too long to respond to the command. (Command timeout). Disk Command Latency The average amount of time taken for a command from the perspective of a Guest OS. 20 msec. Disk Command Latency = Kernel Command Latency + Physical Device Command Latency. Kernel Disk Command Latency The average time spent in ESX Server VMKernel per command. Kernel Command Latency should be very small compared to the Physical Device Command Latency, and it should be close to zero. 135

148 Determine the Active Directory Deployment HCS for Contact Center Category Counter Description Threshold Network Network Usage (Average) Network Usage = Data receive rate + Data transmit rate 30% of the available network bandwidth. Network Data Receive Rate The average rate at which data is received on this Ethernet port. 30% of the available network bandwidth. Network Data Transmit Rate The average rate at which data is transmitted on this Ethernet port. 30% of the available network bandwidth. droppedtx Number of transmitting packets dropped. 0 droppedrx Number of receiving packets dropped. 0 * The CVP Virtual Machine exceeds the 80% memory usage threshold due to the Java Virtual Machine memory usage. Determine the Active Directory Deployment Procedure Step 1 Review AD at Customer Premises, on page 136. Step 2 Review AD at Service Provider Premises, on page 137. AD at Customer Premises In the AD at the customer premises model, the service provider needs to request that the customer add entries into the customer AD to enable the service provider to sign into the system deployed in the domain. The service provider should be a local machine administrator and belong to the setup group for components that need to be installed and managed in the Cisco HCS for Contact Center environment. To run the Domain Manager, the service provider must be a domain administrator or a domain user with domain read and write permissions to create Organizational Units (OU) and groups. The end-customer use of the Cisco HCS for Contact Center solution is limited if the customer premises AD is inaccessible to the Cisco HCS for Contact Center Virtual Machines. Cisco strongly advises service providers to work with end customers to ensure that they understand the potential service limitations when they use the AD at the customer premises model. Cisco HCS for Contact Center also supports a deployment where the Cisco HCS for Contact Center components are associated with the AD at the service provider premises, and the CTI OS client desktops are part of the customer premises corporate AD. Consider the following for the AD in this deployment: 136

149 HCS for Contact Center AD at Service Provider Premises The instance administrator account is created in the service provider domain. The instance administrator uses the Unified CCDM and Unified Intelligence Center to create agents, supervisors, and reporting users in the service provider domain. The instance administrator configures all supervisors and reporting users. AD at Service Provider Premises In the AD at the service provider premises model, the service provider must have a dedicated AD for each customer instance. Each customer AD needs to be updated with Cisco HCS for Contact Center servers and accounts. The service provider administrator needs to be added to each customer AD to manage the Contact Center environment. You can use overlapping IP addresses for each customer deployment. For example, Cisco Unified Border Element Enterprise, Unified CCE, and Unified CVP should be able to overlap IP addresses across customers. When you use overlapping IP addresses, the static Network Address Translation (NAT) provides access from the management system to each Cisco HCS for Contact Center environment. Determine the Blade and Storage Placement Requirements Before You Begin Review the section on storage and blade placement considerations in Installing and Configuring Cisco HCS for Contact Center at hosted-collaboration-solution-contact-center/products-installation-guides-list.html. Procedure Step 1 Step 2 Step 3 Review the storage and blade placement for Cisco HCS shared management components. Review the storage and blade placement for Cisco HCS core components. Review the storage and blade placement for Cisco HCS optional components. Determine High Availability Requirements Before You Begin Review the section on high availability considerations in Installing and Configuring Cisco HCS for Contact Center at hosted-collaboration-solution-contact-center/products-installation-guides-list.html. 137

150 Plan the Solution for Handling Congestion Control HCS for Contact Center Procedure Step 1 Step 2 Review the high availability considerations for Cisco HCS for Contact Center core components. Review the high availability considerations for Cisco HCS for Contact Center optional components. Plan the Solution for Handling Congestion Control Before You Begin Review the section on congestion control considerations in Installing and Configuring Cisco HCS for Contact Center at hosted-collaboration-solution-contact-center/products-installation-guides-list.html. Procedure Step 1 Step 2 Step 3 Determine the supported congestion control deployment types. Determine the congestion treatment mode options. Determine the congestion control levels and thresholds. Plan the UCS Networking Requirements Before You Begin Review the section on UCS network considerations in Installing and Configuring Cisco HCS for Contact Center at hosted-collaboration-solution-contact-center/products-installation-guides-list.html. Procedure Step 1 Step 2 Determine the deployment model. Determine the data center design. 138

151 HCS for Contact Center Determine the Trunk Design Determine the Trunk Design Procedure Step 1 In the data center, review the trunk design for the Cisco Unified Border Element Service Provider edition. In a Cisco HCS for Contact Center deployment, the Cisco Unified Border Element Service Provider edition connects to the Cisco Unified Border Element Enterprise edition. Step 2 Review the considerations for CUBE-Enterprise at Customer Premise, on page 139. Estimate the number of SIP sessions required in the CUBE-Enterprise. Go to the Ordering Tool at www-gsc.cisco.com/swc/cisco/ciscoadvisor.action?sfid=cisco&scflag=y. Step 3 Review the considerations for TDM Gateway at Customer Premise, on page 139. CUBE-Enterprise at Customer Premise Consider the following if you use the Cisco Unified Border Element - Enterprise at the customer premise: Cisco Unified Border Element - Enterprise gateway and the Cisco VXML gateway reside at the customer premise and calls are queued at the customer premise. The Cisco Unified Border Element - Enterprise and VXML gateway can be co-located on the same ISR, or located on different ISRs for cases where the number of IVR ports to agent ratio is small. Cisco Unified Border Element - Enterprise Integrated Services Router (ISR) provides the security, routing, and Digital Signal Processors (DSPs) for transcoders. Redundant Cisco Unified Border Element - Enterprise and Cisco VXML ISRs for failover and redundancy. WAN bandwidth must be sized appropriately for calls from CUBE(SP) to CUBE - Enterprise at the customer premise. Cisco Unified Border Element Enterprise supports flow-through mode. Flow-around mode is not supported. TDM Gateway at Customer Premise You can route PSTN calls using local gateway trunks if you prefer to keep your E1/T1 PSTN. Consider the following if you use the TDM gateway at the customer premise: Both the Cisco TDM gateway and the Cisco VXML gateway reside at the customer premise. PSTN delivery is at the local customer premise. The media stays local at the customer premise for the local PSTN breakout. The IVR call leg is deterministically routed to the local VXML gateway and only uses the centralized resources in spill-over scenarios. 139

152 Firewall Hardening Considerations HCS for Contact Center When media is delivered to a different site, Cisco Unified Communications Manager location-based call admission control limits the number of calls over the WAN link. Calls local to a customer premise use the G.711 codec. Calls going over the WAN link can use the G.729 codec to optimize the WAN bandwidth. ASR/TTS server for local breakout is at the customer premise and resides on a UCS or bare metal server. CUBE(E) can also be used as an alternative for both TDM gateway and VXML gateway. A new call for HCS for Contact Center must originate from the TDM gateway to anchor the call to the survivability service. The Contact Center dialed number to route the calls to Unified Communications Manager must be configured manually. Note You need to manually modify the call routing from TDM gateway for the session target to route the call directly to Unified CVP. Firewall Hardening Considerations This section describes the specific ports required, which should be allowed from the Contact Center and customer networks, but are restricted only to the ports required for the services that need to be exposed, as well as from specific hosts or networks wherever possible. For an inventory of the ports used across the Hosted Collaboration Solutions for Contact Center applications, see the following documentation: Port Utilization Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND). See section 'TCP/UDP ports used by Unified CVP, voice, and VoiceXML gateways in the Network infrastructure considerations chapter. Cisco Unified Intelligence Center TCP and UDP Port Usage Installation and Getting Started Guide for Cisco Finesse. See the 'Ports used for Cisco Finesse' section in the Frequently Asked Questions. See chapter Cisco Finesse port utilization section in the APPENDIX C. Cisco Unified Web and Interaction Manager Solution Reference Network Design Guide. See the 'Port Number Configuration Between Components' in the System Architecture chapter. Cisco Remote Silent Monitor Installation and Administration Guide. See the 'Port Numbers Used' section in the Installation chapter. Cisco Media Sense User Guide. See the 'Port Usage' section in the MediaSense Features and Services chapter. 140

153 CHAPTER 13 Backup and Restore Prerequisites, page 141 Backup and Restore Workflow, page 142 Determine Backup and Restore Requirements, page 142 Backup Strategy, page 144 Prerequisites Before you plan the backup and restore processes for your Cisco HCS installation, make sure that you: Review and have access to the Cisco Hosted Collaboration Solution, Release 10.6(1) Solution Reference Network Design Guide. Review and have access to the Cisco Hosted Collaboration Solution, Release 10.6(1) Maintain and Operate Guide. Complete the actions outlined in previous sections of this guide including: Initial system requirements and planned growth Data center requirements Service fulfilment requirements Service assurance requirements Customer specific dial plan Unified Communications Applications Mobility Video HCS for Contact Center 141

154 Backup and Restore Workflow Backup and Restore Backup and Restore Workflow Determine Backup and Restore Requirements Procedure Step 1 Step 2 Determine which backup and replication technologies you will use in your system. You may have the following options: Consolidated Backup, which is the least expensive option but with the slowest recovery time. High availability storage networks--a storage area network (SAN) can overcome local server failures by providing access to a standby or clustered server system to ensure continuous operation. Remote point-in-time update replication--point-in-time update replication copies the changes made to data in another building or city. The system can replicate changes at scheduled times during the day or whenever changes occur. With no latency limitations to overcome, this technology accommodates any distance requirements. It offers faster recovery times than tape backup, but it cannot guarantee zero data loss. Synchronous disk replication--suitable for applications that require the fastest recovery with zero data loss. This method synchronously copies all disk writes to a remote site across a high-performance network before a transaction is acknowledged, eliminating any transaction loss. This technology is sensitive to network latency, which limits the practical distance between sites. Asynchronous replication--offers significantly lower data loss than point-in-time update replication and reduces bandwidth costs compared to synchronous replication. Asynchronous replication allows the primary and remote copies to be out of synchronization by a range of seconds to minutes. Include these operational parameters in your planning: Backup frequency--depends on the frequency of changes in the network. Changes may include platform configurations or user data provisioning activities. Schedule additional backups before any major configuration and software updates. 142

155 Backup and Restore Determine Backup and Restore Requirements Disk space requirements--calculated by multiplying the frequency of backups and disk space requirements per backup by the number of backups the service provider maintains per UC cluster, as specified in the Service Level Agreement (SLA). Backup and restore duration--depends directly on the amount of disk space required for the backup or restore and the network bandwidth. Frequent backups and restores can adversely affect network traffic performance. Input/output operations per second (IOPS)--Used to determine backup demands on the system. The higher the IOPS, the faster that the backups are completed. Step 3 Step 4 Determine your FTP server usage. We recommend that you have a dedicated FTP server (or dedicated servers) per UC cluster. Schedule HCS component backups so that they do not overwhelm FTP server input/output operations per second (IOPS) capabilities and available bandwidth. Plan to use the Cisco Disaster Recovery System (DRS) for the Unified Communications applications. Be aware of the following when using DRS: Use DRS in coresident mode to back up and restore Unified Communications Manager and Cisco Unity Connection. In the current DRS release, IM and Presence Service servers must be backed up and restored separately. Each backup of a UC application is considered as one backup. DRS does not delete or overwrite phone images if DRS is used with upgrades, so disk space requirements will vary with each Unified Communications Manager upgrade. Consider scheduling backup and restoration tasks during off peak hours. Step 5 Plan to use Platform Manager in conjunction with DRS for these applications: Cisco Unified Communications Manager IM and Presence Service, Cisco Unified Communications Manager, Cisco Unity Connection, and Cisco Unified Contact Center. Be aware of the following when using DRS: When setting up server groups, all of the servers in a particular group must have the same product. For example, you cannot mix Cisco Unified Communications Manager and Cisco Unified Communications Manager IM and Presence Service nodes in the same server group. After you schedule backups on your servers and configure all of your servers and server groups within Platform Manager, you can manage and monitor backup tasks of your system using the Backup Schedule feature to perform DRS backups on groups of servers. Step 6 You may also use virtual machine (VM) backups. Full VM backups include both the binaries and configuration data, while DRS backs up only the configuration data of the application. For information on how to perform a full VM backup, refer tohttp:// VM backup options consist of the following: A crash-consistent backup includes an entire virtual machine while it is running, and there is no shutdown of the application for the backup. An application-consistent backup includes an entire virtual machine when the VM is powered off, or if the application can and does quiesce before the backup. A full VM backup is any backup done on a full virtual machine. It might be crash-consistent or application-consistent. 143

156 Backup Strategy Backup and Restore The VMware Data Recovery (VDR) feature backs up entire virtual machines, in other words, a full VM backup. Step 7 Step 8 Note Full VM backups are not a replacement for Cisco DRS and are not supported as backup of the application, only as a method to recover the VM quickly without having to deploy from ISO or Template. Customers must take DRS backups to protect and restore the configuration and data within the application. Consider these disk and time requirements for backups: Network and data center element backups require 1 to 10 kilobytes of disk space per device. Assuming appropriate bandwidth availability (10/100 Mbit/sec or higher), a network and data center element restore can take from 3 to 15 seconds. If using Micro Node deployment, plan for the following: Dedicate one or more C-series servers to host FTP servers, using the C-series server disk (local storage) for backup. Provide for offsite backup to address Data Center loss. You can back up multiple applications to the same FTP server, but do not store a backup on the same server (disk) that hosts the application or component itself. Backup Strategy You need to develop a Backup and Restore plan to match your implementation by reviewing the components in your implementation to identify the backup requirements and sequence for backups. Refer to the Cisco Hosted Collaboration Solution, Release 10.6(1) Maintain and Operate Guide to identify the components that are backed up occasionally and those that are backed up daily. Procedure Step 1 Group the components in your deployment under the following groups: Data Center Infrastructure Components Aggregation / Shared Component Elements Cisco HCS Service Fulfillment Cisco HCS Service Assurance Cisco UC Applications Endpoints SRST and Voice Gateways Components Cisco HCS for Contact Center Components Third Party Applications 144

157 Backup and Restore Backup Strategy The components in each group have similar backup requirements. Step 2 Step 3 Step 4 Review the component tables in the Cisco Hosted Collaboration Solution, Release 10.6(1) Maintain and Operate Guide to identify and record the backup requirements for the components in your installation. For components that require occasional backup, identify the backup mechanism you will use. For components that require frequent (daily) backup, identify the backup mechanism you will use. 145

158 Backup Strategy Backup and Restore 146