Live Streaming (Webcast) integration with VBrick DME allow users to watch any live streamed CMS conference anywhere inside the network from different devices. Additionally, when VBrick Rev is used along VBrick DME, this extends this capability for viewing from outside the internal network for every VBrick Rev authorized user.Also, CMS Uploader component simplifies the work flow for uploading Meeting Server recordings to the video content manager, Vbrick, from a configured NFS connected to a Meeting Server. No manual importing of recordings is required. Once the Uploader component is configured and enabled, recordings are pushed from the NFS to Vbrick. Uploader creates recording meta data, then uploads recording to Vbrick Rev.
Deploy SIP-based Streamer (Version 3.0 or later):
- CMS Callbridge(s) Version 3.0 or later with Recording/Streaming license(s). (one recording license will allow one streaming call)
- Vbrick DME (used for publishing the live stream from CMS Streaming service)
- Vbrick REV (optional: only required if Live Streaming need to be shared outside internal network)
Note : The CMS server(s) hosting the Callbridge service is the location in which the Streaming/Recording License generated for and installed, not the CMS server acting as the Streamer server.
Note : Cisco recommends if you are running a CMS hosting SIP-based streaming service, running 3.0 or later, the minimum requirements are still 4vCPUs/4GB RAM. However, the number or streams are dependent on the call quality as well. Refer to the chart after this tip for more information.
Uploader
As of Cisco Meeting Server 2.3, Cisco has created a new component of CMS, called the Uploader. The uploader component is specifically designed to take recordings created by CMS, create revelevant meta data for them, and upload them to Rev Cloud or Rev On Premise. This feature is presently considered a preview, but is fully supported by Cisco TAC.
The CMS upload is required to be on a separate VM from the VM hosting the call bridge, but can be collocated with the recorder VM. If installed on the same server as the Recorder, then add a couple of vCPUs for it to use. If run on a different server, then use the same server specification as for the Recorder: dedicated VM with a minimum of 4 physical cores and 4GB of RAM.
Both the recorder VM and the uploader VM will need read/write access to the NFS host for (temporary) storage of the video recordings. The uploader can be configured to delete recordings from the NFS share following succesfull upload to Rev.
LIVE STREAM INTEGRATION
As of Cisco Meeting Server version 2.1, any CoSpace can be configured to send a live stream as an output mechanism to a Vbrick DME. After configuring the ‘streamer’ object per the appropriate CMS documentation, an administrator will need to configure if a CoSpace is set to stream automatically, such as when the first user joins a meeting, or is set to stream manually, when a user presses configured DTMF controls. In either case, individual CoSpaces must be set via CMS API with a streamURL parameter in the format of:
<streamUrl>rtmp://broadcast:broadcast@[DME_FQDN]/live/[STREAM_NAME]</streamUrl>
There is only one stream URL configured per CoSpace, regardless of how many streamer objects are instantiated on the CMS cluster. When streaming is initiated, the streamer object will create 2Mbps 720p stream and send it to the configured DME via RTMP Push. The DME can then reflect the live stream throughout the Vbrick Rev and DME ecosystem, include it in live webcasts, and record it for later playback:
From a deployment methodology perspective, it is important to note that each CoSpace can only support one output stream, and each unique output stream needs to be configured on the recipient DME for either transmux to HLS or delivery to other DMEs. As such, there are two common configurations for deploying CMS live streaming across an organization:
• Several shared CoSpaces dedicated to the purpose of live streaming to large audiences. With this option, administrators would configure several dedicated CoSpaces, each with a unique stream URL defined. Thus a user wanting to host an event would reserve one of these dedicated cospaces and chose a corresponding presentation profile in Rev
• A larger number of independent CoSpaces leveraging a shared streaming URL. In this methodology, only a single URL would be configured on the recipient DME, with the CoSpace of each user set to the same URL. In this case, each user would be capable of hosting an event on their own CoSpace, but only one user could do so at a time.
The minimum CMS ‘streamer’ configuration includes 4 vCPU and 4 GB vRAM and supports up to 24 simultaneous streams. In the event more than one CMS streamer is used, one unique DME per streamer object is required.
Demystify and Simplify 