APC-1305
QUESTIONS: 12/16
TITLE: H.243 based conference session control procedures
for H.bmultipoint
PURPOSE: Discussion
SOURCE*: Lucent Technologies
Li Yan Tel: +1 732 957 3877
lyan(a)lucent.com Fax: +1 732 957 5627
This contribution discusses the possibility of using H.245
based, H.243 like conference session control procedures for
tightly-coupled multipoint conference using H.310 multimedia
terminals.
1. Introduction
At the Hertzliya meeting, APC-1201 proposed several study items
for H.bmultipoint. One of the sturdy items is whether H.243 or
T.120/T.130 can be used for multipoint conference session
control for H.bmultipoint.
We look at both H.243 and T.120/T.130 series for conference
session control. T.120/T.130 may provide a more complete
conference control and potentially more advanced conference
Features. However, since T.120/T.130 is not mandatory for H.310
terminals and H.310 terminals may not support them at all, we
can not rely on them to provide basic control for conference. On
the other hand, H.245 is mandatory control protocol for H.310
terminals. H.245 based, H.243-like procedures can provide some
basic conference session control. These H.245 based procedures
may not be able to provide all we want but they are adequate for
early deployment. We can always add T.120/T.130 for more
advanced feature control later if T.120/T.130 become a norm for
H.310 terminal implementation.
2. The Scope of the contribution
This contribution focus on session control for classical MCU
without video mixing. In this configuration, endpoints are
tightly-coupled. Audio is centrally mixed and video (and data)
are centrally switched at the MCU. To provide basic conference
session control, the following procedures are investigated and
detailed procedures are described in Annex:
Procedure for determining capabilities and selected
communication mode
Initialization procedures for establishing communication
between standard terminals and an MCU
First terminal added to conference
Second terminal added to conference
Third terminal added to conference
Fourth and subsequent calls added to conference
Closure of conference
MCU-MCU interconnections: initialization & designation of
master MCU
Procedure for Video switching
Mode switching and Capability exchange during a call
Exceptional procedures
A terminal connected does not indicate capability for
the SCM
3. Conclusion
H.245 based, H.243-like procedures can provide adequate
conference control for classical MCU without video mixing. We
propose to adopt the procedures described at Annex as part of
H.bmultipoint working drift.
ANNEX
Annex1. Procedure for determining Capabilities and selected
communication mode
The MCU shall send appropriate capabilities, according to the
type of communication intended.
For each conference call a "selected communication mode" is
identified in the MCU. During the call the MCU strives to
maintain this SCM as that transmitted bi-directionally between
itself and all terminals, and between itself and other MCUs.
The following are possible methods to determine the SCM:
1) the SCM may be fixed as a permanent feature of the MCU as
manufactured;
2) the MCU may provide for several possible values of SCM, and
one of these is specified by the service provider or at the
time of booking the call;
3) the SCM is selected automatically within the MCU according to
the capabilities of the terminals connected; for example, the
SCM is set at the value transmitted by the first terminal to
access the MCU; or the highest common mode of all primary
terminals is selected; or the SCM is set at the value
transmitted by the chair-control terminal, if any;
4) the SCM is set by utilizing procedures effectuated using
T.120 Series protocols.
To enforce SCM, at the beginning of a conference, MCU sends
multipointModeCommand to all the terminals to command that a
terminal in receipt shall comply with all requestMode requests
issued by the MCU, if the requested transfer mode are within
terminal's capability set.
Annex 2. Initialization procedures for establishing
communication between standard terminals and an MCU
1. First terminal added to conference
The communication of the first terminal and MCU follows the
following phases:
Phase A: Call setup (Initial VC-Setup):
Initial VC is setup between the first terminal and the MCU via
Q.2931 SETUP message. The exact parameters and Q.2931
Information Elements (IEs) used for this phase is described in
H.310 Annex B. In this phase, MCU can either identify the type
of remote H.310 terminal or infer that the remote terminal is
not H.310 terminal type. This is done by using the Broadband
Bearer Capability (B-BC), Narrow-band Bearer Capability (N-BC)
and other information elements of the Q.2931 SETUP message. An
H.310 MCU shall set these information elements to the
appropriate parameters which indicate the H.310 terminal type.
If an H.310 MCU does not receive the N-BC information element
from the remote terminal, then the H.310 MCU can assume that it
is not communication with an H.320/H.321 terminal.
The initial VC shall have a bitrate of 64 kbits/s at the AAL-
SAP, for the transfer of H.245 message using the separate
VC stack described in H.310 Annex A.
Phase B: Initial communication and Capability exchange
MCU sends multipointConference and multipointZeroComm
indications to the first terminal over the initial VC that has
been established in Phase A, indicating that a conference call
is being set up, that no other terminals are yet connected and
the user should wait. Using H.245 procedures, the MCU and the
first terminal exchanges their capabilities. MCU registers those
capability of the first terminals which it can understand and
used. For those capability that are not understood, or can not
be used by MCU shall be ignored. Note that MCU can determines
"SCM" based on the capabilities exchange or use predetermined
"SCM" as described in Annex1.
MCU then sends multipointModeComm command to request the first
terminal to follow all mode request form it. Then MCU sends
requestMode with selected communication mode.
Phase C: Establishment of audiovisual communication (Additional
VC Setup and A/V comm.)
In this phase, and based on the selected communication mode
determined above, the calling party (can be MCU or the first
terminal), that is, the one that initiated the first VC SETUP
message, shall firstly indicate the characteristics of the
additional VC(s) to the remote end using the H.245
NewATMVCIndication message, and then shall setup the additional
VC(s) with the appropriate parameters, such as bitrate and AAL
types, for the transfer of the audiovisual and other data
between the MCU and the first terminal. After establishment of
the additional VC(s), the procedures of H.245 shall be used to
open the desired video, audio, data, and/or control logical
channels using logical channel signaling protocol and bi-
directional logical channel signaling protocol defined in H.245.
To avoid bad audio, at the discretion of the manufacturer, the
MCU should do one of the following for Audio:
send LogicalChannelInactive for the audio channel to the
terminal;
send silence or an optional audio-message to the terminal.
The video seen by the first terminal is up to the discretion of
the MCU manufacturer.
The data received by the first terminal is up to the discretion
of the MCU manufacturer.
2. Second terminal added to conference
Phase A: Call setup (Initial VC-Setup):
Initial VC is setup between MCU and the second terminal by using
the same method as in the first terminal.
Phase B: initial communication and Capability exchange
MCU sends multipointConference indication to the second terminal
over the initial VC that has been established in Phase A,
indicating that a conference call is being set up. Using H.245
procedures, the MCU and the second terminal exchanges their
capabilities. MCU registers those capability of the second
terminals which it can understand and used. For those capability
that are not understood, or can not be used by MCU shall be
ignored. Note that MCU can determines "SCM" based on the
capabilities exchange or use predetermined "SCM" as described in
Annex 1.
MCU then sends multipointModeComm command to request the second
terminal to follow all mode request form it. Then MCU sends
requestMode with the selected communication mode.
Phase C: Establishment of audiovisual communication (Additional
VC Setup)
In this phase, and based on the communication mode determined
above, the calling party, that is, the one that initiated the
first VC SETUP message, shall firstly indicate the
characteristics of the additional VC(s) to the remote end using
the H.245 NewATMVCIndication message, and then shall setup the
additional VC(s) with the appropriate parameters, such as
bitrate and AAL types, for the transfer of the audiovisual and
other data between the MCU and the second terminal.
An MCU shall open the desired video, audio, data, and/or control
logical channels using the logical channel signaling protocol
and bi-directional logical channel signaling protocol defined in
H.245. The audio and video paths are set up as follows:
Audio:
n Both the (decoded) audio signals are connected to the
audio mixer; the symbol cancelMultipointZeroComm is sent
to the first terminal T1;
n The mixer outputs are sent to T1 and T2 and the mixing
algorithm used is up to the MCU manufacturer.
Video:
n If video signals are being received from either terminals,
VideoFastUpdatePicture is sent towards the transmitter(s)
of these signals and the next video frame in "Fast update"
mode is forwarded to both terminals;
n If video signals are being received from both terminals,
VideoFastUpdatePicture is sent to both terminals. T1's
video is forwarded to T2, and T2's video is forwarded to
T1.
Data:
n If both terminals are T.120 capable the MCU may connect
both to a data conferencing unit.
n
The MCU may defer opening of data channels to a later time, such
as when a predetermined number of terminals is present.
3 Third terminal added to conference
Phase A: Call setup (Initial VC-Setup):
Initial VC is setup between MCU and the third terminal by using
the same method as in the third terminal.
Phase B: Inital communication and Capability exchange
MCU sends multipointConference indication to the third terminal
over the initial VC that has been established in Phase A,
indicating that a conference call is being set up. Using H.245
procedures, the MCU and the third terminal exchanges their
capabilities. MCU registers those capability of the third
terminals which it can understand and used. For those capability
that are not understood, or can not be used by MCU shall be
ignored. Note that MCU can determines "SCM" based on the
capabilities exchange or use predetermined "SCM" as described in
Section 2.
MCU then sends multipointModeComm command to request the third
terminal to follow all mode request form it. Then MCU sends
requestMode with the selected communication mode.
Phase C: Establishment of audiovisual communication
In this phase, and based on the communication mode determined
above, the calling party, that is, the one that initiated the
first VC SETUP message, shall firstly indicate the
characteristics of the additional VC(s) to the remote end using
the H.245 NewATMVCIndication message, and then shall setup the
additional VC(s) with the appropriate parameters, such as
bitrate and AAL types, for the transfer of the audiovisual and
other data between the MCU and the third terminal.
An MCU shall open the desired video, audio, data, and/or control
logical channels using the logical channel signaling protocol
and bi-directional logical channel signaling protocol defined in
H.245. The audio and video paths are set up as follows:
Audio:
n The (decoded) audio signal is connected to the audio
mixer;
n The mixer outputs are sent to all the terminals and the
mixing algorithm used is up to the MCU manufacturer.
Video:
n If video signals are being received from any one of the
terminals T1, T2, and T3, or all of the terminals, video
is switched using the procedures described in Annex 4.
Data:
n If the new terminal is T.120 capable, the MCU connects it
to the data conferencing unit.
4. Fourth and subsequent calls added to conference
The procedure followed is essentially that of section 3 above.
5. Closure of conference
If the conference is closed by sequentially dropping terminals,
then when only one remains connected it should be sent
multipointZeroComm to allow the user to understand explicitly
the reason for loss of video, etc. The terminal dropped follows
the following call release procedures to close the connection:
Logical channels release: In this phase, all logical channels
are closed and EndSessionCommand is transmitted, using the
procedures described in H.245.
Virtual Channels release: In this phase, all ATM VCs are
released using the procedures described in Q.2931.
Annex 3. MCU-MCU Interconnections
Under working.
Annex 4. Video Switching
When it is decided within the MCU that terminal A, currently
receiving the video signal from terminal B, should instead be
sent from terminal C, the following procedure is used:
a) The MCU transmits videoFreezePicture to terminal A at an
appropriate moment, and then switches video such that the
picture from C is transmitted towards A;
b) Terminal A receives videoFreezePicture, and freezes its
currently displayed picture; it ignores subsequent decoded
video information, but continues to track the video
elementary stream for the freeze picture release control
command;
c) When incoming video to A changes from B-picture to C-picture,
frame alignment is lost, and will take a time T to recover,
dependent on the video bit rate and other factors;
d) After a time greater than T, the MCU transmits
VideoFastUpdatePicture to terminal C;
e) On receipt of VideoFastUpdatePicture, terminal C sends its
next video frame in "Fast-update" mode, together with the
videoFreezePictureReleaseControl command;
f) on receipt of the Freeze Picture Release command, terminal A
reverts to displaying the incoming decoded picture.
Annex 5. Mode Switching
1. Bit-rate symmetry
In a point-to-point call, a H.310 terminal can request a new
mode of audiovisual communication over the different logical
channels using the mode request signaling protocol defined in
H.245 as described in Section 6.4.4, and can switch to a new
mode using the logical channel signaling protocol and bi-
directional logical channel signaling protocol, and aided by the
close logical channel signaling protocol, defined in H.245 as
described in Section 6.4.3. However, in a multipoint call,
there are additional temporal constraints:
a) because the output packets from the MCU cannot be synchronous
with all input packets, there will usually be at least some
delay in transmitting a necessary command code; in a more
extreme case the MCU may already be engaged in a capacity
exchange with another terminal, and so be unable itself to
mode switch for some time;
b) time is needed for the MCU to process capability codes and
commands to ensure that the resulting modes are acceptable to
all terminals and are imposed in coordination, without
corruption of any video being transmitted.
To ensure that an MCU has adequate control, and in particular
that it can drive video signal transmission to a common rate
(noting that in the case treated here the MCU has no power to
transcode the video), bit-rate changes are initiated solely from
the MCU. Terminals, after having received multipointConference
from MCU, shall not change bit-rate except in response to such a
change incoming from the MCU. This applies to bit-rates for
audio, data, video, and the transfer rate; audio and video mode
changes not involving bit-rate changes may still be initiated by
terminals. When the bit rate incoming from MCU changes, the
terminals shall follow suit as promptly as other procedures
allow, as any delay may preclude the terminal's transmission
from being received by the other parties in a conference.
Annex 6. Exceptional procedures
Under working.
