HCS Shared Architecture(SA)

HCS Shared Architecture(SA) Enabling A True Cloud Service with A Lower Cost Kai Xu, Kyle Baxter HCS Product Management and Partner Cloud Enablement Nov 15, 2016

Disclaimer The Cisco products, service or features identified in this document may not yet be available or may not be available in all areas and may be subject to change without notice. Consult your local Cisco business contact for information on the products or services available in your area. You can find additional information via Cisco s World Wide Web server at http://www.cisco.com. Actual performance and environmental costs of Cisco products will vary depending on individual customer configurations and conditions.

Key Challenges for HCS, specifically in SMB Compute, Storage & Footprint Costs Operational Costs Access Costs Under utilized dedicated VMs are too expensive for small customer sizes Starting cost is too high Customer on-boarding cost is significant Customer site deployment is too complicated Must make the process to deploy a customer easier MPLS between SP and customer sites is too expensive VPN solution requires CPE at customer site, and does not support mobility/jabber Internet is the preferred method for SMB connection instead of MPLS, VPN

Why HCS Shared Architecture (SA) HCS HCS SA Cost Ratio DC HW 60x B200 M4 100 VRF 3xB200 M4 1 VRF 20 to 1 Customer Onboarding About 2 weeks for each customer About 1 day for each customer 10 to 1 Site Deployment MPLS + device setup OTT + self service N to 1

Agenda HCS Shared Architecture Overview HCS Shared Architecture Other Component and Setup Configuration Steps Phone Registration Additional Links

HCS SA w/ Single Partner-Managed Domain - A True Cloud Collaboration Turnkey Solution HCS Partner Data Center Shared Architecture CUCM Cluster + Partitioned Unity Connection Customer A Customer B Customer C Internet Partner-Managed Domain/AD: ciscolabs.com Partner Cloud Collaboration Service for customers with 100 users or less Full suites of collaboration offers from dial tone, video, mobility to team collaboration. IT/Collaboration TURNKEY Solution: Using partner provided IT domain e.g. ciscolabs.com for collaboration. Partner managed domain will be shared by other SMB customers. Users/password managed within Partner AD. Internet access (OTT) access anywhere Service Provider to manage day to day operation and upgrade (as needed) as any cloud services Basic Voice Voice/Video Mobility Team Collaboration

HCS Shared Architecture Benefit for Partner HCS Shared Architecture (SA) w/ A Single Domain managed by Partner Shared CUCM Cluster and Partitioned Unity Connection Shared Expressway C & E Cluster HCS Management Own the service domain (asset) Have up-sell opportunity by offering other service associated with domain Create more stickiness of customers via domain attachment Maximize hardware utilization by sharing infrastructure (CUCM / CUCxn / IM&P and network/vrf) to reduce starting and on-going CAPEX cost on DC Minimize OPEX cost by reducing the number of application clusters and network/vrf to manage in DC and simplifying customer/user onboarding process Faster service delivery but with less cost by eliminating MPLS setup (months) No more overlapping IP address issue by registering all endpoints to HCS via OTT No more privacy and security concern by separating HCS network from customer network CUCDM 10 is tested and verified by Cisco Easy and simple provisioning and management. Enable automation for customer onboarding and MACD (later) Bring your own management tool (CUCDM 10 optional)

HCS Shared Architecture Benefit for Customer Faster Service Activation Lower Service Cost Mobility MRA for all users/devices More Privacy and Better Security No shared network Easy management Customer Admin and End User Self Care service Spark Service (free version) for all users

HCS Shared Architecture Management Components CUCDM 10 HCM-F PCA (optional) Web Proxy Mobile and Remote Access CUC IM & P CUCM AD Imagicle SIP Trunk(s) PSTN Expressway-C Expressway-E DMZ WAN All Endpoints access via OTT Single Partner Managed Domain (AD) Different OU s for customer separation Shared CUCM, Partitioned Unity PCA only works at cluster level Cust A Cust B

HCS Shared Architecture LDAP Considerations and User Management Partner hosted and managed LDAP server (AD) with one domain. LDAP server An Organization Unit(OU) is equivalent to a Customer in Shared Architecture. Partner to provide web portal (to AD) for user to change his/her password CUCM CUCM UserId must be unique in a Shared Architecture CUCM. Recommended UserId format: user1@ciscolabs.com User is synced to CUCDM per customer from AD (corresponding OU), and pushed to CUCM User authentication via LDAP IM&P Similar to CUCM CUC Similar to CUCM

HCS Shared Architecture Deployment Considerations Access Layer Expressway is used to eliminate need for MPLS and/or VPN setup All devices (phone and jabber) will be connected OTT via Expressway hence there is no issue about overlapping IP address Aggregation Layer/Trunk Set Up Support Shared trunk for customers on the same shared architecture cluster Also support separate trunk per customer HCS Management Fulfillment (CUCDM, HCM-F, etc) Supported Partner needs to setup a web proxy at DMZ for customer to access user self-care portal HCS Management Assurance (PCA) Only supported at Cluster Level

HCS Shared Architecture Dial Plan Considerations Short Code Dialing Supported Multiple locations per customer CUCM to Aggregation layer trunk Multiple country dial plan Emergency Calls Central Break Out External E164 calls Supported Support per customer trunk per customer to facilitate separate billing at trunk level Supported (additional setup maybe needed) Supported Emergency call is sent to aggregation/sp network with proper Location Emergency Published Number for CallingID Supported Supported Routing of the E164 dialing within same customer will be routed out to Aggregation layer instead of ringing the local phone directly.

HCS Shared Architecture Other Component and Setup Directory Search Services (as there is no customer separation on Shared CUCM) Utilise 3 rd party application - Imagicle XML Phone Services Utilise 3 rd party application - Imagicle CUCDM Customer Admin and User Self-Care Service via Internet Use Web Proxy at DMZ to access CUCDM Customer Admin coming in Phase 2 User Password Reset/Change (AD) Self-Service via Internet Setup Web interface to allow users to reset/change their AD password Note: Features/components not covered may still be accommodated, but are out of scope for this base architecture

High level configuration steps System Cluster Infrastructure Setup e.g. VRF AD Install & Configuration UC Cluster Install & Initial Setup Expressway Install and configuration Setup once per deployment Setup once per cluster deployment Customer CUCDM Customer Configuration AD Integration and Onboarding

System level configuration Infrastructure Setup e.g. VRF System AD Install and Configuration Networking(VRF) Create ONE Shared Customer Space VRF for all HCS Shared Architecture customers Configure the Network components accordingly - ASA, Nexus switches, etc. AD Install and Configuration Setup once per deployment Install AD in Shared Customer Space Configure AD to manage Partner-owned Service Domain: ciscolabs.com Setup DNS w Co-located AD CUCDM Configuration Setup an HCS SI Service Provider (entitlement, etc.) Detailed configurations steps are at- http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/hcs/10_6_1/hcs_solution/install_g uide/chcs_b_1061_installation_guide.pdf

Cluster level configuration steps UC Cluster Install & Initial Setup UC Cluster Install & Initial Setup Cluster Expressway Install and configuration Setup once per cluster deployment Setup self-provisioning configuration needed in CUCM Install Expressway Install Expressway C and E Expressway E Configure Traversal Server Configure the domain in TLS verify Subject name Expressway C Configure Traversal Client Add SIP domains(ciscolabs.com) and enable it for MRA Detailed installation steps are in the installation guide at- CUCDM Configuration Add UC Cluster under HCS SA Service Provider Setup Shared Trunk, if needed http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/hcs/10_6_1/hcs_solution/install_guide/chcs_ b_1061_installation_guide.pdf

Customer level configuration steps CUCDM Customer Configuration Provision Customer elements Customer AD Integration and Onboarding Configuration details of CUCDM is listed here- CUCDM Configuration Configure customer Configure Network Device List for customer Configure Dial plan for customer/site Add DN/E164 inventory & associations (trunk) Integrate AD (Customer OU) for customer Move the users to site(s) and pushed to CUCM Pre-Provision phones/soft clients for customers. http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/hcs/10_6_1/hcs_solution/dial_pla n/chcs_bk_dd3fd85c_00_dial-plan-for-cucdm-106x.html ASA Setup

Customer/Users Info Collection Customer/User Management in AD AD is hosted in Partner DC Configure AD with a different Organization Unit for each customer Configure AD Organization Units (OU) for customers Each OU represents a customer in Shared Architecture UserId format: user1@customer1.ciscolabs.com Actual user email might be different from UserId above Minimum User Info: Name Email UserId (managed by Partner) DN/Telephone Number ASA Setup

HCS Shared Architecture: Optimized for Lower Average Customer Size Shared Architecture per Cluster Capacity Users per Customer 20 50 100 250 Number of Customers per CUCM Cluster 1,000 OVA (C-Series) 2500 OVA (B-Series) 50 20 10 4 125 50 25 10 Maximum number of customers per CUCM cluster: 340 Cluster can be of any size (Ex: 10K user cluster will support 340 customers w/ average size of 30 user/customer)

Expressway Compute Platforms and Scalability Deployment vcpu Reserved RAM Disk Space NIC(s) Small 2 x 1.8 GHz 4GB 132GB 1Gb Virtual Machine(s) Medium 2 x 2.4 GHz 6GB 132GB 1Gb Large 8 x 3.3 GHz 8GB 132GB 10Gb Server Cluster Platform Proxied Registrations Video Calls Audio Only Calls Proxied Registrations Video Calls Audio Only Calls Large OVA 2,500 500 1,000 10,000 2,000 4,000 Medium OVA 2,500 150 300 10,000 600 1200 Small OVA (BE6K) 2,500 150 300 N/A N/A N/A Notes: HCS UC applications cannot be mixed with non-uc applications. Expressway No over subscription for any compute resources

Component HW/SW Versions Component Software End-Points CUCM Expressway-E/C CUCDM 10 HCM-F 10.5(2) SU3 or later X8.7.1 or later 10.6.3 SU1 or later 10.6.3 or later 7800 Series IP phones 8800 Series IP phones DX Series endpoints Jabber

Expressway and CUCM Sizing Average customer size shall determine the UC OVA size for Shared Architecture Cluster (limit of 340 customer/cluster) 20 user/customer -> 20 * 200 = 4000 total users We recommend to reserve 25% capacity for possible customer growth 4000 * 1.25 = 5000 -> 7.5k OVA shall be used for cluster We recommend to use medium OVA for Expressway Cluster, which supports 10k devices registration and 800 active sessions (call) Assume average of 2 devices per user 2 devices/user -> 10000 registration

Server and VM Configurations 4000 users 1 Pub, 1 TFTP,2 Sub UC manager Unified Presence Unity Connection 2 Nodes 1Pub,1 Sub Active-Active Expressway Imagicle AD Cluster(C&E) UC App suite 6 Exp C,6 Exp E 2 Nodes 1 node DNS 1 or 2 Nodes- Primary/Secondary Server Sizing 7.5K OVA Customer Limit-340 5K Ova 5K Ova Customer Limit-40 Medium OVA 10,000 registrations,1200 active calls 3xB200 M4 8 Cores 4 Cores 4 Cores 24 Cores 8 Cores (Co resident with AD/DNS) 8000 users 1 Pub/TFTP,3 Sub 4 nodes 1 Pub,2 Sub 12 Exp C,12 Exp E 2 Nodes 1 node 1 or 2 Nodes- Primary/Secondary Server Sizing 10K OVA 2x5K OVA 10K OVA 2 Medium OVA clusters,20,000,2400 active calls 7xB200M4 16 cores 8 cores 12 cores 48 Cores 8 Cores (Co resident with AD/DNS)

Phone Registration Process over Expressway Process 1. One time self-provisioning configuration needed in CUCM and CUCDM for line/device templates and dial plans Configure selfprovisioning and Expressway 2. Configure Expressway (one-time) 3. Add end users with associated line into CUCDM and then sync to CUCM 4. End user gets a phone and plugs it into network 5. End user enters server domain for Expressway-E and user ID and password provided by partner 6. Phone auto-registers 7. End user calls IVR number provided by partner and enters extension and PIN 8. Phone reboots and registers with end user s extension Enter server and credentials on phone Phone auto registers User runs self provisioning IVR Phone registers with actual user extension * Partner Steps * End User Steps

Jabber Registration Process over Expressway Process 1. One time configuration needed in CUCM/CUCIM&P and CUCDM to setup IM&P 2. Add end users with associated Jabber accounts into CUCDM and then make sure they are sync to CUCM/CUCIM&P 3. Configure Expressway C and E 4. End user installs Jabber on their desired machine (Apple, Android, Mac, Windows, etc.) 5. End user enters user ID with Expressway as domain for OTT (ex. user1@collabedge-161.dc-01.com) 6. End user enters password and clicks Sign In 7. Jabber registers! Configure CUCM/CUCMI M&P, CUCDM and Expressway Enter user ID on Jabber Enter password on Jabber Jabber registers * Partner Steps * End User Steps

Kurmi for HCS Shared Architecture AUTOMATING CUSTOMER ONBOARDING IS A KEY SUCCESS FACTOR OF SMB UCAAS SERVICE PROVIDERS: HANDLE HIGH USER VOLUMES WITHIN TIGHT DEADLINE WHILE STILL CONTROLING OPERATIONAL COSTS https://youtu.be/fszx2dhtxrm https://www.youtube.com/channel/ucplw8vmkj4s9vzcdyvueneg SELF-SERVICE ONBOARDING Your customers can deploy their UCaaS services by themselves from your portal or Kurmi UI, without intervention by your teams DEPLOYMENT WORKFLOW Define your deployment process based on your internal best practices: CUCM configuration (dial plan ), DNS configuration, services reboot FULL AUTOMATION Once configured, Kurmi automates your entire deployment process: setup configuration, site deployment and user provisioning

Customer Onboarding Automation Customer 1 Customer 2 Customer 3 Customer 4 Customer N. Customer & User Self- Onboarding using Service Provider Service Store Service provider Portal AND/OR Customer & User Self-onboarding using Kurmi GUI API Kurmi Portal Shared Architecture A D Shared Architecture Express-Way DNS Cisco HCS infrastructure and management stack Speedy Enterprise (Contact Segregation)

Imagicle ApplicationSuite for Cisco HCS SA Mandatory Contact segregation, plus Fax, ACD-IVR, Attendant Console (and more). www.imagicle.com Customer 1 UCaaS Platform CISCO HCS SHARED ARCHITECTURE Imagicle ApplicationSuite SHARED INSTANCE Customer 2 Customer 3 Contact segregation Contact segregation Contact segregation Fax ACD Operator IVR Fax ACD Fax Analytics One Suite The Imagicle AppSuite can offer multiple services to many customers with a single instance. Mandatory services Imagicle Directory Service, granting Contact Segregation, is mandatory to provide each customer the proper list of contacts, enabling also many desired advanced features. Recommended services As ATA/VG and Hunt groups/native Queueing are not supported in HCS SA (MRA), Imagicle Fax, ACD/IVR and Attendant Console are requested to provide must-have services. Optional Services The Imagicle AppSuite includes also Call Accounting and analytics, Phone lock, Call Recording and Hospitality Services. imagicle 28

Imagicle Speedy Enterprise for Cisco HCS shared architecture Cisco UCM in a HCS SA AXL/SOAP CURRI Imagicle AppSuite Speedy Enterprise Contact Segregation Local Directory for Cisco IP Phones Speedy can replace the Cisco Local Directory XML service to provide each customers the proper list of contacts. Local Directory for Cisco Jabber Speedy can behave as the UDS source for Cisco Jabber working in network or MRA and provide each customer the proper list of contacts. Customer 1 XML based IP Phone IP Phone searches for local contacts XML Return Customer 1 contacts only Users/external contacts sync with LDAP/CRM/ERP Imagicle Speedy can synchronize users directly from Cisco UCM or, optionally, from external sources CRM/ERP/LDAP XML based IP Phone Customer 2 Cisco Jabber Desktop/Mobile In network or MRA Jabber requests a local contact UDS Return Customer 2 contacts only Directory partitions Caller ID Speed dials www.imagicle.com imagicle

Additional Links OTT deployment chapter in SRND- http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/hcs/10_6_1/hcs_solution/srnd/chcs_bk_c 3D2E70C_00_cisco-hcs-srnd-10_6_hybrid/CHCS_BK_C3D2E70C_00_cisco-hcs-srnd- 10_6_hybrid_chapter_01100.html HCS documentation site- http://www.cisco.com/c/en/us/support/unified-communications/hosted-collaboration-solution-version- 10-6-1/model.html HCS Shared Architecture Whitepaper- http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/hcs/10_6_1/hcs_solution/hcs_sa_recom mended_deployment.pdf HCS Shared Architecture Demo- Admin steps: https://go.webex.com/go/lsr.php?rcid=1d5f90c3ec9e45638570cfb262be39f0 End user steps: https://go.webex.com/go/lsr.php?rcid=0763828ff48a410e8becde1092a1fce8

HCS Shared Architecture Limitations with MRA Multiple lines are not supported, only the primary line will ring Shared lines are supported in a limited way. Multiple endpoints can share a line but in-call features (like hold/resume) only work on the first endpoint that answers. Endpoints sharing the line may not correctly recognize the state of the call. No directory access mechanisms other than UDS Peer-to-peer file transfer when using IM and Presence Service and Jabber is unsupported via MRA Features that rely on the SIP UPDATE method will not work as expected Desk phone control (QBE,CTI) is not supported Hunt group/hunt pilot/hunt list will not work