Cisco Cisco TelePresence MCU 4510 Developer's Guide
Linking conferences across MCUs
Cisco TelePresence MCU Remote Management API Reference Guide
Page 80 of 89
Linking conferences across MCUs
For the purposes of this description, two conferences are said to be "linked" if there is a bi-directional
H.323 connection between them and each MCU is sending a video channel to the other, showing the
active speaker full screen. The audio communicated between the MCUs will be the usual mix of active
speakers. For clarification, the linked conferences are given different names (“linked1” and “linked2”)
in the explanation, but they can have the same name.
H.323 connection between them and each MCU is sending a video channel to the other, showing the
active speaker full screen. The audio communicated between the MCUs will be the usual mix of active
speakers. For clarification, the linked conferences are given different names (“linked1” and “linked2”)
in the explanation, but they can have the same name.
The first step is to set up the two conferences. It is important to ensure that the conferences have a
numeric id set (the "conferenceID" field in "conference.create"), because, without this configured field,
it is not possible to call in directly to a conference. In this example both conferences are given a
numeric id, though strictly it is only necessary on the target MCU (i.e. the one that is called rather than
the one calling).
numeric id set (the "conferenceID" field in "conference.create"), because, without this configured field,
it is not possible to call in directly to a conference. In this example both conferences are given a
numeric id, though strictly it is only necessary on the target MCU (i.e. the one that is called rather than
the one calling).
In this specific example, "linked1" is set up on "mcu1" and "linked2" set up on "mcu2". The creation of
"linked1" is shown in example message 1, and it is configured with numeric id "1234"; the creation of
"linked2" is shown in example message 2, and this conference is given the numeric id "5678".
"linked1" is shown in example message 1, and it is configured with numeric id "1234"; the creation of
"linked2" is shown in example message 2, and this conference is given the numeric id "5678".
Next, a participant needs to be added to the "linked1" conference and connected to "linked2" on the
target MCU. The most reliable way to accomplish this, which does not rely on the target MCU's
gatekeeper usage, is to call from “mcu1” into the target conference using "mcu2" as a gateway and the
target conference's numeric id as the remote address. The participant addition is shown in example
message 3 - as well as the address and gateway. It also configures the view layout to be full screen
(by setting "cpLayout" to "layout1") to make sure that just the active speaker from "linked1" is sent to
"linked2".
target MCU. The most reliable way to accomplish this, which does not rely on the target MCU's
gatekeeper usage, is to call from “mcu1” into the target conference using "mcu2" as a gateway and the
target conference's numeric id as the remote address. The participant addition is shown in example
message 3 - as well as the address and gateway. It also configures the view layout to be full screen
(by setting "cpLayout" to "layout1") to make sure that just the active speaker from "linked1" is sent to
"linked2".
The final step is slightly more complex — it involves modifying the new "linked2" participant on "mcu2"
which was the result of the call from "mcu1". The modification required is to change the view layout
setting (for the video sent from "linked2" to "linked1") to full screen so that a view of the “linked2”
active speaker is sent.
which was the result of the call from "mcu1". The modification required is to change the view layout
setting (for the video sent from "linked2" to "linked1") to full screen so that a view of the “linked2”
active speaker is sent.
The complication here is that the "linked2" participant in question is not a participant created via the
API, and so the API does not know the name in advance. Therefore, it is necessary to:
API, and so the API does not know the name in advance. Therefore, it is necessary to:
poll membership of "linked2" after the connection from "linked1" has been made
identify the participant corresponding to the call
use its name in a "participant.modify" call to set the view layout
The simplest way to identify the participant is to look for an absence of the “address” field in a
“conference.query” response: for incoming, non-API, connections this will not be present. Example
message 4 shows such a “participant.modify” call; in this case the participant name needed was
"1_Cisco MCU 4210".
“conference.query” response: for incoming, non-API, connections this will not be present. Example
message 4 shows such a “participant.modify” call; in this case the participant name needed was
"1_Cisco MCU 4210".