The MCU supports an additional video channel known as the content channel for each conference. This feature encompasses:
* - these features require the web conferencing feature key.
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:
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).
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:
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.
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.
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 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 ( ).
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'spage (go to 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:
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 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):
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.
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" 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:
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 page.
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 page. The text chat facility itself, and display of typed text to all content channel streaming viewers' windows, cannot be disabled.
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:
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.
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.
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.
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.
|(c) Copyright TANDBERG 2003-2010, License information|