Cisco Meeting Server Deployment Planning and Preparation Guide December 20, 2017 Cisco Systems, Inc. www.cisco.com
Contents 1 Introduction 5 1.1 Configuring the Meeting Server 7 1.2 Using Call Control 7 1.3 Technical specifications 7 2 Single combined server deployment 9 2.1 Overview 9 2.2 Prerequisites 10 2.2.1 VM host server 10 2.2.2 Syslog server to capture logs 10 2.2.3 NTP server for time sync 11 2.2.4 LDAP server for importing users 11 2.2.5 Customization asset server 11 2.2.6 Call Detail Record server 11 2.2.7 Licensing 11 2.2.8 Certificate requirements 11 2.2.9 Security 12 2.2.10 Port requirements 12 2.2.11 DNS requirements 12 2.2.12 Summary of servers required 12 3 Single split server deployment 14 3.1 Overview 14 3.2 Prerequisites 16 3.2.1 VM host server 16 3.2.2 Syslog server to capture logs 16 3.2.3 NTP server for time sync 16 3.2.4 LDAP server for importing users 16 3.2.5 Customization asset server 16 3.2.6 Call Detail Record server 17 3.2.7 Licensing 17 3.2.8 Certificate requirements 17 3.2.9 Security 18 3.2.10 Port requirements 18 3.2.11 DNS requirements 18 3.2.12 Summary of servers required 18 Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 2
3.2.13 API tool 19 4 Scalable and resilient server deployments 20 4.1 Overview 20 4.1.1 Call Bridge Clustering 22 4.1.2 Call Bridge Grouping 23 4.1.3 Database Clustering 23 4.1.4 XMPP resiliency 24 4.2 Prerequisites 24 4.2.1 VM host server 25 4.2.2 VM host for the database 25 4.2.3 Database 25 4.2.4 Syslog server to capture logs 25 4.2.5 NTP server for time sync 25 4.2.6 LDAP server for importing users 25 4.2.7 Customization asset server 25 4.2.8 Call Detail Record server 26 4.2.9 Licensing 26 4.2.10 Certificate requirements 26 4.2.11 Security 27 4.2.12 Port requirements 27 4.2.13 DNS requirements 27 4.2.14 Summary of servers required 27 4.2.15 API tool 28 Appendix A Cisco Licensing 29 A.1 Cisco Meeting Server Licensing and Activation Keys 29 A.1.1 Call Bridge Activation keys 29 A.1.2 Branding 30 A.1.3 Recording 31 A.1.4 XMPP licenses 31 A.2 Cisco User Licensing 31 A.2.1 Personal Multiparty Plus Licensing 31 A.2.2 Shared Multiparty Plus Licensing 32 A.2.3 Cisco Meeting Server Capacity Units 32 A.3 How Cisco Multiparty Licenses are assigned 32 Cisco Legal Information 34 Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 3
Cisco Trademark 35 Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 4
1 Introduction 1 Introduction The Cisco Meeting Server was formerly called the Acano Server. The Cisco Meeting Server software can be hosted on specific servers based on Cisco Unified Computing Server (UCS) technology as well as on the Acano X-Series hardware, or on a specification-based VM server. Cisco Meeting Server is referred to as the Meeting Server throughout this document. The term Meeting Server is used throughout this document as a generic term to refer to the UCS based servers, specification based VM hosts and Acano X-series servers. This guide will help you plan your Meeting Server deployment. For example it tells you which external prerequisites are required (e.g. NTP servers). It also lists the requirements for the components to work together (e.g. certificates) and references other documents that provide the detailed steps. The Meeting Server comprises a number of components which can be pick and mixed to adapt the solution to your video conferencing needs. For instance, the components can be hosted on a single server or split between a core server and an edge server for increased security. The flexibility of the Meeting Server architecture enables your deployment to expand as your video conferencing requirements grow; call capacity can be increased by adding Meeting Servers and clustered together for resiliency. For simplicity we have explained the multitude of possible deployments using three scenarios: single combined server deployments single split server deployments scalable and resilient deployments Chapters 2 to 4 of this guide provides an overview of each type of deployment and identifies the other network components required to deploy the Meeting Server. Figure 1 provides an overview of the documentation covering the Cisco Meeting Server. The guides are available on cisco.com, click on these links: Release notes Installation Guides Deployment Guides Configuration and Advanced Reference Guides Customization Guide Documentation covering the Cisco Meeting App can be found here. Cisco TelePresence Management Suite (TMS) version 15.4 onwards supports scheduling calls with Cisco Meeting Server. Scheduled meetings can be setup by each user in the organization using different methods to meet different customers needs, including: Microsoft Outlook with Exchange integration, Web based scheduling using Smart Scheduler, TMS admin interface for Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 5
1 Introduction help desk booking, and third party applications including Google calendar or Domino Notes. Refer to the Cisco TMS documentation for more details. Figure 1: Overview of guides covering the Cisco Systems Solution Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 6
1 Introduction 1.1 Configuring the Meeting Server There are two layers to the Cisco Meeting Server software: a Platform and an Application. The Platform is configured through the Mainboard Management Processor (MMP). The MMP is used for low level bootstrapping, and configuration via its command line interface. For example, the MMP is used to enable components. The Application runs on this managed platform with configuration interfaces of its own. The application level administration (call and media management) is done via either the Call Bridge s Web Admin Interface, or through the API. The Web Admin interface is suitable for configuring a single Call Bridge. To configure multiple Call Bridges you will need to use the API. Refer to the deployment guides for configuration details. The MMP and API guides are also useful reference material. 1.2 Using Call Control The Meeting Server can be used with Cisco Unified Communications Manager and other third party call control devices. The Cisco Meeting Server with Cisco Unified Communications Manager Deployment Guide details how to configure a SIP trunk between the Meeting Server and Cisco Unified Communications Manager. It explains how to set up scheduled, rendezvous and ad hoc calls between the two devices. The guide also covers ActiveControl on the Meeting Server (available from version 2.1). The Cisco white paper Load Balancing Calls across Cisco Meeting Servers discusses how to increase the scalability and resilience of Meeting Servers within a Cisco Unified Communications Manager deployment, using Call Bridge grouping to load balance calls across clustered Call Bridges. Load balancing aims to avoid overloading individual Meeting Servers in the cluster. The Cisco Meeting Server Deployments with Third Party Call Control guide provides examples of how to configure the Meeting Server to work with third party call control devices from Avaya and Polycom. 1.3 Technical specifications Video standards supported: H.263+ and H.263++ H.264 AVC (baseline and profile) H.264 SVC WebM, VP8 Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 7
1 Introduction Microsoft RTV SIP, H.323, TIP Audio standards supported: AAC-LD Speex Opus G.722, G.722.1, G.722.1c, G.728, G.729a, G.711a/u Resolution and frame rate supported: Up to 1080p at 60fps for main video and 1080p at 30fps for content Bandwidth consumed: Up to 6Mbps Call capacity: Table 1: Call capacity on supported servers Supported server HD calls (assuming 720p5 content, upto 2.5 Mbps bandwidth) SD calls (assuming 720p5 content, upto 2.5 Mbps bandwidth) Audio calls Cisco Meeting Server 1000 Cisco Meeting Server 2.x running on Multiparty Media 410v Cisco Meeting Server 2.x running on Multiparty Media 400 96 192 3000, this includes a maximum of 1000 escalated Ad Hoc calls (note 1) 64 128 2000 36 72 1000 Notes: 1) Assuming 3 participants (call legs) in an Ad Hoc call. If you create new call legs and destroy them very rapidly, you may find the maximum Ad Hoc calls reduces to 100. 2) Lync video calls into the Call Bridge consume the same resources as SIP calls. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 8
2 Single combined server deployment 2 Single combined server deployment 2.1 Overview Figure 2 shows schematically the components on a Meeting Server. Depending on your deployment you may find that not all of these components need to be enabled and configured. Figure 2: Components on a Meeting Server The components are: The Call Bridge and the database are always required within a deployment. The TURN server is required for media if you need NAT traversal. Alternatively you could use the TURN server in the Cisco Expressway X8.9. The XMPP server and Web Bridge are only required in the following circumstances: If you are using any of the Cisco Meeting Apps (Windows, OS X, or ios ) then you must install and configure the XMPP server. If you are using the Cisco Meeting App for WebRTC then you require the Web Bridge and the XMPP server. The H.323 Gateway is only required if you need to connect H.323 endpoints to the Meeting Server. Alternatively, you could use the Cisco VCS or Expressway to connect H.323 endpoints to calls on the.cisco Meeting Server The Recorder is only required if you intend to record meetings. Only enable the Recorder on the same server as the Call Bridge if you are simply evaluating the feature. For normal deployment enable the Recorder on a different server to the Call Bridge. The Recorder component on the Meeting Server adds the capability of recording meetings and saving the recordings to a document storage such as a network file system (NFS). The recommended deployment for production usage of the Recorder is to run it on a dedicated VM with a minimum of 4 physical cores and 4GB. In such a deployment, the Recorder should support 2 recordings per physical core, so a maximum of 8 simultaneous Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 9
2 Single combined server deployment recordings. Where possible it is recommended that the Recorder is deployed in the same physical locality as the target file system to ensure low latency and high network bandwidth. It is expected that the NFS is located within a secure network. The recorder uses variable bit rate, so it is not possible to accurately predict how much storage a recording will take. Our testing has shown that the size of 720p30 recordings ranges between 300MB to 800MB for 1 hour. In terms of budgeting it would be safe to assume 1GB per hour. The Streamer is only required if you intend to stream meetings (from version 2.1). Only enable the Streamer on the same server as the Call Bridge if you are simply evaluating the feature. For normal deployment enable the Streamer on a different server to the Call Bridge. The Streamer component adds the capability of streaming meetings held in a space to the URI configured on the space. An external streaming server needs to be configured to be listening on this URI. The external streaming server can then offer live streaming to users, or it can record the live stream for later playback. Note: Several standards based streaming servers are known to work with the Streamer, but Cisco only offers support for VBrick as an external streaming server. The recommended deployment for production usage of the Streamer is to run it on a separate VM. This VM should be sized with 1 vcpu and 1GB of memory per 6 concurrent streams, with a minimum of 4 vcpus and a maximum of 32vCPUs. Note: If you intend to deploy the Recorder and Streamer on the same Meeting Server, you will need to size the server appropriately for both uses. 2.2 Prerequisites The remainder of this chapter outlines the prerequisites for deploying the Meeting Server as a single combined server. For details on setting up the Meeting Server for this type of deployment, refer to the Cisco Meeting Server Single Combined Server Deployment Guide. 2.2.1 VM host server If you are using a VM host it must comply with the host server requirements provided in the Installation Guides for Cisco Meeting Server 2.x Virtualized Deployments. Sizing guidelines are also provided in the document. 2.2.2 Syslog server to capture logs The Syslog is recommended for troubleshooting and audit logging. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 10
2 Single combined server deployment 2.2.3 NTP server for time sync You must configure at least one NTP server to synchronize time between the Meeting Server components. 2.2.4 LDAP server for importing users If you intend to use any of the Cisco Meeting Apps you must have an LDAP server (currently Active Directory or OpenLDAP). User accounts are imported from the LDAP server. You can create user names by importing fields from LDAP. 2.2.5 Customization asset server If you are customizing your Meeting Server deployment, you need a web server that is reachable by the Call Bridge without performing any form of HTTP authentication. See the Cisco Meeting Server Customization Guidelines for details. 2.2.6 Call Detail Record server The Meeting Server generates Call Detail Records (CDRs) internally for key call-related events. The Meeting Server can be configured to send these records to a remote system to be collected and analyzed: there is no provision for records to be stored on a long-term basis on an Meeting Server. See the Cisco Meeting Server Call Detail Records guide for details. 2.2.7 Licensing You will need activation keys or licences to use these components on the Meeting Server: Call Bridge Recording Streaming (from version 2.1) You will also need a branding license if you wish to rebrand the voice prompts and invitation text. The XMPP license activation key is now included in the Cisco Meeting Server software. In addition to the licences mentioned above, you will also need to purchase Cisco User Licensing. Refer to Section A.2. 2.2.8 Certificate requirements Certificates and a certificate bundle (or intermediate certificate chain if automatically downloaded from the internet) are required for the: Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 11
2 Single combined server deployment Call Bridge (If you are using Lync, this certificate will need to be trusted by the Lync Front End Server; the best way to achieve this is to sign the certificate on the CA (Certification Authority) server that has issued the certificates for the Lync Front End Server) Web Bridge XMPP server Web Admin Interface TURN server (if using TLS connections) Recorder Streamer For more information on the use of certificates, see the Certificate Guidelines for a single combined server deployment. 2.2.9 Security If security is paramount, then consider the following: User access control Common Access Cards (CAC) Online Certificate Status Protocol (OCSP) FIPS TLS certificate validation with MMP commands DSCP Details are provided in the Deployment guides. 2.2.10 Port requirements Appendix B of the Deployment guides shows the required ports between each component of the Meeting Server, and between them and external components. 2.2.11 DNS requirements You will require a DNS server in your Meeting Server deployment. Verify that no A or SRV records already exist for any host Meeting Server before defining the DNS records on this server. Refer to Appendix A in the deployment guides for a table of DNS records needed for the deployment. 2.2.12 Summary of servers required In addition to the Cisco Meeting Server, you will need: Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 12
2 Single combined server deployment 1 Meeting Server (either hosted on a specified UCS server or a specified VM host or an Acano X series server). Note: you will need an additional Cisco Meeting Server if you intend to deploy the Recorder or Streamer. 1 Syslog server 1 NTP server 1 LDAP server (if using Cisco Meeting Apps) 1 DNS server 1 CDR receiver if you intend to send CDR records to a remote system for collection and analysis (optional) 1 web server for customization assets (optional) 1 Network File Server (NFS) if you are using the Recorder Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 13
3 Single split server deployment 3 Single split server deployment 3.1 Overview Figure 3 shows schematically the Meeting Server components when they are split between a Core and an Edge server. The Edge server will typically sit in the DMZ and interface to the internet, while the Core server is in an enterprise s core network, with a firewall separating the core server and edge server. Depending on your deployment you may find that not all of these components need to be enabled and configured. Figure 3: Components split between the Core server and the Edge server The components are: The Call Bridge and the database are always required within a deployment. The TURN server is required for media if you need NAT traversal. Alternatively you could use the TURN server in the Cisco Expressway X8.9. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 14
3 Single split server deployment The XMPP server, Load Balancer and Web Bridge are only required in the following circumstances: If you are using any of the Cisco Meeting Apps (Windows, OS X, or ios ) then you must install and configure the XMPP server and Load Balancer. If you are using the Cisco Meeting App for WebRTC then you require the Web Bridge, XMPP server and the Load Balancer. The H.323 Gateway is only required if you need to connect H.323 endpoints to the Meeting Server. Alternatively, you could use the Cisco VCS or Expressway to connect H.323 endpoints to calls on the Cisco Meeting Server The Recorder is only required if you intend to record meetings. Only enable the Recorder on the same server as the Call Bridge if you are simply evaluating the feature. For normal deployment enable the Recorder on a different server to the Call Bridge. The Recorder component on the Meeting Server adds the capability of recording meetings and saving the recordings to a document storage such as a network file system (NFS). The recommended deployment for production usage of the Recorder is to run it on a dedicated VM with a minimum of 4 physical cores and 4GB. In such a deployment, the Recorder should support 2 recordings per physical core, so a maximum of 8 simultaneous recordings. Where possible it is recommended that the Recorder is deployed in the same physical locality as the target file system to ensure low latency and high network bandwidth. It is expected that the NFS is located within a secure network. The recorder uses variable bit rate, so it is not possible to accurately predict how much storage a recording will take. Our testing has shown that the size of 720p30 recordings ranges between 300MB to 800MB for 1 hour. In terms of budgeting it would be safe to assume 1GB per hour. The Streamer is only required if you intend to stream meetings (from version 2.1). Only enable the Streamer on the same server as the Call Bridge if you are simply evaluating the feature. For normal deployment enable the Streamer on a different server to the Call Bridge. The Streamer component adds the capability of streaming meetings held in a space to the URI configured on the space. An external streaming server needs to be configured to be listening on this URI. The external streaming server can then offer live streaming to users, or it can record the live stream for later playback. Note: Several standards based streaming servers are known to work with the Streamer, but Cisco only offers support for VBrick as an external streaming server. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 15
3 Single split server deployment The recommended deployment for production usage of the Streamer is to run it on a separate VM. This VM should be sized with 1 vcpu and 1GB of memory per 6 concurrent streams, with a minimum of 4 vcpus and a maximum of 32vCPUs. Note: If you intend to deploy the Recorder and Streamer on the same Meeting Server, you will need to size the server appropriately for both uses. 3.2 Prerequisites The remainder of this chapter outlines the prerequisites for deploying the Meeting Server as a single split server. For details on setting up the Meeting Server for this type of deployment, refer to the Cisco Meeting Server Single Split Server Deployment Guide. 3.2.1 VM host server If you are using a VM host it must comply with the host server requirements provided in the Installation Guides for Cisco Meeting Server 2.x Virtualized Deployments. Sizing guidelines are also provided in the document. 3.2.2 Syslog server to capture logs The Syslog is recommended for troubleshooting and audit logging. Although it is possible to use more than one Syslog server, if you are using a split deployment, then all host servers must use the same one. 3.2.3 NTP server for time sync You must configure at least one NTP server to synchronize time between the Meeting Server components. Note: Using more than one NTP server is recommended. Both the Core server and the Edge server must be set up separately to use the NTP servers. 3.2.4 LDAP server for importing users If you intend to use any of the Cisco Meeting Apps you must have an LDAP server (currently Active Directory or OpenLDAP). User accounts are imported from the LDAP server. You can create user names by importing fields from LDAP. 3.2.5 Customization asset server If you are customizing your Meeting Server deployment, you need a web server that is reachable by the Call Bridge without performing any form of HTTP authentication. See the Cisco Meeting Server Customization Guidelines for details. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 16
3 Single split server deployment 3.2.6 Call Detail Record server The Meeting Server generates Call Detail Records (CDRs) internally for key call-related events. The Meeting Server can be configured to send these records to a remote system to be collected and analyzed: there is no provision for records to be stored on a long-term basis on an Meeting Server. See the Cisco Meeting Server Call Detail Records guide for details. 3.2.7 Licensing You will need activation keys or licences to use these components on the Meeting Server: Call Bridge Recording Streaming (from version 2.1) You will also need a branding license if you wish to rebrand the voice prompts and invitation text. The XMPP license activation key is now included in the Cisco Meeting Server software. In addition to the licences mentioned above, you will also need to purchase Cisco User Licensing. Refer to Section A.2. 3.2.8 Certificate requirements Certificates and a certificate bundle (or intermediate certificate chain if automatically downloaded from the internet) are required for the: Call Bridge (If you are using Lync, this certificate will need to be trusted by the Lync Front End Server; the best way to achieve this is to sign the certificate on the CA (Certification Authority) server that has issued the certificates for the Lync Front End Server) Web Bridge XMPP server Web Admin Interface database host server TURN server (if using TLS connections) trunks between Core and Edge servers Recorder Streamer (from version 2.1) Note: It is possible to use the same certificate across multiple Edge servers but Cisco does NOT recommend it. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 17
3 Single split server deployment For more information on the use of certificates, see the Certificate Guidelines for a single split server deployment. 3.2.9 Security If security is paramount, then consider the following: User access control Common Access Cards (CAC) Online Certificate Status Protocol (OCSP) FIPS TLS certificate validation with MMP commands DSCP Details are provided in the Deployment guides. 3.2.10 Port requirements Appendix B of the Deployment guides shows the required ports between each component of the Meeting Server, and between them and external components. 3.2.11 DNS requirements You will require a DNS server in your Meeting Server deployment. Verify that no A or SRV records already exist for any host Meeting Server before defining the DNS records on this server. Refer to Appendix A in the deployment guides for a table of DNS records needed for the deployment. 3.2.12 Summary of servers required 2 Meeting Servers (either hosted on specified UCS servers or specified VM hosts or Acano X series servers or a mix). Note: you will need an additional Cisco Meeting Server if you intend to deploy the Recorder or Streamer. 1 Syslog server 1 or 2 NTP servers 1 LDAP server (if using Cisco Meeting Apps) 1 or more CDR receivers (maximum of 4) if you intend to send CDR records to remote systems for collection and analysis (optional) 1 web server for customization assets (optional) Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 18
3 Single split server deployment 1 DNS server 1 Network File Server (NFS) if you are using the Recorder 3.2.13 API tool If your deployment has more that one Meeting Server we strongly recommend using the API to configure them, rather than the Web Admin interface. You will need a web API tool, such as POSTMAN, and a login account and password for the Meeting Server API. The API login password is set up using the MMP command user add <username> api. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 19
4 Scalable and resilient server deployments 4 Scalable and resilient server deployments 4.1 Overview Scalable and resilient deployments can be based on combined servers or on split Core and Edge servers as shown in Figure 4, or a mix of the two. Depending on your deployment you may find that not all of the components need to be enabled and configured on all of the Meeting Servers. Typically, specified UCS servers hosting the software or X-Series servers are used for the Core servers and VM hosts for the Edge servers; but this is not mandatory. Note that databases can be co-located with the Call Bridge or on a separate host server usually also a VM. Figure 4: Scalable and resilient deployment can use a mix of combined servers and split Core and Edge servers The components are: The Call Bridge and the database are always required within a deployment. The TURN server is required for media if you need NAT traversal. Alternatively you could use the TURN server in the Cisco Expressway X8.9. The XMPP server, Load Balancer and Web Bridge are only required in the following circumstances: If you are using any of the Cisco Meeting Apps (Windows, OS X, or ios ) then you must install and configure the XMPP server and Load Balancer. If you are using the Cisco Meeting App for WebRTC then you require the Web Bridge, XMPP server and the Load Balancer. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 20
4 Scalable and resilient server deployments CAUTION: The maximum number of concurrent XMPP clients supported by the current Meeting Server software is 500.This maximum is a total number of all different clients (Cisco Meeting App, WebRTC Sign-in and WebRTC Guest clients) registered at the same time to clustered Meeting Servers. If the number of concurrent XMPP registrations exceeds 500 sessions, some unexpected problems with sign in may occur or it may lead to a situation where all currently registered users need to re-sign in, this can cause a denial of service when all users try to sign in at the same time. The H.323 Gateway is only required if you need to connect H.323 endpoints to the Meeting Server. Alternatively, you could use the Cisco VCS or Expressway to connect H.323 endpoints to calls on the Cisco Meeting Server The Recorder is only required if you intend to record meetings. Only enable the Recorder on the same server as the Call Bridge if you are simply evaluating the feature. For normal deployment enable the Recorder on a different server to the Call Bridge. The Recorder component on the Meeting Server adds the capability of recording meetings and saving the recordings to a document storage such as a network file system (NFS). The recommended deployment for production usage of the Recorder is to run it on a dedicated VM with a minimum of 4 physical cores and 4GB. In such a deployment, the Recorder should support 2 recordings per physical core, so a maximum of 8 simultaneous recordings. Where possible it is recommended that the Recorder is deployed in the same physical locality as the target file system to ensure low latency and high network bandwidth. It is expected that the NFS is located within a secure network. The recorder uses variable bit rate, so it is not possible to accurately predict how much storage a recording will take. Our testing has shown that the size of 720p30 recordings ranges between 300MB to 800MB for 1 hour. In terms of budgeting it would be safe to assume 1GB per hour. The Streamer is only required if you intend to stream meetings (from version 2.1). Only enable the Streamer on the same server as the Call Bridge if you are simply evaluating the feature. For normal deployment enable the Streamer on a different server to the Call Bridge. The Streamer component adds the capability of streaming meetings held in a space to the URI configured on the space. An external streaming server needs to be configured to be listening on this URI. The external streaming server can then offer live streaming to users, or it can record the live stream for later playback. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 21
4 Scalable and resilient server deployments Note: Several standards based streaming servers are known to work with the Streamer, but Cisco only offers support for VBrick as an external streaming server. The recommended deployment for production usage of the Streamer is to run it on a separate VM. This VM should be sized with 1 vcpu and 1GB of memory per 6 concurrent streams, with a minimum of 4 vcpus and a maximum of 32vCPUs. Note: If you intend to deploy the Recorder and Streamer on the same Meeting Server, you will need to size the server appropriately for both uses. In a scalable and resilient deployment with several Core servers: it is not necessary, or even desirable, to have the same number of Edge and Core servers. For example, one Call Bridge can manage multiple Web Bridges; those Web Bridges can be reachable externally with a single DNS name resolving to potentially multiple separate units. it is not necessary to have a database instance for every Call Bridge; rather we recommend one at every point of presence. Scalability and resilience is provided by simply adding more instances of the Meeting Server to your deployment. Features that support the scaling of deployments include: Call Bridge clustering Call Bridge grouping Features that support resiliency in multi-server deployments include: Database clustering XMPP resiliency Note: If your deployment design uses more than 8 servers running Meeting Server software, irrespective of which components are running on those servers, contact your Cisco sales representative to have the design validated. 4.1.1 Call Bridge Clustering Within a scalable and resilient Meeting Server deployment, you can enable Call Bridge clustering which will allow multiple Call Bridges to operate as a single entity and scale beyond the capacity of any single Call Bridge. Note: Cisco recommends a maximum of 8 Call Bridges in a single cluster. You have a choice whether to setup the Call Bridges in the cluster to link peer-to-peer, or for calls to route via call control devices between the clustered Call Bridges. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 22
4 Scalable and resilient server deployments Linking Call Bridges peer-to-peer: reduces call complexity as the call will go from Call Bridge A to Call Bridge B directly, with nothing in the middle to interfere with the routing of the call. reduces load on the call control device, and frees up resources to handle calls that need to route through the call control device. This may be important if the call control device is licensed on a per call basis. Routing via call control device(s): creates a consistent call flow for your Meeting Server and Local SIP devices. This can make network configuration a little simpler, particularly if there are firewalls between networks with fixed allow rules which only allow calls routed through call control devices. For more information on how calls are routed in deployments with clustered Call Bridges, refer to the Cisco Meeting Server Scalability and Resilience Deployment Guide. Note: Clustered Call Bridges cannot use the same database (or database cluster) as a nonclustered Call Bridge 4.1.2 Call Bridge Grouping Deployments with Cisco Unified Communications Manager and clustered Meeting Servers can use the Call Bridge Grouping feature in version 2.1 to load balance calls on the Meeting Servers. Load balancing aims to avoid overloading individual Meeting Servers in the cluster. Using Call Bridge groups, a Meeting Server cluster can intelligently load balance calls across the Call Bridges within the same location or across nodes in different locations. The intelligent decision making behind where calls end up, is handled by the Meeting Servers. The call control system needs to be able to handle SIP messages from the Meeting Servers, in order to move calls to the correct location. This functionality has been tested using Cisco Unified Communications Manager as a call control system, which is the only Cisco supported call control system for this functionality. The Cisco VCS is not currently supported since it doesn t include support for INVITE with Replaces. For more information on load balancing calls, see the Cisco white paper Load Balancing Calls Across Cisco Meeting Servers. 4.1.3 Database Clustering Database clustering works differently to Call Bridge clusters. A database cluster creates what is essentially an 'online' backup of the running database which is maintained as the system runs. It also provides the ability to move to using the backup in an automated fashion in the event of a failure being detected. Within a database cluster, only one database is used at any time by all the Call Bridges; this is the master. All reads and writes are performed on this database instance. This master database s Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 23
4 Scalable and resilient server deployments contents are replicated to the slaves/hot-standbys for resilience. In case of master failure, a slave database will be "promoted" to being the new master, and other slaves will reregister with the new master database. After the failure has been corrected, the old master will assign itself as a slave and will also register with the new master. Database clustering does not do any kind of load balancing, caching, nor sharding of data for more efficient local access within any kind of geographically distributed arrangement. All queries are directed at the current master, where ever it is. The replicas are not available as read-only instances. Note: Do not create a database cluster of 2 nodes, as it reduces resiliency rather than increase it. Using an odd number of nodes aids resiliency in the case of network partitions, and Cisco recommends running at least 3 database nodes. There is currently a limit of 5 database nodes in a cluster. For more information on database clustering see the Scalability and Resilience Deployment Guide. 4.1.4 XMPP resiliency XMPP resiliency provides fail-over protection for a client being unable to reach a specific XMPP server. XMPP resiliency can be configured in multi-server deployments where there are at least three XMPP servers in the deployment. When setup in resilient mode, the XMPP servers within a deployment are loaded with the same configuration. Each knows the location of the others and they establish links between them. They use keep-alive messages to monitor each other and elect a master. XMPP messages can be sent to any server, messages will be forwarded to the master XMPP server. The XMPP servers continue to monitor each other, if the master fails then a new master is elected and the other XMPP servers forward traffic to the new master. Note: Deployments with only two XMPP servers will not benefit from resiliency, and if one fails it will cause an outage, effectively doubling the risk of failure versus stand-alone mode. This is due to the failover algorithm requiring more than half of the nodes to be available in order for the system to make good decisions about which XMPP server is the master. 4.2 Prerequisites The remainder of this chapter outlines the prerequisites for deploying Meeting Servers using a scalable and resilient deployment approach. For details on setting up the Meeting Server for scalability and resilience refer to the Cisco Meeting Server Scalability and Resilience Deployment Guide. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 24
4 Scalable and resilient server deployments 4.2.1 VM host server If you are using a VM host it must comply with the host server requirements provided in the Installation Guides for Cisco Meeting Server 2.x Virtualized Deployments. Sizing guidelines are also provided in the document. 4.2.2 VM host for the database Each database which holds the spaces can be co-located with other components on a Core server, but it can also be an external database, for example as a VM host. 4.2.3 Database A minimum of 3 databases is required. In a large deployment with several combined or Core servers, it is not necessary to have a database instance for every Call Bridge; rather we recommend one at every point of presence. 4.2.4 Syslog server to capture logs The Syslog is recommended for troubleshooting and audit logging. Although it is possible to use more than one Syslog server, if you are using split deployments or clustering, all host servers must use the same one. 4.2.5 NTP server for time sync You must configure at least one NTP server to synchronize time between the Meeting Server components. Note: Using more than one NTP server is recommended. Every host server must be set up separately to use an NTP server. 4.2.6 LDAP server for importing users If you intend to use any of the Cisco Meeting Apps you must have an LDAP server (currently Active Directory or OpenLDAP). User accounts are imported from the LDAP server. You can create user names by importing fields from LDAP. 4.2.7 Customization asset server If you are customizing your Meeting Server deployment, you need a web server that is reachable by the Call Bridge without performing any form of HTTP authentication. See the Cisco Meeting Server Customization Guidelines for details. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 25
4 Scalable and resilient server deployments 4.2.8 Call Detail Record server The Meeting Server generates Call Detail Records (CDRs) internally for key call-related events. The Meeting Server can be configured to send these records to a remote system to be collected and analyzed: there is no provision for records to be stored on a long-term basis on an Meeting Server. See the Cisco Meeting Server Call Detail Records guide for details. 4.2.9 Licensing You will need activation keys or licences to use these components on the Meeting Server: Call Bridge Recording Streaming (from version 2.1) You will also need a branding license if you wish to rebrand the voice prompts and invitation text. The XMPP license activation key is now included in the Cisco Meeting Server software. In addition to the licences mentioned above, you will also need to purchase Cisco User Licensing. Refer to Section A.2. 4.2.10 Certificate requirements Certificates and a certificate bundle (or intermediate certificate chain if automatically downloaded from the internet) are required for the: Call Bridge (If you are using Lync, this certificate will need to be trusted by the Lync Front End Server; the best way to achieve this is to sign the certificate on the CA (Certification Authority) server that has issued the certificates for the Lync Front End Server) Web Bridge XMPP server Web Admin Interface database host server TURN server (if using TLS connections) trunks between Core and Edge servers Recorder Streamer (from version 2.1) Note: It is possible to use the same certificate across multiple Edge servers but Cisco does NOT recommend it. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 26
4 Scalable and resilient server deployments 4.2.11 Security If security is paramount, then consider the following: User access control Common Access Cards (CAC) Online Certificate Status Protocol (OCSP) FIPS TLS certificate validation with MMP commands DSCP Details are provided in the Deployment guides. 4.2.12 Port requirements Appendix B of the Deployment guides shows the required ports between each component of the Meeting Server, and between them and external components. 4.2.13 DNS requirements You will require a DNS server in your Meeting Server deployment. Verify that no A or SRV records already exist for any host Meeting Server before defining the DNS records on this server. Refer to Appendix A in the deployment guides for a table of DNS records needed for the deployment. 4.2.14 Summary of servers required 2 Meeting Servers Meeting Server (either hosted on specified UCS servers or specified VM hosts or Acano X series servers). Note: you will need an additional Cisco Meeting Server if you intend to deploy the Recorder or Streamer. 1 Syslog server 1 or 2 NTP servers 1 LDAP server (if using Cisco Meeting Apps) 1 or more CDR receivers (maximum of 4) if you intend to send CDR records to remote systems for collection and analysis (optional) 1 web server for customization assets (optional) 1 DNS server 1 Network File Server (NFS) if you are using the Recorder Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 27
4 Scalable and resilient server deployments 4.2.15 API tool If your deployment has more that one Meeting Server we strongly recommend using the API to configure them, rather than the Web Admin interface. You will need a web API tool, such as POSTMAN, and a login account and password for the Meeting Server API. The API login password is set up using the MMP command user add <username> api. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 28
Appendix A Cisco Licensing Appendix A Cisco Licensing You will need activation keys and licenses for the Cisco Meeting Server and Cisco user licenses. For information on purchasing and assigning Cisco licenses, see the Cisco Meeting Server deployment guides. A.1 Cisco Meeting Server Licensing and Activation Keys The following activation keys or licenses are required to use the Cisco Meeting Server: Call Bridge Branding Recording Streaming XMPP license activation key, this is now included in the software For customers new to the Meeting Server the four areas are explained in the sections below. For Acano Server customers there are four changes to note: the XMPP license is now included in the software. you need to have the Call Bridge activated to create any calls, if you require demo licenses to evaluate the product then contact your Cisco partner. if you are deploying a cluster of Call Bridges then you require a license file for each Call Bridge in the cluster. If you already have a single activation key covering the multiple MAC addresses of the Call Bridges in the cluster, then you can continue to use the key. However, it is no longer possible to purchase a single key covering multiple MAC addresses. you will need to change the name of each newly purchased Cisco license file to cms.lic A.1.1 Call Bridge Activation keys The activation key allows the Call Bridge to be used for media calls. Activation keys need to be installed on: the Cisco Meeting Server 1000, VM servers with Cisco Meeting Server software installed and configured as a combined server deployment (all components are on the same server), VM servers with Cisco Meeting Server software installed and configured as a Core server in a split server deployment. You need to have the Call Bridge activated to create any calls, if you require demo licenses to evaluate the product then contact your Cisco sales representative. Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 29
Appendix A Cisco Licensing Acano X-Series Servers do not require an activation key. VMs configured as Edge servers do not require an activation key for the Call Bridge. Note: If you are deploying a cluster of Call Bridges you require a license file for each Call Bridge in the cluster. When you purchase license files you will be asked for the MAC address of each server hosting a Call Bridge which requires activation. This is the MAC address of interface A of your VM, not the MAC address of the server platform that the VM is installed on. The name of the license file will have the MAC address within it, so that you can identify the appropriate license file to load on a server. Before uploading the license file rename it as cms.lic To apply the license after uploading the license file, you need to restart the Call Bridge. However, you must configure the Call Bridge certificates and a port on which the Call Bridge listens before you can do this. These steps are part of the Cisco Meeting Server configuration and described in the Cisco Meeting Server deployment guides. The banner This CMS is running in evaluation mode; no calls will be possible until it is licensed. is displayed in the Web Admin interface until a valid cms.lic file is uploaded. After you upload the license file, the banner is removed. A.1.2 Branding Customization is controlled by license keys with different keys providing different levels of customization. The levels of customization supported are: No key: control of the background image and logo on the WebRTC landing page of a single Web Bridge via the Web Admin Interface; no API configuration is allowed. Single brand via API: only a single set of resources can be specified (1 WebRTC page, 1 set of voice prompts etc). These resources are used for all spaces, IVRs and Web Bridges. Multiple brand via API: different resources can be used for different spaces, IVRs and Web Bridges. These resources can be assigned at the system, tenant or space/ivr level. To purchase branding license keys, you will need the following information: Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 30
Appendix A Cisco Licensing level of branding required (single/multiple), MAC address of interface A on servers hosting the Call Bridge. A.1.3 Recording Recording is controlled by license keys, where one license allows one simultaneous recording. The license is applied to the server hosting the Call Bridge (core server) which connects to the Recorder, not the server hosting the Recorder. Note: The recommended deployment for production usage of the Recorder is to run it on a dedicated VM with a minimum of 4 physical cores and 4GB. In such a deployment, the Recorder should support 2 simultaneous recordings per physical core, so a maximum of 8 simultaneous recordings. To purchase recording license keys, you will need the following information: number of simultaneous recordings, MAC address of interface A on the servers hosting the Call Bridges. A.1.4 XMPP licenses Customers who are using Cisco Meeting Apps require an XMPP license installed on the server(s) running the XMPP server application. The XMPP license is included in the Cisco Meeting Server software. You will also need a Call Bridge activated on the same Cisco Meeting Server as the XMPP server. A.2 Cisco User Licensing Cisco Multiparty licensing is the primary licensing model used for Cisco Meeting Server; Acano Capacity Units (ACUs) can still be purchased, but cannot be used on the same Call Bridge as Multiparty licenses. Contact your Cisco sales representative if you need to migrate ACUs to Multiparty licenses. Multiparty licensing is available in two variations: Personal Multiparty Plus (PMP Plus) licensing, which offers a named host license, and Shared Multiparty Plus (SMP Plus) licensing, which offers a shared host license. Both Personal Multiparty Plus and Shared Multiparty Plus licenses can be used on the same server. A.2.1 Personal Multiparty Plus Licensing Personal Multiparty Plus (PMP Plus) provides a named host license assigned to each specific user who frequently hosts video meetings. This can be purchased through Cisco UWL Meeting (which includes PMP Plus). Personal Multiparty Plus is an all-in-one licensing offer for video conferencing. It allows users to host conferences of any size (within the limits of the Cisco Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 31
Appendix A Cisco Licensing Meeting Server hardware deployed). Anyone can join a meeting from any endpoint, and the license supports up to full HD 1080p60 quality video, audio, and content sharing. Note: Prior to release 2.1, Ad Hoc conferences never consumed PMP+ licenses. From 2.1 the initiator of the Ad Hoc conference can be identified and if they have been assigned a PMP+ license then that is used for the conference. A.2.2 Shared Multiparty Plus Licensing Shared Multiparty Plus (SMP Plus) provides a concurrent license that is shared by multiple users who host video meetings infrequently. It can be purchased at a reduced price with a UCM TP Room Registration license included when purchasing room endpoints, or it can be purchased separately. Shared Multiparty Plus enables all employees who do not have Cisco UWL Meeting licenses to access video conferencing. It is ideal for customers that have room systems deployed that are shared among many employees. All employees, with or without a Cisco UWL Meeting license have the same great experience, they can host a meeting with their space, initiate an ad-hoc meeting or schedule a future one. Each shared host license supports one concurrent video meeting of any size (within the limits of the hardware deployed). Each Shared Multiparty Plus license includes one Rich Media Session (RMS) license for the Cisco Expressway, which can be used to enable business-to business (B2B) video conferencing. A.2.3 Cisco Meeting Server Capacity Units Acano Capacity Units (ACUs) have been renamed Cisco Meeting Server Capacity Units. Each Capacity Unit (CU) supports 12 audio ports or the following quantity of concurrent media streams to the Cisco Meeting Server software (for the CU software license terms and conditions refer here). Table 2: Capacity Unit Licensing Media Stream Number of licenses per Capacity Unit Number of licenses required per call leg 1080p30 0.5 2 720p30 1 1 480p30 2 0.5 Each CU also entitles the Licensee to content sharing in each meeting containing at least one video participant. For more information refer to the terms and conditions of the CU license. A.3 How Cisco Multiparty Licenses are assigned When a meeting starts in a space, a Cisco license is assigned to the space. Which license is assigned by the Cisco Meeting Server is determined by the following rules: Deployment Planning and Preparation Guide : Deployment Planning and Preparation Guide 32