Filter
Top Products
Copyright © TANDBERG 2008 Reference Guide Version 3.0 rev 1.0 55
Appendix B - 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.
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).
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".
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".
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.
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:
f poll membership of "linked2" after the connection from "linked1" has been made
f identify the participant corresponding to the call
f 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_Codian
MCU 4210".
B.1 Example message 1 - creating conference "linked1" on "mcu1"
<?xml version="1.0"?>
<methodCall>
<methodName>conference.create</methodName>
<params>
<param>
<value>
<struct>
<member>
<name>authenticationUser</name>
<value>