Cisco Meeting Server Feature Update Lab v1: About This Demonstration

Cisco dCloud
Cisco Meeting Server Feature Update Lab v1

Last Updated: 30-JANUARY-2018
Created in Partnership with the Collaboration VT Lab Owners.
About This Demonstration

This preconfigured demonstration includes:
• Requirements
• About This Solution
• Topology
• Session Users
• Get Started
• Scenario 1: Active Control
• Scenario 2: Load Balancing across Meeting Servers with Call Bridge Groups
• Scenario 3: Configure CMS as Meeting Recorder Server
• Scenario 4: Configure CMS to be a Streaming Server
• Scenario 5: PREVIEW – Expressway Unified Edge
• Scenario 6: PREVIEW – Cisco Meeting Management
Requirements
The table below outlines the requirements to complete this lab.
Table 1. Requirements
Required Optional
• Laptop with Cisco AnyConnect® • None

• dCloud Router with video endpoint and 2 x video phones
o DX80 and 8845 recommended
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 75
Cisco dCloud
About This Solution

Cisco® Meeting Server is the lead offer of Cisco on-premises video conferencing solution that brings together video, audio, and
web communication to meet the collaboration needs of the modern workplace. Cisco Meeting Server is the next generation
conferencing platform that brings greater scale and interoperability as well as improved conferencing capabilities. Participants can
join meetings hosted on Cisco Meeting Server using standard SIP endpoints (Cisco room or desktop video systems or third-party
video endpoints) or Cisco Meeting App. Cisco Meeting App consists of mobile, desktop, and WebRTC native or compatible
browsers clients.
With v2.0, Cisco Meeting Server is now optimized to be deployed with Cisco Unified Communications Manager (CM) for call
control. This allows customers with Cisco Unified Communications (UC) deployment to fully integrate with our latest conferencing
capabilities such as distributed conferencing, and existing UC features such ad-hoc conference escalation, scheduled conferences
using Exchange and personal Spaces. The objective for this session is to understand the latest features and innovations included
in the Cisco Meeting Server platform, and deploy them as part of the Cisco UC platform to create the best collaborative video
experience for customers.
Benefits of migrating to the Cisco Meeting Server solution:
• One software solution for audio, video and web conferencing
• Rich interoperability with support for standards based endpoints, WebRTC, and Skype for Business
• Scalable conferencing with WAN bandwidth optimization
• Integration with other workplace tools via API
• Support for immersive Cisco TelePresence® endpoints
Multiparty licensing is the primary licensing model used for Cisco Meeting Server. 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 PMP plus and SMP plus licenses can be used on the same server.
Personal Multiparty Plus License

PMP plus provides a named host license assigned to each specific user who frequently hosts video meetings. This can be
purchased through Cisco Unified Workspace Licensing (UWL) Meeting (which includes PMP plus). PMP 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 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.
Shared Multiparty Plus License

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 when purchased with room endpoints (SX / MX / RMK), or it can be purchased separately. SMP plus lets 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 SMP plus
Cisco dCloud
license includes one Rich Media Session (RMS) license for the Cisco Expressway™, which can be used to enable business-to-
business (B2B) video conferencing.
This lab consists of a preconfigured standalone Cisco Unified CM and TelePresence Management Suite (TMS), two clustered
combined Cisco Meeting Servers (for the purpose of this lab, Cisco Meeting Server will also be referred to as CMS), and a third
CMS instance to be used for recording and streaming. Each CMS has the core components preconfigured with self-signed
certificates installed.
The goal of the lab is to configure Unified CM, TMS, and CMS to demonstrate new features including Active Control, Call Bridge
groups, recording, and live streaming. Additionally, you will get a preview of upcoming enhancements including support for CMS
edge service in Expressway (Unified Edge), and Cisco Meeting Management (CMM). CMM is a new tool that will initially allow
control of active meetings, but will ultimately grow to cover control, configuration, and management of the CMS system.
NOTE: CMS PMP plus and SMP plus licenses are both included on the servers used in this lab.
Each module in the lab is standalone and can be completed in any order.
Topology
The components in the lab include preconfigured users and components to illustrate the features and function of the solution. Most
components are fully configurable with predefined administrative user accounts. You can see the IP address and user account
credentials to use to access a component by clicking the component icon in the Topology menu of your active session and in the
scenario steps that require their use.
Figure 1. CMS Lab Topology
Cisco dCloud
Table 2. Server Details
Name Description Host Name (FQDN) IP Address Username Password

CUCM1 Cisco Unified Communications Manager 11.5 ucm1.dcloud.cisco.com 198.18.133.3 administrator dCloud123!
IM & P IM & Presence 11.5 imp1.dcloud.cisco.com 198.18.133.4 administrator dCloud123!
CUxN Cisco Unity Connection 11.5 cuc1.dcloud.cisco.com 198.18.133.5 administrator dCloud123!

CMS1 Cisco Meeting Server v2.1.7 cms1.dcloud.cisco.com 198.18.134.175 admin dCloud123!

TMS TelePresence Management Suite 15.5.0 tms1.dcloud.cisco.com 198.18.133.158 administrator C1sco12345
Exp-C Expressway-C (Core) X8.9.2 exp-c-1.dcloud.cisco.com 198.18.133.152 admin dCloud123!
Exp-E Expressway-E (Edge) X8.9.2 exp-e-1.dcloud.cisco.com 198.18.1.152 admin dCloud123!

198.18.2.152
Exchange Microsoft Exchange 2010 mail1.dcloud.cisco.com 198.18.133.2 administrator C1sco12345
AD1 AD (Win2K8) and DNS server ad1.dcloud.cisco.com 198.18.133.1 administrator C1sco12345
CMM Cisco Meeting Management (Pre-release) dem-cmm- 198.18.135.56 admin cisco

sevt.dcloud.cisco.com
Workstation 1 Windows 7 wkst1.dcloud.cisco.com 198.18.133.36 cholland C1sco12345
Workstation 2 Windows 7 - OUTSIDE wkst2.dcloud.cisco.com 198.18.2.37 aparez C1sco12345
Workstation 3 Windows 7 wkst3.dcloud.cisco.com 198.18.133.38 mcheng C1sco12345
Session Users
The table below contains details on preconfigured users available for your session.
Table 3. User Information
User Name User ID Password Endpoint Devices Phone Extension Workstation
Charles Holland cholland C1sco12345 DX70 +1 408 555 6018 6018 wkst1
Monica Cheng mcheng C1sco12345 8800 +1 408 555 6030 6030 wkst3
Anita Perez aperez C1sco12345 8800 +1 212 555 6017 6017 wkst2 (OUTSIDE)
Get Started
BEFORE PRESENTING
Cisco dCloud strongly recommends that you perform the tasks in this document with an active session before presenting in front
of a live audience. This will allow you to become familiar with the structure of the document and content.
It may be necessary to schedule a new session after following this guide in order to reset the environment to its original
configuration.
PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.
Follow the steps to schedule a session of the content and configure your presentation environment.
1. Browse to dcloud.cisco.com, select the location closest to you, and log in with your Cisco.com credentials.
Cisco dCloud
2. Register and configure your router if this is the first time you will use the router with dCloud. [Show Me How]
3. Schedule a session. [Show Me How]
4. Test your connection. [Show Me How]
5. Verify that the status of your session is Active in My Dashboard > My Sessions.
NOTE: It may take up to 30 minutes for your session to become active.
6. Click View to open the active session.
7. For best performance, connect to the lab with Cisco AnyConnect VPN [Show Me How] and the local RDP client on your
laptop [Show Me How].
NOTE: You can also connect to the workstation using the Cisco dCloud Remote Desktop client [Show Me How]. The dCloud
Remote Desktop client works best for accessing an active session with minimal interaction.
Cisco dCloud
Scenario 1: Active Control

From version 2.1, the CMS supports ActiveControl for hosted calls. For participants using a Cisco SX, MX, or DX endpoint with CE
8.3+ software installed, ActiveControl allows the meeting participant to receive details of the meeting and perform a few
administrative tasks during the meeting, using the endpoint interface.
CMS supports sending the following meeting information to ActiveControl enabled endpoints:
• Participant list (also known as the roster list) so that you can see the names of the other people in the call and the total
number of participants
• Indicator of audio activity for the currently speaking participant
• Indicator of which participant is currently presenting
• Indicators telling whether the meeting is being recorded or streamed, and if there are any non-secure endpoints in the call
• On-screen message which will be displayed to all participants
CMS supports these administrative tasks on ActiveControl enabled endpoints:
• select the layout to be used for the endpoint
• disconnect other participants in the meeting
Limitations
• If an ActiveControl enabled call traverses a Unified CM trunk with a Unified CM version lower than 9.1(2), the call may fail.
ActiveControl should not be enabled on older Unified CM trunks (Unified CM 8.x or earlier).
• Active Control is a SIP only feature. H.323 interworking scenarios are not supported.
NOTE: ActiveControl uses UDT transport for certain features, i.e. sending roster lists to endpoints and allowing users to disconnect
other participants while in a call.
Overview on ActiveControl and the iX Protocol

ActiveControl uses the iX protocol, which is advertised as an application line in the SIP Session Description Protocol (SDP). The
Meeting Server automatically supports ActiveControl, but the feature can be disabled. In situations where the far end network is not
known or is known to have devices that do not support the iX protocol, it may be safest to disable iX on SIP trunks between CMS
and the other Call control or Video Conferencing devices. For instance:
• Connections to Unified CM 8.x or earlier systems. Older Unified CM systems will reject calls from ActiveControl-enabled
devices. To avoid having these calls fail, disable iX on any trunk towards the Unified CM 8.x device in the network. In cases
where the 8.x device is reached via a SIP proxy, ensure that iX is disabled on the trunk towards that proxy.
• Connections to third-party networks. In these cases, there is no way to know how the third-party network will handle calls from
ActiveControl-enabled devices, the handling mechanism may reject them. To avoid such calls failing, leave iX disabled on all
trunks to third-party networks.
Cisco dCloud
• Cisco VCS-centric deployments which connect to external networks or connect internally to older Unified CM versions. From
Cisco VCS X8.1, you can turn on a zone filter to disable iX for INVITE requests sent to external networks or older Unified CM
systems. (By default, the filter is off.)
Task 1: Create a Test Space in CMS
1. If disconnected from Workstation 1, RDP to Workstation 1 (198.18.133.36) and, if necessary, log in as Charles Holland:
a. Username: dcloud\cholland
b. Password: C1sco12345
2. Using your browser navigate to https://cms1.dcloud.cisco.com:445 and log in:
a. Username: admin
b. Password: dCloud123!
c. Password will show as expired. Please set new password to dCloud123! Again.
3. Go to Configuration > Spaces.
4. In the blank entry at the bottom, create a new space. Use these parameters:
a. Name: Test Space
b. URI user part: 7000
5. Click Add New.
Figure 2. Space Configuration
6. Test the new space by dialing 7000 from one of the endpoints. You should be connected to the new space you just created.
Cisco dCloud
Task 2: Creating a SIP Profile in Unified CM
Support for the iX protocol is enabled by default on the Standard SIP Profile for Telepresence Conferencing that is used on the
trunks to CMS. To properly see the effects of Active Control, you need to create a SIP profile with the iX protocol disabled.
1. From a browser, log in to https://ucm1.dcloud.cisco.com.
a. Username: administrator
2. Once logged in, go to Device > Device Settings > SIP Profiles.
3. Click Standard SIP Profile for Telepresence Conferencing.
4. At the top, click Copy. Change the name to SEVT SIP Profile for Telepresence Conferencing and click Save.
5. Scroll to the bottom and UNCHECK the box Allow iX Application Media and click Save.
Figure 3. Creating SIP Profile
Task 3: Test Active Control Using the Test Space

1. First we will test with active control enabled. Dial into the Test Space at 7000 for all three endpoints.
2. Touch the person list icon in the top right corner of the DX70. You will see a list of meeting participants.
Cisco dCloud
Figure 4. Meeting Participants List
3. Touch a participant on the list. You will see a Favorite and a Drop option. Click Drop. That caller will be removed from the
meeting.
4. There is also an icon (next to the person list icon) that allows you to change the screen layout. Touch this icon and test by
changing the layout to something different.
Figure 5. Drop Call
5. Now turn Active Control OFF and try the test again.
6. From Unified CM administration, go to Device > Trunk and click Find.
Cisco dCloud
7. Look for the trunk to CMS that has the 7XXX route pattern associated with it. Click that trunk to open it.
8. Change the SIP Profile (in the SIP Information section at the bottom of the page) to the SEVT SIP Profile for TelePresence
Conferencing that you created before.
Figure 6. SIP Profile
9. Be sure to click Save and Reset twice to activate the change.
10. Wait several minutes for the trunk to come back into Full Service before proceeding.
11. Now we will test with active control DISABLED. Dial into the Test Space at 7000 for all three endpoints.
12. Notice with Active Control disabled, you are only able to see yourself and the number you called on the list – not the individual
participants.
13. Also note that there is no icon showing to change the screen layout – that is an Active Control Function.
14. When you are finished testing, change the SIP Profile on the trunk back to Standard SIP Profile for TelePresence
Conferencing.
Cisco dCloud
Figure 7. Meeting Participants List
This concludes this scenario.
Cisco dCloud
Scenario 2: Load Balancing across Meeting Servers with Call Bridge

Groups
A typical large scale deployment consists of several Meeting Servers deployed at multiple offices/data centers. For scalability and
resilience of the conferencing service, the Call Bridges will typically be configured as a cluster.
This lab will show how to use Call Bridge Grouping to load balance incoming on the Meeting Servers, and avoid overloading
individual Meeting Servers in the cluster. In a real-world scenario, load balancing outbound calls would also be recommended.
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.
Figure 8. Examples of Load Balancing Incoming Calls
NOTE: The Cisco VCS is not currently supported since it doesn’t include support for SIP ‘INVITE with Replaces’.
Call Bridge Grouping

The load balancing of calls occurs between a group of Call Bridges that exist in the same location. To configure which Call Bridges
are in each location, a new concept of Call Bridge groups has been added to version 2.1 of the Cisco Meeting Server software. A
Call Bridge group defines a subset of cluster nodes that are more closely linked and should be treated as equivalent. This could
refer to those in a single data center, or those in the same continent. The decision of how to group Call Bridges will depend on the
specifics of your network configuration and the desired behavior.
For the load balancing feature to work correctly, a Round Trip Time (RTT) of less than 100 ms is required for the servers in a Call
Bridge group. The maximum RTT between any two nodes in the same cluster remains as 300 ms.
Refer to the Load Balancing across CMS white paper for real world example:
• http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/White_papers/Load-balancing-calls-across-
Meeting-Servers-2-2-white-paper.pdf
Cisco dCloud
This lab will consist of two Tasks.
• Task 1: Create the Call Bridge Groups
• Task 2: Enable Load Balancing Limits on the Call Bridges
Task 1: Create the Call Bridge Groups

1. If disconnected from Workstation 1, RDP to Workstation 1 (198.18.133.36) and, if necessary, log in as Charles Holland
2. Before you access Postman Application you need to access CMS1 and CMS2 to reset the api password.
3. Please access CMS1 with the admin password dCloud123! and run the command passwd api. Enter the existing password
dCloud123!.
4. Set new api password to dCloud123!.
5. Repeat steps 2-4 on CMS2 (Password on CMS2 is expired. Please set new password to dCloud123!)
6. If it is not already running, from the taskbar, launch the Postman [ ] application.
7. Import the CallBridgeGroups-config.json file from the CMS Update Lab folder on the Workstation 1 desktop.
Figure 9. Import File
Cisco dCloud
Figure 10. Select the CallBridgeGroups Collection
8. Select the Get Call Bridge IDs method.
9. Click Send.
10. Copy the returned CallBridge IDs, which are associated to CMS1/2 to Notepad for later use. Copy everything between the <>.
Cisco dCloud
Figure 11. Get Method for Call Bridge IDs
11. Choose the Post Create Call Bridge Groups method.
12. Click on the Body tab.
13. Enter CallBridgeGroup1 in the name key.
14. Enter true in the loadBalancingEnabled key.
15. Click Send.
Cisco dCloud
Figure 12. Creating Call Bridge Group w/Load Balancing
16. Repeat the previous Post method changing the name key to CallBridgeGroup2.
17. Select the Get CallBridgeGroup IDs method.
18. Click Send.
19. Copy the callBridgeGroup IDs to Notepad for later use. Copy everything between the <>.
Figure 13. Get Method to Copy CBG IDs
20. In the right pane of postman, leave the method as GET and add a slash “/” to the end of the URI field followed by one of the
callBridgeGroup IDs that was returned in the previous step.
For example: https://cms1.dcloud.cisco.com:445/api/v1/callBridgeGroups/8b58de8e-f696-4ef6-b6be-99702082bf57
21. Click Send.
22. Verify that the loadBalancingEnabled key is true.
Cisco dCloud
23. You can repeat the previous steps to verify the second call bridge group as well.
Figure 14. Verify Load Balancing is Enabled for the Bridge Group
24. Select the PUT Assign Call Bridge to Group method.
25. Select the Body tab.
26. After the slash “/” in the URI field, copy the Call Bridge ID for CMS1 that was saved in notepad previously. Only copy the ID
between the quotes “”. For example: 8cbb6c16-f8ef-45a7-ab53-4b5d89c0018e
27. Copy the callBridgeGroup id for CallBridgeGroup1 from Notepad into the callBridgeGroup key. Only copy the ID between
the quotes “‘’. For example: 8b58de8e-f696-4ef6-b6be-99702082bf57
28. Click Send.
NOTE: This assigns the Call Bridge on CMS1 to CallBridgeGroup1.
Figure 15. Assign Call Bridges to Group
29. After the slash “/” in the URI field, copy the CallBridge ID for CMS2 that was saved in notepad previously. Only copy the ID
between the quotes “”.
Cisco dCloud
30. Copy the callBridgeGroup ID for CallBridgeGroup2 from Notepad into the callBridgeGroup key. Only copy the ID between
the quotes ‘’.
31. Click Send.
NOTE: This assigns the Call Bridge on CMS2 to CallBridgeGroup 2.
32. Verify that the call bridges are assigned to a group by using the a GET method to the following URI:
https://cms1.dcloud.cisco.com:445/api/v1/callBridges/<callBridgeID>
This completes this Task.
Task 2: Enable Load Balancing Limits on the Call Bridges

1. Select the PUT Set load Limit on each call bridge method.
2. Click the Body tab.
3. Enter the value 6250 in the loadLimit key.
4. Click Send.
NOTE: The CMS servers in the lab have 5 vCPUs, base the value of the load limits you set on the following chart.
Figure 16. CMS Load Limit Values
Figure 17. Set Load Limit on CMS1
5. In the right pane of Postman, change the method to GET and click Send. You should see the loadLimit parameter is now set
to 6250 in the value returned.
Cisco dCloud
Figure 18. Verifying Load Limit is Set
NOTE: Since the lab has limited number of endpoints, we cannot test the load balancing is working, but it is now configured on
CMS1. In actual production, you would need to set the load limit on each CMS bridge in the cluster by issuing the put command
above to each server individually by changing the server in the URI field in the right pane of postman to:
https://cms2.dcloud.cisco.com:445/api/v1/system/configuration/cluster
Before you can do this on each server, you have to set up the API user on each of the servers.
This conclude this Task and this Scenario.
Cisco dCloud
Scenario 3: Configure CMS as Meeting Recorder Server

The Recorder component was added to CMS in v1.9. The Recorder component provides the capability of recording meetings and
saving the recordings to a document storage such as a network file system (NFS). The recording is automatically converted to
MP4 and saved onto the NFS at the end of recording the meeting.
The Recorder should be hosted on the CMS server that is remote to the server hosting the Call Bridge. If the Recorder is hosted
on the same server as the Call Bridge (local), then it should only be used for testing purposes or for very small deployments. It is
recommended to deploy the Recorder and NFS 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.
One call bridge can support multiple Recorders or multiple call bridges can use the same Recorder (see figures below). If multiple
Recorders are used, then the solution load balances recordings between all recording devices and no knowledge of the physical
location of recording devices is known. Every Call Bridge will use every Recorder.
Figure 19. One Call Bridge with Multiple Recorders
Figure 20. Multiple Call Bridges with One Recorder
Cisco dCloud
In addition, the recorder is an XMPP client and XMPP server is required for the deployment.
In this lab, we will use a third CMS server (CMS3) as a recording / streaming device as recommended in the deployment
documentation. To configure the Recorder, use CLI commands to enable the Recorder on CMS, specify which Call Bridges within
the deployment will work with the Recorder and where to save the recordings. Also, use CMS API to specify the Recorder’s
HTTPS URL address that the Call Bridge should use, set the recordingMode parameter in call profiles object to specify how to
start recording, set the recordingControlAllowed parameter in call leg profiles object to allow users control when to start/stop
recording. Here are the high-level tasks to setup this scenario:
• Task 1: Install the certificate bundle on the CMS3 server to be used by the recorder (SKIP THIS IF YOU RAN THROUGH
THE STREAMING SCENARIO ALREADY – IT WAS DONE THERE)
• Task 2: Setup Recorder on the server using CLI
• Task 3: Configure Recorder for Manual Recording using API
• Task 4: Test Automatic Recording
Task 1: Install the Certificate Bundle on CMS

When using a remote recorder, it needs to trust all of the Callbridge’s that will connect to it. This is accomplished by installing a
trust bundle containing all of the certificates from the other servers plus the root certificate. The recorder process will trust all the
Call Bridges included in the trust bundle. The trust bundle has been created for you and is located on wkst1 in the CMS folder.
Copy the Trust Bundle
1. On wkst1, open the WinSCP application [ ].
2. Connect to 198.18.134.147 (CMS3) and log in with password dCloud123!.
Cisco dCloud
Figure 21. Log in
3. Drag the file cmsbundle.crt (located in the CMS folder on the desktop) to the CMS3 server.
Figure 22. Drag cmsbundle.crt to the CMS3 Server
4. Close WinSCP.
Cisco dCloud
5. Open PuTTY and SSH to 198.18.134.147 (CMS3).
6. Log in with:
a. Username: admin
7. At the cms3> prompt, enter pki list.
8. Verify that certificates cms3.key, cms3.crt, caroot.crt, and cmsbundle.crt are listed.
Figure 23. Certificates
This concludes this Task.
Task 2: Set up Recorder on the Server Using CLI
Configure Recorder
2. Log in with:
a. Usenamer: admin
Recorder is an XMPP client and requires the enablement of the XMPP server.
3. At the cms3> prompt, enter the following commands:

xmpp disable
xmpp listen a
xmpp certs cms3.key cms3.crt caroot.crt
xmpp domain dcloud.cisco.com
xmpp enable
Cisco dCloud
Figure 24. PuTTY Commands and Success Message
4. Continue to enter the following commands:

recorder listen a:8443
recorder certs cms3.key cms3.crt caroot.crt
recorder trust cmsbundle.crt
recorder nfs 198.18.133.1:recordings
recorder enable
Figure 25. Add Recorder Commands to CMS1 with Success
NOTE: This lab uses a remote recorder, and the recorder must therefore listen on an appropriate network interface e.g. a:8443.
Otherwise, the recorder can listen on the network interfaces a – d.
Recordings store on the NFS mount recordings located on the dcloud domain controller (198.18.133.1).
5. You must authenticate the Call Bridge to the XMPP service. Open a web browser and view the CMS3 web admin interface at
https://cms3.dcloud.cisco.com:445.
6. Log in with:
a. Username: admin
Cisco dCloud
7. Navigate to Configuration->General and note the name of the Call Bridge under XMPP server settings.
Figure 26. Call Bridge Name
8. Add the Callbridge to XMPP using PuTTY and the command line for CMS3.
a. Enter: xmpp callbridge add <Callbridge Name from Step 7>
9. You will see a result similar to what is shown below.
Figure 27. Secret
10. Make note of the Secret shown. You will need it in the next step. If you miss it, you can find it again by entering xmpp
callbridge list from the cms3> prompt.
11. Return to the web admin page, Configuration->General. On the line for Shared Secret, click [change]. Enter the secret key
from above for both Shared Secret and Confirm Shared Secret. Be sure to click Submit at the bottom of the page to save
your changes.
12. Verify that the XMPP service is active and has no errors. On the web admin interface for CMS3, navigate to Status->General.
The XMPP connection should say connected and the Authentication service should be registered.
13. Finally, to view the recorder details enter the command recorder.
Cisco dCloud
Figure 28. Recorder Details
Cisco dCloud
Task 3: Configure Recorder for Manual Recording using API
Configure API
1. If disconnected from Workstation 1, RDP to Workstation 1 (198.18.133.36) and if necessary log in as Charles Holland with
Username: dcloud\cholland and Password: C1sco12345
2. If PuTTY has closed, from the Desktop, launch PuTTY [ ].
3. SSH to 198.18.134.147 (CMS3) and log in with User admin and Password dCloud123!.
4. At the command prompt type user add api api
NOTE: Configure an API user that the Postman tool utilizes to authenticate with CMS for making API calls.
5. At the Please enter new password prompt, enter dCloud123!.
6. Confirm the password.
Figure 29. Create User API
Import the JSON files to Postman
1. If disconnected from Workstation 1, RDP to Workstation 1 (198.18.133.36) and, if necessary, log in as Charles Holland with
Username: dcloud\cholland and Password: C1sco12345.
3. Click Import on the top left of the window.
Figure 30. Import
4. If not selected, click the Import File tab.
5. Click Choose Files.
Cisco dCloud
Figure 31. Choose File to Import
6. Browse to the Desktop->CMS Update Lab folder and select the Recorder-Config.json file.
Figure 32. Choose the Recorder-Config.json File
7. Click Open.
Create a Recorder Object
8. In the Postman left panel, under Recorder-Config collection, click on the recorders folder to expand the folder.
Cisco dCloud
Figure 33. recorders Folder
9. Click on the POST request under the recorders folder.
10. On the right panel of Postman, this will load the recorders POST request URL. Click the Body tab to display its key/value
pairs as shown below.
Figure 34. recorders POST Body Contents
11. Click Send.
NOTE: This creates a remote recorder entry in the CalI Bridge on CMS1 and CMS2 that points to CMS3 port 8443 that was set up
previously.
Create a callLeg Profile
A callLeg profile determines the in-call behavior. In the case of recording, it determines if a call can be recorded.
12. In the left panel, under Recorder-Config collection, click on the callLegProfiles folder to expand it.
13. Click on the POST request under the callLegProfiles folder.
Cisco dCloud
Figure 35. callLegProfile Folder
14. One the right panel of Postman, this will load the callLegProfiles POST request URL. Click the Body tab to display its
key/value pairs as shown below.
Figure 36. callLegProfiles Body Contents
15. Click Send.
NOTE: This creates a callLeg profile with the parameter, recordingControlAllowed, set to true. A Record button appears on the
Cisco Meeting App that users can use to start/stop recording(s). On a regular endpoint device, users can utilize DTMF to start/stop
recording, however, this requires creating a DTMF profile to define the keys to use to start/stop recording. If
recordingControlAllowed is set to false or does not exist, no Record button will appear on the Cisco Meeting APP nor can users
utilize DTMF to start/stop recording(s).
16. Click on the GET request under the callLegProfiles folder.
Cisco dCloud
Figure 37. GET callLegProfiles
17. This will load the GET request URL on the right panel as shown below.
Figure 38. GET Request URL
18. Click Send and the response should show all the callLeg profile ID.
Figure 39. GET Result
NOTE: This would retrieve all existing call leg profiles in CMS. Validate that the first one listed is the one you just created. IF
YOU DON’T KNOW HOW TO VALIDATE, ASK A PROCTOR – THIS IS IMPORTANT!
19. Save the correct callLegProfile id attribute to Notepad for later use.
Create a Call Profile
A Call profile defines whether calls can be recorded and if they can be done with or without user intervention.
20. Under the Recorder-Config collection, click on the callProfiles folder to expand it.
Cisco dCloud
Figure 40. callProfile Folder
21. Click on the POST request under the callProfiles folder.
22. On the right panel of Postman, this will load the callProfiles POST request URL. Click the Body tab to display its key/value
Figure 41. POST callProfile Key/Values
NOTE: Set the recordingMode parameter in call profile. Manual allows user to start/stop recording manually, Automatic allows the
recording to start automatically when the call is launched. This lab uses Manual.
23. Click Send.
24. Click on the GET request under the callProfiles folder.
Cisco dCloud
Figure 42. GET Request
Figure 43. GET Contents
26. Click Send. The response should show the call profile ID.
Figure 44. callProfile ID
27. Save the first callProfile id attribute to notepad for later use.
Create a DTMF Profile
NOTE: A DTMF Profile identifies DTMF Key sequences to control system functions, such as like start and stop recording in our
case.
28. Under the Recorder-Config collection, click on the dtmfProfiles fold to expand it.
29. Click on the POST request under the dtmfProfiles folder.
30. On the right panel of Postman, this will load the dtmfProfiles POST request URL. Click the Body tab to display its key/value
Cisco dCloud
Figure 45. Key/Value Pairs
NOTE: We are using **2 to start recording and **3 to stop recording.
31. Click SEND.
32. Click the GET request in the dtmfProfiles folder. This will load the GET request in the right hand panel in Postman.
33. Click SEND. The system will return the ID of the newly created DTMF profile as shown below.
Figure 46. DTMF Profile
34. Save the DTMF Profile ID in Notepad for use in the next step.
Cisco dCloud
Add Call Leg Profile, Call Profile, and DTMF Profile To System Profiles
35. Under the Recorder-Config collection, click on the systemProfiles folder to expand it.
Figure 47. systemProfiles Folder
36. Click on the PUT request under the systemProfiles folder.
37. On the right panel of Postman, this will load the systemProfiles PUT request URL. Click the Body tab to display its key/value
38. Copy and paste the callProfile ID, callLegProfile and dtmfProfile IDs, saved previously to Notepad, to fill in the values in
the following key fields:
a. callProfile: <call profile ID attribute saved in the previous step>
b. callLegProfile: <call leg profile ID attribute saved in the previous step>
c. dtmfProfile: <dtmf profile ID attribute saved in the previous step>
Figure 48. systemProfiles PUT Contents
39. Click Send.
40. Change the request type to GET and click Send.
Cisco dCloud
Figure 49. Change PUT to GET
41. The response should contain the call profile and call leg profile that were added to the system profiles. Minimize Postman.
Cisco dCloud
Task 4: Test Manual Recording
Test Recording
1. Call the Space recorder.space (or any space) the Cisco Meeting App on wkst1.
2. Call the same space (recorder.space@dcloud.cisco.com) from the DX70 and from Jabber on wkst3.
3. After the devices joined the conference, click on the Record button at the top of the Cisco Meeting App window.
4. You will hear the announcement “This call is being recorded” and see a red dot to indicate recording.
5. If your laptop is NOT connected with a dCloud router, skip this and move on to step 6. Otherwise, continue onto steps a – f
below.
NOTE: Steps a – f gives you the experience of using WebRTC compatible browser to join a Space conference. Current WebRTC
compatible supported browsers are Firefox and Chrome.
a. Open a Firefox or Chrome and browse to https://join.dcloud.cisco.com.
b. If prompted with This Connection is Untrusted click I Understand the Risks.
c. Click Add Exception.
d. Click to Confirm Security Exception.
e. Click Sign in and enter:
i. Username: cholland@dcloud.cisco.com
ii. Password: C1sco12345
Figure 51. Sign in
f. Click Sign in.
NOTE: Charles Holland is logged in thru the WebRTC browser client.
g. Click New Call [ ] in the upper left.
h. Type recorder.space in the box, click the [ ] next to video icon and select Use this device.
Cisco dCloud
Figure 52. Dial Conference Number
i. Charles Holland joined the Remote Recorder’s Meeting along with the DX70 and Cisco Meeting App and should
see the recording indicator on the top.
Figure 53. Joined CMS Space
j. To hang up the call, click on Leave.
6. Talk or make some noise for 30 seconds or more.
7. Hang up the call from all endpoints.
8. Access the shared recordings folder under Network->AD1.
9. Using Windows File Explorer, locate and open the spaces folder. Observe the MP4 recordings under one of the folders.
10. Click on the MP4 file to play back the recording.
Cisco dCloud
Figure 54. Location of Recording
11. Test again but connect to the space with an endpoint or Jabber. Use DTMF to start/stop the recording (**2 to start, **3 to
stop).
Cisco dCloud
Scenario 4: Configure CMS to be a Streaming Server

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 external streaming server. For our lab, we will test using YouTube. The stream can be viewed from any device that can connect
to the YouTube service.
The Streamer connects to an external server using RTMP with an overall bitrate of 2Mbps. The video is encoded using H.264 at
720p30, while the audio is 64kbps AAC-LC. All traffic between the Streamer and the external streaming server is unencrypted. The
Streamer should be hosted on another Meeting Server instance than the server hosting the Call Bridge. If the Streamer is hosted
on the same server as the Call Bridge (local), then it should only be used for testing purposes.
Figure 55. Streamer
The Streamer also supports redundant configurations as shown in the figures below. If you use multiple streamers, the solution
load balances between available streaming devices. To restrict the use of specific Streamers to specific Call Bridges, use the Call
Bridge Group functionality.
Cisco dCloud
Figure 56. Permitted Deployments for Streaming: Multiple Streamers
Figure 57. Permitted Deployments for Streaming: Call Bridge Cluster
If your deployment has multiple Call Bridge and multiple Streamers then every Call Bridge will use every Streamer (see Figure
below), unless the callBridgeGroup and callBridge parameters have been set for each Streamer using the API to PUT to
/streamers/ .
Cisco dCloud
Figure 58. Permitted Deployments for Streaming: Call Bridge Cluster with Multiple Streamers and No Call Bridge Groups Set up
Figure 59. Permitted Deployments for Streaming: Call Bridge Cluster with Multiple Streamers and Call Bridge Groups
For purposes our our lab, we will use CMS3 as the streamer from our Call Bridge cluster.
Cisco dCloud
Task 1: Install the Certificate Bundle on CMS

IMPORTANT NOTE: If you have already completed the recorder Scenario 3, this step is completed and does not need to be
done here. Continue to Task 2.
When using a remote recorder, it needs to trust all of the Call Bridges that will connect to it. This is accomplished by installing a
trust bundle containing all of the certificates from the other servers plus the root certificate. The recorder process will trust all the
Callbridges included in the trust bundle. The trust bundle has been created for you and is located on wkst1 in the CMS folder.
Copy the Trust Bundle
1. Open the WinSCP application [ ] on wkst1.
2. Connect to 198.18.134.147 (CMS3).
a. Log in with password dCloud123!
Figure 60. Login
3. Drag the file cmsbundle.crt (located in the CMS folder on the desktop) to the CMS3 server.
Cisco dCloud
Figure 61. Drag cmsbundle.crt to the CMS3 Server
4. Close WinSCP.
6. Log in with:
a. Username: admin
7. At the cms3> prompt, enter: pki list
8. Verify that certificates cms3.key, cms3.crt, caroot.crt, and cmsbundle.crt are listed.
Cisco dCloud
Task 2: Set up Streamer on the Server Using CLI
Configure Streamer
2. Log in with:
a. Usenamer: admin
Recorder is an XMPP client and requires the enablement of the XMPP server.
IMPORTANT NOTE: If you have already completed the Recorder Setup in Scenario 3, this step has been completed.
Continue with Step 23.
3. At the cms3> prompt, enter the following commands:

xmpp disable
xmpp listen a
xmpp certs cms3.key cms3.crt caroot.crt
xmpp domain dcloud.cisco.com
xmpp enable
Figure 62. PuTTY Commands and Success Message
4. You must authenticate the Callbridge to the XMPP service. Open a web browser and view the CMS3 web admin interface at
https://cms3.dcloud.cisco.com:445.
5. Log in with:
a. Username: admin
6. Navigate to Configuration->General and note the name of the Call Bridge under XMPP server settings.
Cisco dCloud
Figure 63. Note the Call Bridge Name
7. Add the Callbridge to XMPP using PuTTY and the command line for CMS3.
a. Enter: xmpp callbridge add <Callbridge Name from Step 7>
8. You will see a result similar to what is shown below:
Figure 64. Call Bridge to XMPP
9. Make note of the Secret shown. You will need it in the next step. If you miss it, you can find it again by entering xmpp
callbridge list from the cms3> prompt.
10. Return to the web admin page, Configuration->General. On the line for Shared Secret, click change. Enter the secret key
from above for both Shared Secret and Confirm Shared Secret. Be sure to click Submit at the bottom of the page to save
your changes.
11. Verify that the XMPP service is active and has no errors. On the web admin interface for CMS3, navigate to Status->General.
The XMPP connection should say connected and the Authentication service should be registered.
12. Continue to enter the following commands:

streamer listen a:8445
streamer certs cms3.key cms3.crt caroot.crt
streamer trust cmsbundle.crt
streamer enable
Cisco dCloud
Figure 65. Add Recorder Commands to CMS1 with Success
NOTE: This lab uses a remote streamer, and the streamer must therefore listen on an appropriate network interface e.g. a:8445.
Otherwise, the recorder can listen on the network interfaces a – d.
The streaming destination URL will be setup in a later step as it can be unique to a Space.
13. Finally, to view the streamer details, enter the command streamer.
Cisco dCloud
Task 3: Configure Streamer for Automatic Streaming using API
Configure API
Username: dcloud\cholland and Password: C1sco12345
2. If PuTTY has closed, from the Desktop, launch PuTTY [ ].
3. SSH to 198.18.134.147 (CMS3) and log in with User admin and Password dCloud123!.
4. Continuing from Task 1 in PuTTY at the command prompt type: user add api api
NOTE: Configure an API user that the Postman tool utilizes to authenticate with CMS for making API calls.
5. At the Please enter new password enter dCloud123!.
6. Confirm the password.
Figure 66. Create User API
Import the JSON Files to Postman
Username: dcloud\cholland and Password: C1sco12345.
9. Click Import on the top left of the window.
Figure 67. Import
10. If not selected, click the Import File tab.
11. Click Choose Files.
Cisco dCloud
Figure 68. Choose File to Import
12. Browse to the Desktop->CMS Update Lab and select the Streamer-Config.json file.
Figure 69. Choose the Streamer-Config.json file
13. Click Open.
Create a Streamer Object
14. In the Postman left panel, under Streamer-Config collection, click on the streamers folder to expand the folder.
Figure 70. streamers Folder
15. Click on the POST request under the streamers folder.
Cisco dCloud
16. On the right panel of Postman, this will load the streamers POST request URL. Click the Body tab to display its key/value
Figure 71. streamers POST Body Contents
17. Click Send.
NOTE: This creates a remote streamer entry in the CalIBridge that points to CMS3 port 8445 that was setup previously.
Create a callProfile
A callProfile defines whether calls can be recorded and if they can be done with or without user intervention.
18. Under the Streamers-Config collection, click on the callProfiles folder to expand it.
Figure 72. callProfile Folder
19. Click on the POST request under the callProfiles folder.
Cisco dCloud
20. On the right panel of Postman, this will load the callProfiles POST request URL. Click the Body tab to display its key/value
Figure 73. POST callProfile Key/Values
NOTE: Set the streamingMode parameter in call profile. Manual allows user to start/stop streaming manually, Automatic allows
the streaming to start automatically when the call is launched. This lab uses Automatic.
21. Click Send.
22. Click on the GET request under the callProfiles folder.
Figure 74. GET Request
Cisco dCloud
Figure 75. GET Contents
24. Click Send. The response should show the call profile ID.
Figure 76. callProfile ID
25. Save the callProfile id attribute to notepad for later use.
26. Validate it is the correct profile if more than one exists. THIS IS IMPORTANT!
Add Call Profile to the Remote Streaming CoSpace
27. Under the Streamer-Config collection, click on the cospaces folder to expand it.
Figure 77. cospaces Folder
28. Click on the GET request under the cospaces folder.
29. On the right panel of Postman, this will load the cospaces GET request URL. Click the Send tab and review the results.
a. Find the coSpace id for the streaming.space coSpace
Cisco dCloud
b. Copy this ID to notepad for later use.
Figure 78. coSpace id for streaming.space coSpace
NOTE: Save the coSpace ID to Notepad for later use.
30. Go to a web browser and log in to Youtube.com using the lab credentials provided on your lab sheet. There are not enough
lab accounts for everyone, so we are sharing 5 accounts. If your account is already in use, please wait until it becomes free.
NOTE: You can also use your personal YouTube credentials if you prefer.
31. Once in YouTube, go to My Channel, then Video Manager. Click on the Video Manager Tab, and then Live Streaming.
Figure 79. Live Streaming on YouTube
32. On the Live Streaming page, there is a section at the bottom labeled Encoder Setup. Click the Reveal button to show the
stream name key. Copy the Server URL and the Stream Name/Key to Notepad.
Cisco dCloud
Figure 80. Server URL and Stream Name/Key
33. Return to Postman and click the PUT request under the cospaces tab. This will load the cospaces PUT request in the right
hand window. Click on Body to see the parameters.
34. At the end of the PUT request URL, add a slash “/” and paste the CoSpace ID you saved earlier from Notepad.
35. Click on Body to see the parameters.
36. In the streamURL, add the information you saved from YouTube (the Server URL and the Stream Key).
37. Copy and paste the callProfile ID you saved from the previous step into that variable.
Figure 81. coSpace
38. Click Send.
39. To verify the result, change POST to GET and click Send again.
40. The response should look like the figure below.
Cisco dCloud
Task 4: Test the Streamer with YouTube

Since we set up the streamer for to begin automatically when someone calls the space streamer.space, testing it is easy.
1. Log in to YouTube with your browser using the test account assigned to your lab pod.
2. Go to Live Streaming, Stream now.
3. The screen should look like the figure below.
Cisco dCloud
Figure 83. Streaming on YouTube
4. Connect to the streaming.space with any client. You can use the Cisco Meeting App, dial in from an endpoint, or join via a
browser.
5. For our example, we will connect using the Cisco Meeting App.
Figure 84. Connecting to streaming.space
6. If everything is configured correctly, you should see the stream startup on YouTube in just a few seconds.
7. You can add additional calls to the meeting and all the calls will be streamed.
Cisco dCloud
Figure 85. Streaming on YouTube
Cisco dCloud
Scenario 5: PREVIEW – Expressway Unified Edge

In order to collapse edge services into a single Unified Edge using Expressway instead of a CMS edge server, Cisco Expressway
X8.9 supports traversal of SIP traffic at the edge of the network, to and from the Cisco Meeting Server. This allows collaboration
using Cisco Meeting spaces between on-premise Cisco Meeting App or SIP endpoint users, and users external to the network who
are using standards-based SIP endpoints, Microsoft Skype for Business or Microsoft Office 365. Cisco Expressway does not
currently support traversal for external Cisco Meeting App users. Cisco Expressway X8.9 is also previewing a Cisco Meeting
Server web proxy to enable off-premise users to join meetings held in spaces using a web browser supporting WebRTC. This
feature is being enhanced in each release of CMS and Expressway. Detailed deployment options are covered in the document:
Cisco Expressway Options with Cisco Meeting Server and/or Microsoft Infrastructure Deployment Guide.
Figure 86. Examples of Possible Communications Scenarios with Expressway Edge
Task 1: Create a Certificate for CMS Edge Guest URI

1. From wkst1, log in to Expressway-E administrator session.
2. Go to https://exp-e-1.dcloud.cisco.com and log in.
a. Username: admin
3. Navigate to Maintenance->Security Certificates-> Trusted CA Certificate and verify that there is a certificate for
CN=dcloud-AD1-CA present.
Cisco dCloud
Figure 87. Certificate for CN=dcloud-AD1-CA
4. Navigate to Maintenance->Security Certificates->Server Certificate. A server certificate already exists. You can view it by
clicking the Show (decoded) button. We need to recreate this certificate to include everything it has at present, plus the CMS
guest URI join.dcloud.cisco.com.
5. To generate a new Certificate Signing Request, click on Generate CSR.
Figure 88. New Certificate Signing Request
6. On the Generate CSR page, add join.dcloud.cisco.com as an Additional Alternative Name. Leave everything else on the
page as is (it will be pre-populated).
7. Click Generate CSR.
Cisco dCloud
Figure 89. Generate CSR
8. Click on Download under Certificate Signing Request to download the CSR to wkst1. You can place it on the desktop or
any convenient place where you can easily find it. Firefox will default to saving the file in the Downloads folder.
Figure 90. Certificate Signing Request
9. Create the certificate. Open a command prompt and enter “certreq –submit –attrib
“CertificateTemplate:Webclientandserver” C:\Users\cholland\Downloads\<CSR File Name> as shown below. Save
the certificate to the Downloads folder as exp-e-1.crt.
Cisco dCloud
Figure 91. Create Certificate
10. Upload the new certificate. Click Browse in the Upload New Certificate section and select the file for the new certificate.
Then click Upload server certificate data.
Figure 92. Upload New Certificate
11. The system will display a message at the top of the screen when the certificate is uploaded and accepted. Click restart twice
to restart the Expressway and make the certificate active.
Figure 93. Restart Expressway and Activate Certficate
12. After the system restart is complete, the new certificate will be in place
Task 2: Enable TURN Services on Expressway-E

1. Log in to Expressway-E at https://exp-e-1.dcloud.cisco.com.
a. Username: admin
Cisco dCloud
2. Navigate to Configuration->Traversal->TURN.
3. Set Turn services to On.
4. Set the Authentication realm to dcloud.cisco.com.
5. Click Save.
Figure 94. Enable TURN Services on Expressway-E
6. Note the two IP addresses shown on the status display. Expressway typically has two interfaces – one facing to the “inside”
that is used by the Expressway-C to establish an encrypted tunnel so traffic can be proxied inward. The other facing to the
“outside”. The outside interface is where traffic is routed through the firewall to the Expressway-E. This means no ports need
to be opened from the outside directly to the inside network to support services.
a. 198.18.1.0/24 network is the inside in our lab
b. 198.18.2.0/24 network is the outside in our lab
Cisco dCloud
Task 3: Enable the Web Proxy in Expressway

1. Verify that connectivity is not enabled. Using your RDP client, connect to wkst2 at 198.18.2.37
a. Username: dcloud\aperez
2. Open Firefox and navigate to https://join.dcloud.cisco.com
3. Instead of going to the Meeting Server login screen, you get the default login screen for the Expressway. Your request was not
proxied through to the Meeting Server.
Figure 95. Default Expressway Log in Screen
4. Because of this behavior, it is recommended in a production deployment that you change the default port used by the
Expressway for administration services. Details are in the documentation. Now let’s correct that problem.
5. Log in to Expressway-C at https://exp-c-1.dcloud.cisco.com
a. Username: admin
6. Navigate to Configuration->Unified Communications->Cisco Meeting Server.
7. Set the Meeting Server Web Proxy to Enable.
8. Add the Guest account client URI as join.dcloud.cisco.com.
9. Click Save
10. You should see a successful completion message that shows both the CMS1 and CMS2 servers as shown below.
Cisco dCloud
Figure 96. Successful Completion Message that Shows Both the CMS1 and CMS2 Servers
11. It is also necessary to add DNS records on the inside and outside DNS for the guest URI to allow clients to resolve the name.
The DNS A record for join.dcloud.cisco.com has already been added to the External DNS and points to the Expressway-E
outside interface.
Task 4: Test Connectivity from the Outside

1. Using your RDP client, connect to wkst2 at 198.18.2.37.
a. Username: dcloud\aperez
2. Workstation wkst2 is on the outside. You can verify this by looking at Jabber. If you navigate to Settings->Help->Show
Connection Status, you’ll see that the connection shows as -Expressway, indicating it is an MRA connection through the
Expressway.
Figure 97. Verify Workstation 2 is on Outside
3. Open Firefox and navigate to https://join.dcloud.cisco.com.
Cisco dCloud
4. You should see the Cisco Meeting Server login screen. Log in to Meeting Server:
a. Username: aperez@dcloud.cisco.com
5. You should see Anita Perez’ client. Connect to Anita Perez Meeting Space.
6. From the DX70, call into the same space: aperez.space@dcloud.cisco.com.
7. There should be no difference between the call into the Meeting Server from the DX70 on the inside and the connection via
the browser on the outside.
Figure 98. Meeting
8. Log out of the browser and open the Cisco Meeting App on wkst2.
9. Log in from the Meeting App.
a. Username: aperez@dcloud.cisco.com
10. The connection should FAIL. The Meeting App is not supported via Expressway at this time. If customers need to support the
meeting app from the outside, they will need to deploy the Meeting Server TURN services at the edge. This will be addressed
in a future release.
Cisco dCloud
Figure 99. Meeting Sign in
This concludes this Scenario.
Cisco dCloud
Scenario 6: PREVIEW – Cisco Meeting Management

Cisco Meeting Management (CMM) is a new tool being developed specifically to manage Cisco Meeting Server. In its final form,
CMM will provide active meeting management, help deploy new servers, configure the API, and provision users and spaces with
required features. CMM will use CMS APIs and CDRs, extending the functionality with a graphical user interface for easier
deployment and management.
TMS continues to provide scheduling services and endpoint management.
CMM will be developed in phases over time. We are fortunate to have an early version of the software to PREVIEW in our lab so
you can get a view of what the CMM platform GUI will look like and a beginning understanding of how you will be able to use it. In
this version, CMM allows control of active meetings running on CMS servers. This is unreleased alpha software. It is a PREVIEW
only. There are many features that are not complete yet and it does not directly reflect the version that will FCS. FCS is planned for
the July/August 2017 timeframe.
The figure below shows the solution architecture for CMS and CMM deployments. CMM runs as a separate VM. CMS servers are
added to CMM via the GUI.
Figure 100. Solution Architecture for CMS and CMM Deployments
Task 1: Add CMS Servers to CMM

1. RDP to Workstation 1 (198.18.1.36) and, if necessary, log in as Charles Holland.
2. Using the CHROME BROWSER, navigate to https://demo-cmm-sevt.dcloud.cisco.com and log in.
a. Username: admin
b. Password: cisco
Cisco dCloud
Figure 101. CMM Sign in
3. You are taken to the Overview dashboard. In future releases, the Overview will be the single place to view the status of you
entire CMS system (single, cluster, distributed) and will show information like the number of active calls, total spaces, and
number of meetings. A conceptual diagram is included below. In our early PREVIEW version of the system, no information is
yet displayed on the overview page.
Cisco dCloud
Figure 102. CMS Management
4. To add the CMS servers into CMM, click on Servers on the left hand navigation tab, then click Add Server at the top right of
the page.
Cisco dCloud
Figure 103. Add CMS into CMM
5. Fill in the host name, port, admin user name, and password on the add server screen as shown. This version of CMM does
not let us add certificates so UNCHECK the box HTTPS Verification. When all the fields are filled in, click Add.
Figure 104. Add Server
Cisco dCloud
6. Because in the lab CMS1 and CMS2 are setup as a cluster, when you add CMS1 to the CMM portal, it will display it as well as
the notation that there is 1 unmanaged. If you click show, you will see that it found CMS2 as part of the cluster. Also note that
the server is showing unverified. That is because we disabled HTTPS verification when adding the server.
7. From here you can rename the cluster, delete the cluster, edit servers in the list, or add more servers.
8. Go ahead and add CMS2 and CMS3. Notice that CMS3 appears as a different cluster; not part of the CMS1/CMS2 cluster.
9. Rename the first cluster as CMS_Cluster and the second as Recorder-Streamer. This gives the users a good idea how the
system is laid out. The names could be based on region, business unit, or whatever makes sense for the customer.
Figure 105. First cluster as CMS_Cluster
10. From the Cisco Meeting App on wkst1, join Charles Holland’s Space.
11. From there, invite Anita Perez and Monica Cheng and add them to the conference.
12. Dial into cholland.space@dcloud.cisco.com from the DX70.
13. You should now have four participants in the meeting.
14. If you click on the Meetings tab on CMM, you should see the active meeting displayed. Note it includes the start time, duration,
and number of participants.
Cisco dCloud
Figure 106. Join Charles Holland’s Meeting Space
15. Click on the meeting to open the details. From here you have a great deal of control and visibility. You can see who the
participants are and when they joined. If anyone left, they will show up too. You can add other participants, start recording or
streaming, look at the event logs for this meeting, or end the meeting.
Figure 107. Charles Holland’s Meeting Space
16. Click on the Recording button to add the recorder to the meeting. Notice the recorder has been added to the meeting. Press
Recording again to stop the recording.
Cisco dCloud
Figure 108. Recording Button
17. Click on Event Logs. You can now see all events pertaining to this meeting that were recorded by the CMS server hosting the
meeting.
Figure 109. Event Logs
Cisco dCloud
18. Click on a User to open the details panel. You can mute audio or video for the user, change their screen layout, drop the user
from the conference, and see key statistics about the audio, video, and screen share for that user.
Figure 110. User Details
19. Lastly, click End Meeting. The meeting will end for all participants.
Figure 111. End Meeting
20. Take some time to explore the interface. Test out the capabilities. The current planned release date is in the July/Aug 2017
timeframe. The addition of CMM will bring greatly enhanced management capabilities to customers.
Cisco dCloud
This concludes this Scenario.

Cisco Meeting Server Feature Update Lab v1: About This Demonstration

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cisco Meeting Server Feature Update Lab v1: About This Demonstration

Încărcat de

Drepturi de autor:

Formate disponibile

Cisco dCloud

Cisco Meeting Server Feature Update Lab v1

Created in Partnership with the Collaboration VT Lab Owners.

About This Demonstration

• About This Solution

• Scenario 1: Active Control

• Scenario 3: Configure CMS as Meeting Recorder Server

• Scenario 4: Configure CMS to be a Streaming Server

• Scenario 5: PREVIEW – Expressway Unified Edge

• Scenario 6: PREVIEW – Cisco Meeting Management

• Laptop with Cisco AnyConnect® • None

About This Solution

Benefits of migrating to the Cisco Meeting Server solution:

• One software solution for audio, video and web conferencing

• Scalable conferencing with WAN bandwidth optimization

• Integration with other workplace tools via API

• Support for immersive Cisco TelePresence® endpoints

Personal Multiparty Plus License

Shared Multiparty Plus License

Figure 1. CMS Lab Topology

Table 2. Server Details

Name Description Host Name (FQDN) IP Address Username Password

IM & P IM & Presence 11.5 imp1.dcloud.cisco.com 198.18.133.4 administrator dCloud123!

CUxN Cisco Unity Connection 11.5 cuc1.dcloud.cisco.com 198.18.133.5 administrator dCloud123!

CMS2 Cisco Meeting Server v2.1.7 cms2.dcloud.cisco.com 198.18.134.185 admin dCloud123!

CMS3 Cisco Meeting Server v2.1.7 cms3.dcloud.cisco.com 198.18.134.147 admin dCloud123!

Exp-C Expressway-C (Core) X8.9.2 exp-c-1.dcloud.cisco.com 198.18.133.152 admin dCloud123!

Exp-E Expressway-E (Edge) X8.9.2 exp-e-1.dcloud.cisco.com 198.18.1.152 admin dCloud123!

Exchange Microsoft Exchange 2010 mail1.dcloud.cisco.com 198.18.133.2 administrator C1sco12345

AD1 AD (Win2K8) and DNS server ad1.dcloud.cisco.com 198.18.133.1 administrator C1sco12345

CMM Cisco Meeting Management (Pre-release) dem-cmm- 198.18.135.56 admin cisco

Workstation 1 Windows 7 wkst1.dcloud.cisco.com 198.18.133.36 cholland C1sco12345

Workstation 2 Windows 7 - OUTSIDE wkst2.dcloud.cisco.com 198.18.2.37 aparez C1sco12345

Workstation 3 Windows 7 wkst3.dcloud.cisco.com 198.18.133.38 mcheng C1sco12345

Table 3. User Information

User Name User ID Password Endpoint Devices Phone Extension Workstation

PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.

3. Schedule a session. [Show Me How]

4. Test your connection. [Show Me How]

NOTE: It may take up to 30 minutes for your session to become active.

6. Click View to open the active session.

Scenario 1: Active Control

• Indicator of audio activity for the currently speaking participant

• Indicator of which participant is currently presenting

• On-screen message which will be displayed to all participants

CMS supports these administrative tasks on ActiveControl enabled endpoints:

• select the layout to be used for the endpoint

• disconnect other participants in the meeting

Overview on ActiveControl and the iX Protocol

Task 1: Create a Test Space in CMS

2. Using your browser navigate to https://cms1.dcloud.cisco.com:445 and log in:

3. Go to Configuration > Spaces.

a. Name: Test Space

b. URI user part: 7000

5. Click Add New.

Figure 2. Space Configuration

Task 2: Creating a SIP Profile in Unified CM

1. From a browser, log in to https://ucm1.dcloud.cisco.com.

3. Click Standard SIP Profile for Telepresence Conferencing.

Figure 3. Creating SIP Profile

Task 3: Test Active Control Using the Test Space

Figure 4. Meeting Participants List

Figure 5. Drop Call