Content channel video support

The MCU supports an additional video channel known as the content channel for each conference. This feature encompasses:

H.239 video streams sent from the MCU to viewing H.323 endpoints
Sourcing the content channel from an H.323 endpoint's H.239 video stream or a SIP endpoint supporting content using BFCP
Streaming the content channel to users' desktop machines as a pane in the conference view
Streaming the content channel to users' desktop machines as a separate window (where markup and text chat can also be used)^(*)
Showing the content as part of the main video channel, where an endpoint cannot, for whatever reason, receive the content channel as an additional video channel. That is, the participant will see the content as a pane in the conference layout
Content

Content channel vs. main video

The H.239 protocol allows the MCU to support an additional video stream to or from each connected endpoint. Therefore, there are potentially three media streams between each endpoint and the MCU: audio, main video and content video.

The main video is the normal multi-pane conference view showing participants' video streams composed within the selected layout. The differences between the content channel video and the main video are:

Single layout
Each participant in a conference can normally select their own individual main video layout (e.g. a 2 x 2 grid of other participants, one large focused pane plus eight smaller panes) and they are free to change this layout as many times as desired while they are connected to the conference.
By comparison the content channel video always shows just a single video stream, "full screen", and each viewing endpoint will see the same stream. The stream which constitutes the content channel can change any number of times during the conference, but there can be at most one contributing stream at any given moment.
One channel per conference
Each participant's main video stream is encoded independently; this means that each endpoint can be receiving its main video stream at a different bit rate, codec, or resolution to that being sent to other participants.
However, there is a single content video stream per-conference: the MCU sends the same bit rate and resolution to all endpoints receiving content. The bit rate and resolution used is chosen to maximize the number of viewers - for instance the resolution might be reduced if a new endpoint joins the conference and its content receive capabilities are more limited than those of the other participants. Note that in conferences that use encryption, the MCU can send encrypted and unencrypted content to different participants in the same conference (albeit with the same encryption key for every participant receiving encrypted content).
Differing characteristics
The range of bit rates, resolutions and frame rates available to the MCU for sending the content channel via H.239 to H.323 video conferencing endpoints is potentially as wide as that for the main video channel. However, in general, the main video channel is used for motion video (i.e. high frame rate streams) and the content channel for less dynamic video such as an accompanying presentation - typically high resolution, low frame rate.
However, the MCU allows flexibility in terms of nominating which of the available streams forms the content channel, as well as allowing control over which endpoints are permitted to start contributing content video.
Uni-directionality
For the main video channel, a video conferencing endpoint would normally be both contributing (sending) a video stream to the MCU and receiving a video stream from it.
However the content channel works differently in that an endpoint can either be sending content video or receiving content video, but not both. A given endpoint may switch between being the contributor and a viewer during the conference, but it will never be both simultaneously.

Passthrough and hybrid content

In versions prior to 4.3, the MCU always decoded the incoming content stream and then re-encoded it using either H.263+ or H.264 before sending it out. This original mode is called Transcoded content. As of version 4.3, the MCU can be configured to pass-through a content stream without transcoding it to participants that can support the same content codec as the source content stream. This can reduce latency and increase quality and does not require a video port on the MCU. This is known as Passthrough content.

There are drawbacks with both of these content modes. In Transcoded mode, all participants will see the content encoded with the specified outgoing transcoded codec and a single participant could reduce the quality for other participants if it had limited codec support. In Passthrough mode, the MCU does no transcoding for content, which means that fewer endpoints may be able to decode the passed through content.

Hybrid content mode helps to avoid these drawbacks. In Hybrid mode, the incoming content stream is passed through to participants who are able to support the same codec as the original content stream (the Passthrough content stream). The MCU also encodes a second content stream with the specified outgoing transcoded codec for participants who cannot decode the original Passthrough content stream. Hybrid content mode uses up a video port.

The Outgoing transcoded codec for the content stream can be explicitly specified (either H.263+ or H.264) or set to Automatic.

To edit these settings, go to the Content section of the conference's configuration page (go to Conferences then click on the conference name).

H.323/SIP endpoints' content channel support

For H.323 endpoints, depending on the specific endpoint and how it is configured, the content video stream may be displayed on a separate screen, or the endpoint may show the main video and the content video streams side by side on the same screen.

Irrespective of its content receive capability, an endpoint may or may not be able to contribute the content channel - typically, for this to be possible it will either need a second camera or some other video input such as a VCR or "video in" connection.

Some H.323 endpoints may have no support for the H.239 protocol. However, it is still possible for such endpoints to display the content channel - the MCU is able to show the content channel within a normal view pane in the same way as it displays other conference participants. This ability is controlled by the unit-wide/blade-wide Display content in normal video channel setting (see Configuring content settings).

Content channel sources

As described above, a conference's content channel as sent to the set of receiving endpoints has a single source. There are several possible content channel sources:

H.239 video channel
This is the most conventional content channel behavior - a H.323 conference participant opens a H.239 channel to the MCU and contributes a video stream, such as that supplied by a second camera or an attached PC.
Because there can be at most one content channel source, the H.323 endpoint needs to make a request to the MCU, and have that request accepted, before actual content channel contribution can start. If the conference already has an active content channel (for example, another endpoint is contributing H.239 video), the new request will be rejected by the MCU - it will be necessary to wait for the active contributor to cease sending H.239 video before the new endpoint is able to start. However, if you have enabled Automatic content handover (on the Settings > Content page), the new request will be granted automatically.
BFCP video channel
BFCP (Binary Floor Control Protocol) is a protocol that allows for an additional video channel (known as the content channel) alongside the main video channel in a video-conferencing call that uses SIP. A SIP conference participant opens a BFCP channel to the MCU and contributes a video stream, such as that supplied by a second camera or an attached PC.
Because there can be at most one content channel source, the SIP endpoint needs to make a request to the MCU, and have that request accepted, before actual content channel contribution can start. If the conference already has an active content channel (for example, another endpoint is contributing content video), the new request will be rejected by the MCU - it will be necessary to wait for the active contributor to cease sending content video before the new endpoint is able to start. However, if you have enabled Automatic content handover (on the Settings > Content page), the new request will be granted automatically.
Note that the transmission of SIP content using BFCP is not supported on encrypted calls in any content modes. To allow content to be transmitted over SIP calls in a separate channel from main video, disable encryption on the MCU or on the target endpoint.
Participant main video
It is also possible for the MCU to use a endpoint's main video channel as the conference's content channel (when in Transcoded or Hybrid content modes).

MCU content channel configuration

Unit-wide or Blade-wide configuration

At the MCU-wide level, the MCU can be configured to disallow the use of conference content channels completely.

You can choose to enable encryption on the MCU. When encryption is used, the content channel will be encrypted.

For more information on these configuration parameters, see Configuring content settings and Configuring encryption settings.

Per-conference configuration

Assuming that content is enabled on the MCU unit-wide/blade-wide, each scheduled conference can be independently configured to allow content channel operations or not. If enabled, this has an impact on the conference's port usage; if disabled, then all attempts by participants in that conference to open a content channel to the MCU will be unsuccessful.

If the MCU is configured to allow encryption, each individual conference can be configured to either require encryption or to optionally use encryption. The MCU can send either encrypted or unencrypted content to different participants in a conference depending on the capabilities of those participants' endpoints.

For more information on the conference configuration parameters relevant to the content channel, see Adding and updating conferences.

Per-participant parameters

Content contribution

Content contribution refers to the ability of video conferencing devices to contribute the content channel video for a conference via the mechanism of opening a separate video channel, distinct from its main video stream. Specifically, this section does not deal with the use of content by the MCU when sending content channels to viewing devices or the use of other protocols to supply the content channel video for a conference.

For a conference configured with content channel video enabled, each endpoint in that conference is either permitted or prohibited from being able to contribute content video. H.239 is the protocol used by H.323 video conferencing endpoints to supply or receive content channel video; BFCP is the protocol used by SIP video conferencing endpoints to supply content channel video. Other content channel source configurations do not depend on any H.239 or BFCP contribution parameters.

Remember that what is termed Content contribution is more precisely described as the ability to start contributing content channel video via H.239/BFCP. The nature of the H.239 and BFCP protocols used between the MCU and endpoints is such that once an endpoint has successfully become the content source for a conference, the MCU is not then able to force that endpoint to stop contributing the content channel video.

While an endpoint is supplying the content channel for a conference, it is considered to be holding the virtual content token for the conference. This token must be relinquished before either another endpoint can start contributing video via H.239 or BFCP or a content channel source becomes active. This token is normally released by a specific endpoint operation (e.g. a "stop content " option), or by that endpoint leaving the conference. However, when Automatic content handover is enabled, the MCU will ask the endpoint (or computer) to return the token if there is another participant who wants to start contributing content.

When Automatic content handover is enabled, it allows another participant to start sending content without having to wait for the current content provider to stop sending content from his computer. In this case, the MCU will start sending the 'new' content to the participants in the conference and will ask the endpoint (or computer) that was originally providing content to return the token. Automatic content handover is a unit-wid/blade-wide configuration option on the Settings > Content page.

By default, participants' ability to contribute content video (technically, as above, to start contributing H.239 or BFCP video) is determined by the per-conference Content contribution from endpoints setting (Conferences > Add new conference).

The per-conference default Content contribution from endpoints setting can be overridden by individual endpoints' configuration. If such an endpoint's Content contribution setting is <use conference default> then the endpoint's ability to contribute content channel video will be determined initially from the conference setting. If the endpoint setting is <enabled> or <disabled> then this will override the conference setting and that endpoint will either always be prevented from using content, or always permitted (assuming the conference of which it is part is configured with content channel support). As well as being part of each endpoint's configuration, the Content contribution setting can also be specified when calling out to an endpoint by address.

Irrespective of per-conference or per-endpoint configuration parameters, if a conference is configured to allow content channel operations then it is possible to explicitly enable or disable individual conference participants' ability to use content via the web browser interface (assuming a user login with full conference control).

To change the content contribution setting for an active conference participant via the web interface, first navigate to that participant's Display page (go to Conferences and click the conference you want and then click on the name of the participant whose settings you want to change). If the conference has content enabled and the endpoint in question has content capabilities, you should be able to use one of the following controls:

allow participant to contribute content video
do not allow participant to contribute content video

If an endpoint's ability to contribute content video has been explicitly enabled or disabled via this mechanism, that enablement or disablement will take precedence over any current or future conference or participant configuration, even if the endpoint later moves to a different conference.

Use of main video as content channel

In addition to supporting the H.239 and BFCP protocols by which endpoints in a conference can supply the content channel video, the MCU also allows a participant's main video channel to be used for the content stream.

As detailed above, it is not possible to force an endpoint that has started to contribute content video to relinquish the virtual token that it holds. Thus, if you select an endpoint's main video channel to be the content channel source, this will only take effect if no other endpoint is supplying the content channel video stream (whether by H.239, BFCP, or through use of its main video stream). However, if you have enabled Automatic content handover on the Settings > Content page and you select an endpoint's main video channel to be the content source, this will take effect even if there is currently another content source in the conference.

To control the use of a participant's main video as the conference content channel source, the following controls are displayed on the per-conference participant list (next to the preview image of the video stream to which they relate):

use this participant's main video stream as the content channel
stop using this participant's main video stream as the content channel (revert to more conventional content channel behavior such as H.239)

In rare circumstances, if more than one participant's main video channel is configured to provide the content channel (for example where a participant configured in this way is moved to another conference where there is an existing participant providing his main video channel as the content channel), then all but the active (normally, first) one will be marked with the status: Content: unable to use main video as source

Port usage

Port reservation mode

Cisco TelePresence MCU 4200 Series and Cisco TelePresence MCU 5300 Series
If the MCU is operating in reserved mode, enabling content for a conference requires the use of an additional video port. A single video port is needed for all content channel operations, irrespective of how many viewers there are; for example, a conference involving five video endpoints (one of which is contributing a content stream and the other four viewing it) will require six video ports - Video ports to reserve should be set to 5, and Content channel video set to "Enabled" in this specific example.

In reserved mode, a conference with content enabled will require a video port for content operations even if no current participants are actively making use of content.

Note that for the Cisco TelePresence MCU 4203, there are separate ports for content. For more information, refer to MCU port matrix.

Cisco TelePresence MCU 4500 Series and Cisco TelePresence MCU MSE 8510
If the MCU is operating in reserved mode, enabling content for a conference does not use a video port; instead, content uses one of the additional content ports provided by your MCU. A single content port is needed for all content channel operations, irrespective of how many viewers there are; for example, a conference involving five video endpoints (one of which is contributing a content stream and the other four viewing it) will require five video ports and one content port - Video ports to reserve should be set to 5, and Content channel video set to "Enabled" in this specific example.

In reserved mode, a conference with content enabled will require a streaming and content port for content operations even if no current participants are actively making use of content.

For more information about the number and types of ports provided by your MCU, refer to MCU port matrix.

Unreserved mode

If the MCU is operating in unreserved mode, enabling content for a conference will require a port to be allocated when content channel operations are first attempted for that conference. For instance, this could be when a participant opens a content channel or a user starts viewing the content channel via their web browser. When the port is no longer needed for the conference's content channel (e.g. when the last remaining participant disconnects) the port will be released for use by future participants or conferences.

Ad hoc conferences

All of the above-mentioned features, for instance content video streams between the MCU and video conferencing endpoints, are available for use with both scheduled and ad hoc conferences.

However, whereas for scheduled conferences the availability of content is determined by a per-conference configuration setting, for ad hoc conferences it is only possible to enable or disable content on a device-wide basis. This is accomplished via the Content for ad hoc conferences option on the Content settings web page—if this is "Enabled" then any ad hoc conference on the MCU may use content; if "Disabled" then none may do so.

Ad hoc conferences are not permitted when operating in reserved mode.