Cisco Cisco TelePresence MCU 4510 Release Notes
New features in Version 4.2(1.43)
Cisco TelePresence MCU Version 4.2(1.43) software release notes
Page 7 of 20
Slave participant content negotiation mode
In previous versions of the Cisco TelePresence MCU, it was possible to make calls to and receive
calls from another MCU and send media successfully in both directions. H.239 content could be
received from another MCU by the Cisco TelePresence MCU, however, certain other MCUs (such as
the Polycom MGC) did not send on H.239 content received from the Cisco TelePresence MCU to their
participants because they expected to always act as a master in content negotiation.
calls from another MCU and send media successfully in both directions. H.239 content could be
received from another MCU by the Cisco TelePresence MCU, however, certain other MCUs (such as
the Polycom MGC) did not send on H.239 content received from the Cisco TelePresence MCU to their
participants because they expected to always act as a master in content negotiation.
In Version 4.2 it is possible to configure the Cisco TelePresence MCU to be a slave in content
negotiation with another MCU. It can be configured as a true slave, where content will only be
transmitted if the master MCU agrees, or as a mimic slave where the Cisco TelePresence MCU still
acts as a slave in the content negotiation, but will try to send content over other links even if the mimic
slave’s master rejects the token request.
negotiation with another MCU. It can be configured as a true slave, where content will only be
transmitted if the master MCU agrees, or as a mimic slave where the Cisco TelePresence MCU still
acts as a slave in the content negotiation, but will try to send content over other links even if the mimic
slave’s master rejects the token request.
This is configured via a new field (Content negotiation) in the Add participants page.
Lecture mode screen layout enhancements
Previously, when in lecture mode all participants except the speaker in a conference would see the
same layout. This has been changed so that those joining using the chair ID/PIN (lecture mode) and
those joining using the guest ID/PIN see different layouts.
same layout. This has been changed so that those joining using the chair ID/PIN (lecture mode) and
those joining using the guest ID/PIN see different layouts.
The table below illustrates the screen layout functionality prior to Version 4.2:
Layout seen by speaker
Layout seen by guest
Layout seen by chair
When a guest is speaking
Continuous presence or
participant’s custom layout
participant’s custom layout
Speaker
Speaker
When the chair is speaking
Continuous presence or
participant’s custom layout
participant’s custom layout
Speaker
Speaker
In Release 4.2 automatic lecture mode has two options which determine the screen layout that is seen
by a guest when another guest is speaking:
by a guest when another guest is speaking:
Type 1: The speaker sees continuous presence or their custom layout and all participants see the
loudest speaker, be they a chair or a guest.
loudest speaker, be they a chair or a guest.
Type 2: All guests including the speaker see the last chair who spoke full screen. All chairs will
see their custom layout.
see their custom layout.
This is controlled via the existing Automatic lecture mode field in the conference Configuration page.
When this field is set to Type 1, the screen layout behavior is as it was prior to Version 4.2 (see the
table above). The table below illustrates the new screen layout behavior when Automatic lecture mode
is set to Type 2.
When this field is set to Type 1, the screen layout behavior is as it was prior to Version 4.2 (see the
table above). The table below illustrates the new screen layout behavior when Automatic lecture mode
is set to Type 2.
Layout seen by speaker
Layout seen by guest
Layout seen by chair
When a guest is speaking
Last chair who was speaking
Last chair who was speaking
Participant’s custom layout
When the chair is speaking
Participant’s custom layout
Speaker
Participant’s custom layout
Note that MCUs can be cascaded and lecture mode functionality will continue to work, subject to the
following restrictions:
following restrictions:
Cascaded conferences can only be two MCUs deep, with one master MCU and multiple slave
MCUs called into it.
MCUs called into it.
All chairs must connect to the master MCU.
Cascade links must be H.323.
All MCUs must have the same setting for Automatic lecture mode.