Cisco Meeting Server (CMS) brings audio, video, and web communication together in a single on-premise conferencing solution. The platform is scalable and interoperates with a variety of 3rd party solutions.
The CMS software, regardless of the hardware platform, comes bundled with all necessary components to deploy every feature. It is up to the administrator to configure one or more CMS service components to provide scalability, redundancy, and functionality such as external access. The CMS software is available for dedicated hardware appliances as well as a virtual appliance.
There are three deployment models for CMS: Single Combined, Single Split, and Scalable and Resilient Meeting Server deployments. The Single Combined deployment model is exactly that - one server running all the services you need. In most cases, this type of deployment is applicable only to internal-only access and in smaller environments, where the scalability and redundancy limitations of a single server are not a critical concern, or in situations where the CMS is only tasked with specific features, such as ad-hoc conferencing.
The Single Split deployment model extends the previous configuration by adding a separate server for external access. In legacy deployments, this meant deploying a CMS server in the edge network, where external clients could reach it, and one CMS server in the core, where internal clients have access. This particular deployment model is now being supplanted by what is called the Single Edge, which consists of Cisco Expressway servers, which either have or will have many of the edge traversal capabilities, so customers will not need to add a dedicated CMS edge server just for CMS.
This leads us to the final deployment model: Scalable and Resilient. This includes redundancy for each component, allowing for the system to grow with your needs to its maximum capacity, while providing redundancy in case of failure. It also leverages the Single Edge concept to provide secure external access. This is the model we will examine in this lab. If you understand this, you will not only understand the other deployment models, but it will allow you to understand how to build a system with growth in mind.
The newer single edge architecture, which you will deploy in this lab, still includes all core roles for CMS, however we will utilize the Cisco Expressway series of products to allow external access to our meetings and provide secure firewall traversal. While there are currently still some feature gaps between the single edge model and the traditional Acano/CMS deployments, we will introduce the concepts for deploying a Collaboration Edge that can be applied regardless of CMS or Expressway.
The lab topology presented here will expose you to configuration methods and design concerns applicable to every complex CMS deployment.
The core software components for CMS are:
You will note that we did not include things like Loadbalancer or TURN server. These are CMS components that are deployed exclusively in the edge network. For this lab, we will not deploy any CMS servers at all in the DMZ at the Edge. We will leave this functionality for Expressway. This does currently limit us to not being able to deploy CMA (other than WebRTC CMA), however this can leverage an existing Expressway deployment and traditional CMA will eventually be supported by this architecture.
For this lab, we will examine the scalable, resilient deployment model for CMS. We will add call control via the Unified CM and provide external access with the Cisco Expressway as well as management capabilities with Cisco Meeting Management (CMM). In understanding these components and the interactions between the products and their features, we will better understand how CMS is deployed in nearly every other deployment scenario.
The software versions used in this lab are CMS 2.5.2, CMM 220.127.116.11, Expressway X12.5.2 for external access, and Jabber 12.6.0 as our video client. Differences in product capabilities or configuration steps may exist in older or newer versions.
Unlike most other Cisco products, Cisco Meeting Server supports (in fact in most cases requires) three methods of configuration to get any larger deployment off the ground:
In addition, the SFTP protocol is used to transfer files - typically licenses, certificates, or logs - to and from the CMS server. While there may be tools that can configure much of this, it is imperative for administrators to understand and be comfortable with each of these methods of access and the type of information each provides.
Before getting started, let’s map out exactly what you will accomplish in this lab:
In this lab you will use the Windows PuTTY application for MMP (SSH CLI) access. For Web Admin access you will use Google Chrome, and for API-related configuration tasks we will use the Postman application.
Throughout this lab, you will find that CMS is indeed a powerful product with many features. It is truly a Swiss Army knife for interoperability. While it is impossible to cover all scenarios, we have tried to highlight a few specific configuration methods and design practices that will help you understand the CMS capabilities as well as give you the tools to deploy these or other features successfully.