Cisco Cisco TelePresence MCU 4510 Developer's Guide
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.
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).
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
"linked1" is shown in
, and it is
configured with numeric id "1234"; the creation of "linked2" is shown in
, 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
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
- 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".
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.
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:
so the API does not know the name in advance. Therefore, it is necessary to:
n
poll membership of "linked2" after the connection from "linked1" has been made
n
identify the participant corresponding to the call
n
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.
“conference.query” response: for incoming, non-API, connections this will not be present.
shows such a
“participant.modify” call; in this case the participant name needed was "1_Cisco MCU 4210".
Example message 1 - creating conference "linked1" on
"mcu1"
"mcu1"
<?xml version="1.0"?>
<methodCall>
<methodName>conference.create</methodName>
<params>
<param>
<value>
<struct>
<member>
<name>authenticationUser</name>
Cisco TelePresence MCU API 2.10
Page 190 of 296
Related information
Linking conferences across MCUs