Help contents > Managing conferences > Content channel video support

搜尋/列印  索引

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 a H.323 endpoint's H.239 video stream, a SIP endpoint supporting content using BFCP, or a VNC connection
• 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
• 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)^(*)
• Allowing graphical and textual "markup" of the content channel ^(*)

• Text chat between conference participants ^(*)

* - these features require the web conferencing feature key.

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.

SIP endpoints will always receive the content as part of the main video channel. That is, SIP endpoints will not receive the content channel as a separate video channel, but will see the content as a pane in the main video channel.

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.

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 and the MCU does not send the content channel video to SIP endpoints. 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. 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.
• VNC connection
  A VNC connection is one where the MCU has made a connection to a remote device (normally a desktop PC) and is receiving a video stream from that device; this is typically used for including a slide-based presentation in a conference.
  If Automatic content handling is disabled, and a conference is configured with content channel support, when a VNC "participant" is added to that conference, the MCU will attempt to use the VNC video as the content channel. This is normally the desired behavior; however, there are a couple of caveats:
  • If there is a video conferencing endpoint actively contributing content video then it will not be possible to immediately switch over to using the VNC video instead - the switch over will occur when the participant closes his content channel.
  • With more than one active VNC connection in a conference, the first will be used as the content channel source, and subsequent connections will be shown in main video layout panes, just as if the conference had no content channel facility. If the currently active VNC connection is either disconnected or its use as the content channel disabled, another VNC video stream will start to be used as the content channel.
  If Automatic content handling is enabled:
• If there is a video conferencing endpoint actively contributing content video, the MCU will automatically switch to using the VNC video as the content channel.
• If there is already an active VNC connection in a conference, a second VNC connection will automatically replace the first as the content channel (rather than appearing as a pane in the main video).
• Participant main video
  It is also possible for the MCU to use a endpoint's main video channel as the conference's content channel. This has the same caveats as the use of a VNC connection for the content channel, as described above.
• Video markup
  Whichever of the content channel sources mentioned above is active, the MCU provides the facility for users to add markup to the video channel. This markup consists of an additional video overlay on to which graphics may be drawn and text added; content channel viewers see the content channel source video plus this overlay. The overlay can be cleared later leaving the source video unaltered.

MCU content channel configuration

Unit-wide or Blade-wide configuration

At the unit-wide/blade-wide level, the MCU can be configured to disallow the use of conference content channels completely. If the content channel facility is enabled, the MCU can be separately configured not to allow textual or graphical markup of the content, and whether to make text chat visible to connected endpoints.

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 such as VNC 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, such as the use of a VNC connection, 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 such as VNC become 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. This is essentially what happens by default for VNC connections in a conference configured to allow content channel video.

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 (this is set by default for VNC connections)
•  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
You might also see this warning if there is more than one VNC connection in a conference, because, when establishing a new VNC connection, the MCU will automatically configure its main (in fact, sole) video channel to be used as the content channel source if possible. To choose between multiple potential main video channels as the content source for the conference, use the control to stop using this participant's main video channel as the conference's content channel source:
  
on all but the source you want to use.

Streaming

As well as the content stream (used for sending to H.323 endpoints), the MCU also generates a proprietary format version of the content channel video which can be viewed in conjunction with PC-based video streaming. This ensures that, if desired, all participants and viewers for a conference are able to access all of its associated media.

Content channel streaming also allows participants using H.323 video conferencing endpoints without H.239 capability, or SIP endpoints to view a high resolution version of the content channel. Content channel streaming also provides some features not available via the H.239 protocol:

Markup

"Markup" is the overlaying of graphics and text onto the content channel video; this could be used, for instance, to draw attention to a specific element of a presentation slide. Markup can only be performed through the content channel streaming interface, and is accomplished via the simple mechanism of clicking and dragging with the mouse, with extra controls for changing the drawing color or clearing the markup when its usefulness has passed.

Content channel markup also has the following characteristics:

• All content streaming viewers have equal markup capabilities. This means that either all viewers are able to perform markup on the content channel video (or clear it), or all are unable to do so - it is not possible to restrict markup to just a subset of active viewers.
• The video markup, although it can only be edited by streaming viewers, will be seen by content channel streaming viewers, by participants connected via H.323 endpoints that are receiving the content channel, and by any participants that are viewing the content as part of their main video.
• Video markup is normally used as an overlay to content channel video as supplied by a H.239, BFCP, or VNC connection. However, for a conference with content channel operations enabled, it is also possible to form a content channel comprising just the markup applied to an otherwise blank video stream. This can be accomplished simply by starting to stream the conference's content channel and performing the usual markup operations on the (empty) content channel displayed. Adding markup to such a blank channel "activates" it, and will cause a video channel to be opened to those H.323 conference endpoints which have H.239 capabilities. SIP endpoints will see the video markup as a pane in the main video.

The ability of content channel streaming viewers to perform markup is governed by the unit-wide/blade-wide Markup of content channel video setting on the Settings > Content page.

Text chat

In parallel with, though in many senses independently of, content channel streaming, the MCU also provides a mechanism for those streaming a conference's content channel to communicate with other conference participants via text messages. Beneath the window showing the content channel video, streaming viewers are able to type messages that will be sent to all other streaming viewers, as well as see messages that other users type.

In order that users contributing text messages can be identified, each content streaming viewer has an associated user ID, and this ID is pre-pended to each message when it is sent out to other viewers' displays. If the content channel streaming has been initiated via the streaming-only interface, each user is required to supply a Sign-in name before streaming starts, and this sign-in is used as their text chat identifier. If streaming has been initiated via the Stream control on the MCU conference list, the user's web interface login ID will be used as their text chat identifier.

The text chat facility provided via web browser-based content streaming is two-way in that any content channel streaming viewer is able to both contribute text and see all messages typed by other viewers. Although there is no mechanism by which endpoints are able to contribute text chat messages, the MCU is able to display the most recent text messages within endpoints' main video channels. This is intended to be of use when a presenter is connected to an MCU conference via a video endpoint and wants to field questions raised by (content channel) streaming viewers. In this situation, the text typed by content channel streaming viewers is overlaid on the normal, multi-pane, conference layout, though restricted to approximately the lowest 1/3 of the screen.

For streaming viewers to have the option of contributing and/or reading text messages, the View content channel option must be selected. This option is one of the advanced streaming options available to users when they select to stream a conference.

The display of text chat in endpoints' views is governed by the unit-wide/blade-wide Content channel text chat option which is an Overlaid text setting on the Settings > Conference page. The text chat facility itself, and display of typed text to all content channel streaming viewers' windows, cannot be disabled.

Web conferencing feature key

Some of the above content channel features require the MCU to have been configured with the Web conferencing feature key. The following features are only available with the Web conferencing key:

• Streaming the content channel to users' desktop machines as a separate window (rather than as a pane in the conference view)
• Markup of content channel video
• Text chat

Port usage

Port reservation mode

MCU 4200 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 MCU 4203, there are separate ports for content and for streaming viewers. For more information, refer to MCU port matrix.

MCU 4500 Series and MSE Media2 blades
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 'Streaming and content' ports provided by your MCU. A single 'Streaming and 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 'Streaming and 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 works in a similar way to streaming in that it 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.

Streaming

The streaming of the content channel is performed using the port allocated for content rather than the port allocated for streaming. This means that it is possible to stream the content channel (for example, to use the video markup feature) for conferences which do not have streaming enabled. Enabling both streaming and content for a conference will mean that two additional ports will be required for that conference, over and above the video and audio-only ports used by endpoints participating in that conference.

See port reservation for more information.

Ad hoc conferences

All of the above-mentioned features, for instance content video streams between the MCU and video conferencing endpoints, markup of content channel video and text chat, 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.

In software versions prior to 1.4(1), it was not possible to use content channel features (including the H.239 protocol between the MCU and H.323 video conferencing endpoints) with ad hoc conferences. It remains the case that ad hoc conferences are not permitted when operating in reserved mode.

Related topics

• Configuring content settings
• Conference content channel
• Configuring H.323 endpoints
• Configuring SIP endpoints