Lab Overview

CMS Overview

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.

Deployment Models

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.

network-topo.png

Lab Topology

The lab topology presented here will expose you to configuration methods and design concerns applicable to every complex CMS deployment.

Software Components

The core software components for CMS are:

  • Database: Allows some configuration, such as dial plan, spaces, and users to be aggregated. Supports clustering for high availability only (single master).
  • Call Bridge: The audio and video conferencing bridge, including all call control and media processing. Supports clustering for high availability and scalability.
  • Web Bridge: Provides access for WebRTC clients
  • Web Admin: Administration GUI and API access, including for Unified CM ad-hoc conferencing
  • Recording & Streaming: Call recording and streaming functionality

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.9, CMM 2.8.0.97, Expressway X12.5.6 for external access, and Jabber 12.7.1 as our video client. Differences in product capabilities or configuration steps may exist in older or newer versions.

Configuration Modes

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: 

  • Command Line (CLI): The command-line interface, known as the MMP (or Mainboard Management Processor, from the Acano appliance days), for initial configuration tasks and certificates.
  • Web Admin: Primarily for CallBridge-related configuration, especially when configuring a single, non-clustered server.
  • REST API: Used for most advanced configuration tasks and those that involve a clustered database.

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:

  1. Basic CMS Server configuration: The IP addresses and basic services such as NTP, DNS, and some certificates have already been configured for you. You will want to be sure that everything is set up properly before going any further. These services are crucial with any deployment because DNS lookup failures or inaccurate clocks can lead to issues that can be challenging to troubleshoot during the setup process.
  2. Configure CMS Database Clustering
  3. Configure the WebAdmin component
  4. Configure the CallBridge component and CallBridge clustering
  5. Configure Web Bridge
  6. Configure LDAP Synchronization and Authentication on CMS
  7. Configure a CMS Inbound and Outbound Dial Plan
  8. CMS call control integration via Cisco Expressway and Unified CM with load balancing considerations
  9. Optional bonus section - Advanced features, such as Space creation, Ad-hoc conferencing, and Branding
  10. Optional bonus section - Set up Expressway Edge: Web Proxy for WebRTC and TURN server
  11. Optional bonus section - Integration with external Skype for Business via Expressway
  12. Optional bonus section - Integration with on-premises Skype for Business
  13. Optional bonus section - Administering CMS meetings with Cisco Meeting Management

In this lab you will use the Secure Shell extension for Google Chrome 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.