One optional feature that CMS provides is the ability to record meetings to be viewed later by any or a portion of the attendees. The Recorder service provides the capability to record meetings and save the recordings on a Network File System (NFS) share. The recordings can then be retrieved later for consumption by attendees of a meeting.

Supported Deployments

CMS is flexible with regard to it's deployment options and may be used in several different ways:


Cisco never recommends having the Call Bridge and XMPP services co-resident on a single server due to scalability concerns. With this in mind, the first model recommended by Cisco is the One-to-One model where the Call Bridge and XMPP services run on one node and the Recorder service runs on a different node. The recorder then sends the recordings to an NFS share on a remote server within the network.

One-to-Many/Redundant Recorder

The One-to-Many or Redundant Recorder model is another method of deploying the recorder when a resilient recorder is needed. When using this method, recordings are load-balanced between all available Recording nodes. This means that every Call Bridge uses every Recorder node available.


This concept of using all available Recorder nodes applies in the opposite direction as well where there are many Call Bridge nodes but only a single Recorder available. While this is supported, it is not necessarily recommended due to the obvious scalability concerns with a model like this.


As stated earlier, it is not recommended to host the Call Bridge, XMPP, and Recorder services all on a single CMS node. However, for demo as well as testing purposes it is supported and it is the method we will utilize in this lab to demonstrate the capability of the recorder.

Recorder Configuration

For the purposes of our lab we will also assume that the NFS server exists on our network and has been preconfigured with a share to store our recordings. In our lab we are using a Widows server for this purpose, but any NFS share will work. Let's start by connecting to the command-line of cms1a via SSH using the PuTTY application:

Cisco Meeting Server Password
cms1a.pod2.cms.lab c1sco123

Now, we want to configure the Recorder service on cms1a. Because we are configuring the Recorder on the same CMS node as Call Bridge and XMPP services, we need to change the default configuration slightly. We want the CMS server to listen on it's local loopback so that cms1a can send recordings to itself and then forward them to the NFS server. We also want to configure the Recorder to listen on the 'a' interface so that the other Call Bridges in the cluster are able to send recordings to it. We must also specify a port to run the service on. We will select a port which we know does not already have another service running. To accomplish this, we will issue the commands below:

cms1a> recorder listen a:8888 lo:8888

Once we've told the recorder to listen on the loopback as well as the primary network interface, we need to set the certificate file to be used by the recorder. We can use the certificate we already have on cms1a as well as the private key file used by the Call Bridge, let's specify those now with the command below.

cms1a> recorder certs cms1a.key cms1a.cer

We also need to add the certificate used by the Call Bridge to the Recorder trust store. Since we have a cluster, we need to specify the trust bundle we created earlier so that the Recorder will trust any of the Call Bridge nodes that might send recordings to it. We will specify that bundle with our command below:

cms1a> recorder trust cms1abc.cer

Now that we have the certificates specified, we need to tell the Call Bridge where we want to send our Recordings. As mentioned earlier, this needs to be specified as an NFS path that exists on our network. We are sending our recordings to a Windows 2008 R2 Server running NFS services, but any NFS service will work. We will specify the hostname of the NFS server, as well as the directory to store the recordings.

cms1a> recorder nfs recorder.cms.lab:/pod2

We also want to set the resolution of our recorded meetings to 720p which will allow us to save a bit of space while not compromising video quality. Set the resolution by issuing the command below:

cms1a> recorder resolution 720p

Next, let's enable the recorder service. If everything worked correctly, you should see a success message.

cms1a> recorder enable SUCCESS: Key and certificate pair match SUCCESS: Recorder enabled

Add the Recorder to the Call Bridge Using Postman

Now that we've enabled the recorder service on the command-line, we need to add the recorder to the Call Bridge using the API. To do that, we'll launch the Postman tool.

  1. Launch Postman using the desktop shortcut.
  2. Change the verb to POST.
  3. Enter the following URL in the address bar to target the recorders entity: https://cms1a.pod2.cms.lab:8443/api/v1/recorders.
  4. Send an empty POST and you should get back a 200 OK.

Next, we'll get the Recorder ID of the Recorder we just created.

  1. Change the verb to GET and hit Send. You should see output similar to that below with the Recorder ID populated.
  2. Be sure to save the ID of the Recorder, we'll need it in the next step.

Now we'll set the URL of the Recorder on the Call Bridge.

  1. Change the verb to PUT and set the URL to https://cms1a.pod2.cms.lab:8443/api/v1/recorders/### Your Recorder ID ###
  2. In the Body, add a key labeled url and set the value to https://cms1a.pod2.cms.lab:8888
  3. Hit Send
  4. We should get a 200 OK.

Now that we have specified the Recorder address, we should be able to record our meetings manually. Let's try a test call to make sure we see the 'Record' button and are able to initiate a recording. Then, we'll download the recording and play it back to insure it worked correctly. Jabber should already be launched and registered. First, place a call to directly from the Jabber client.


Now that we're in a conference call, we can invite others to be part of the recording.

  1. Click Invite Participants

  2. In the search field enter Pod2 User1
  3. Now hover over the Pod2 User1 entry and click the green call icon.
  4. Click the +E.164 work number for that user to place the outbound call from CMS to the user.

  5. This user will auto-answer, as we saw earlier in the lab.

  6. NOTE: If the remote side does not answer, this usually means Jabber on PC1 is either not launched or on an active call. Access PC1 via the Remote Desktop shortcut on your desktop. Then disconnect/restart Jabber on PC1.
  7. Now, you should see the Record button on the Jabber client after clicking the button in the call window. While CMS is recording, you will see the icon at the top left of your CMS conference window.
  8. Wait about 30 seconds to record enough video to play back, then click the button after selecting the button in the call window.

The CMS Recorder will now encode and write the video recording to the NFS share which will be available in a few moments.

  1. Browse to http://recorder.cms.lab/recordings/?dir=pod2
  2. You should see a directory listing on the web server we're storing our recordings on. In this directory, CMS creates a subdirectory called spaces which contains subdirectories with a title in the format a long UID which represents the Space ID as CMS defines it.
  3. You can click on the directory containing your recordings and download the video to test it out.

Your recording should now be available to view in your Downloads folder.

  1. Open the video to view the recording you just created.
  2. When finished, navigate to Jabber to end the call. Disconnect Pod 2 User 1 by hovering over the user in the participant list, right-clicking and selecting the Expel option. Now, hang up yourself by hovering over the video window and clicking on the button.



You've finished the main portion of the lab. There are multiple additional optional lab sections, depending on your time and interest, to continue on.