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. In addition to using the CMS Recorder service included with CMS, as of version 2.9 there is a new feature allowing recording of CMS meetings using a third-party SIP recording service. For the purposes of this lab, we will be demonstrating how to configure the built-in recording service, but it is important to be aware that the overall strategy for recording CMS meetings is in the process of changing so there are more options available to those administering the CMS environment.
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 Recording 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 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.
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, 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.
The CMS Recorder service acts as an XMPP client, so we need to configure the XMPP server on the Call Bridge being used as the Recorder. We will not concern ourselves with configuring XMPP clustering at this point; the way recording works natively is changing and in future releases it will not rely on the XMPP service, so we want to configure XMPP merely to show how recording is currently achieved, realizing that in future releases the specific configuration will change slightly, doing away with the need for XMPP.
First, let's configure the XMPP service on CMS1a:
Cisco Meeting Server | Password |
---|---|
cms1a.pod8.cms.lab |
Be sure to note the Call Bridge secret for each call bridge after you add them to the XMPP server. The secrets will be used in the next step below.
Start with cms1a by following these steps:
You should see that the XMPP connection is in a connected state.
Now that we have our XMPP server configured, we will focus on the actual Recorder-specific 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:
Now, we want to configure the Recorder service on cms1a. Because we are configuring the Recorder on the same CMS node as the Call Bridge service, 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:
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.
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:
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.
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:
Next, let's enable the recorder service. If everything worked correctly, you should see a success message.
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.
Next, we'll get the Recorder ID of the Recorder we just created.
Now we'll set the URL of the Recorder on the Call Bridge.
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 pod8user4.space@conf.pod8.cms.lab directly from the Jabber client.
|
|
Now that we're in a conference call, we can invite others to be part of the recording.
The CMS Recorder will now encode and write the video recording to the NFS share which will be available in a few moments.
Your recording should now be available to view in your Downloads folder.
 
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.