Cisco Cisco TelePresence MCU 4510 Maintenance Manual
Content channel video support
Cisco TelePresence MCU Version 4.2 Printable online help
Page 61 of 252
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.
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.
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.
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.
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
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
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.
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.
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.
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.