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@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.