This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/ITU/ITU-T H.140 A multipoint internat videoconference system.pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- INTERNATIONAL TELECOMMUNICATION UNION )45 4 ( TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU ,).% 42!.3-)33)/. /& ./. 4%,%0(/.% 3934%-3 ! -5,4)0/).4 ).4%2.!4)/.!, 6)$%/#/.&%2%.#% 3934%- )45 4 Recommendation ( (Extract from the "LUE "OOK) NOTES 1 ITU-T Recommendation H.140 was published in Fascicle III.6 of the Blue Book. This file is an extract from the Blue Book. While the presentation and layout of the text might be slightly different from the Blue Book version, the contents of the file are identical to the Blue Book version and copyright conditions remain unchanged (see below). 2 In this Recommendation, the expression “Administration” is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. © ITU 1988, 1993 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. Recommendation H.140 Fascicle III.6 - Rec. H.140 A MULTIPOINT INTERNATIONAL VIDEOCONFERENCE SYSTEM (Melbourne, 1988) 1 Scope This Recommendation defines a multipoint videoconference system which enables three or more videoconference sites to intercommunicate simultaneously, provided that the codecs conform to Recommendations H.120 and H.130 (§ 1, Note). Note – Codecs conforming to § 2 of Recommendations H.120 and H.130 are in principle also applicable. 2 General requirements A multipoint control unit (MCU) is a piece of equipment located in a node of the network (terrestrial or satellite) which receives several (maximum seven) 2 Mbit/s channels from access ports (each access port corresponding either to a local or a remote codec, or to another MCU) and, according to a certain criterion, causes some of them called selected channels to be distributed towards the connected studios (see Figure 1/H.140). The basic functions of the MCU for a terrestrial or a satellite network are identical. The MCU shall have the capability: − To synchronise the incoming streams to a single 2048 kHz pilot clock. − To extract frame alignment from TS0 in order to synchronise the different streams to the frame clock, to extract frame parity, multiframe and supermultiframe alignment from TS2 in order to access in each incoming stream the codec-to-codec signalling channel. − To process this signalling channel. − To process the sound channels in order to create an open sound system, in the case of an unencrypted system. − To decide image switching and dispatching according to a selection criterion (automatic or on request). − To signal in advance the switching decisions to the codecs so that degradation during and after the switching can be avoided. − To multiplex the selected video channels with the open sound channel and the effective data channels. − To distribute the reconstructed streams to the corresponding access ports. Fascicle III.6 - Rec. H.140 1 3 Synchronisation of bit streams 3.1 Clock synchronisation All incoming bit streams to the MCU must be derived from the same basis 2048 kbit/s clock. If no codec involved in a multipoint conference resides in a synchronous network, i.e. no signal is received with bit 8 in TS0 of odd frames set to zero, then the MCU acts as a master clock source. Such an MCU should have a reference clock with a short term accuracy of 1 in 109, in order to avoid frame slips during a conference session. If one or more codecs are in synchronous networks (bit 8 = 0), then their clocks are taken as the master. In both cases the MCU sets on all outgoing channels bit 8 in odd TS0’s to zero. 3.2 Frame synchronisation The MCU has the following functions: i) Extract from TS0 frame alignment and generate the frame clock. Frame parity should not be extracted from TS0 as it is not transparently transmitted through some networks. ii) Extract from TS2 multiframe and supermultiframe alignment and generate: frame parity, multiframe clock, supermultiframe clock. iii) Synchronise the bit streams at the PCM frame rate, such that switching can be performed without interrupting the Recommendation G.704 frame structure. 4 MCU and codec use of TS2 odd for multipoint conference applications The bits are encoded according to Recommendation H.130, (§ 1). A majority decision of 5 out of 8 is used to provide resilience to channel errors with respect to the signals in bits 3 and 4. 4.1 Bits 1, 2, 6, 7 are transparently transmitted by the MCU. 4.2 Bit 8 gives multiframe and supermultiframe alignment and recovery of frame parity. 4.3 Bit 3 is for coding mode identification. Bit 3.1.c indicates the facilities offered by the codec (set to 1 if provided) and are fixed for each codec. The MCU should take account of these bits in order to set up a minimum operating mode for all the codecs involved in the conference. For each individual port on the MCU a logical AND is made between the incoming signals from all other ports. The resultant signal is then used as the outgoing signal for that specific port, the rule being that an individual ports facilities bits should not be echoed back. Bit 3.1.0 Graphics (mode 1) Bit 3.1.1 High quality speech Bit 3.1.3 Encryption Bit 3.1.4 System M Bit 3.1.5 Graphics (mode 2) Bit 3.1.6 Spare – set to zero Note 1 – MCUs not equipped to mix Recommendation G.722 audio will set bit 3.1.1 to zero. Note 2 – The use of bit 3.1.3 for encryption is under study. 2 Fascicle III.6 - Rec. H.140 Bit 3.1.2 Bit 3.1.7 0 0 2 Mbit/s working only 1 0 2 Mbit/s and 4 × 384 kbits/s working only 0 1 2 Mbit/s and 2 × 384 kbits/s working only 1 1 2 Mbit/s and 4, 3, 2 × 384 kbits/s working Note – If the bit rate signalled by bits 3.1.2 and 3.1.7 exceeds that available at the codec digital interface, then the meaning of the facilities bits is as follows: – with codecs having a 1.5 Mbit/s serial interface 0 0 Never occurs 1 0 Means 4 × 384 kbit/s working only 0 1 Means 2 × 384 kbit/s working only 1 1 Means 4, 3, 2 × 384 kbit/s working only – with codecs having a 2 Mbit/s serial interface, but effective rate of 768 kbit/s 0 0 Never occurs 1 0 Never occurs 0 1 Means 2 × 384 kbit/s working only 1 1 Means 2 × 384 kbit/s working only Bits 3.3 (colour transmission) and 3.5 (split-screen display) are transparently transmitted by the MCU. 4.3.1 Bit 3.7 – Fast update request (FUR) When set to 1, the transmitter buffer occupancy is forced to decrease and stabilise to a state of less than 6 K by preventing coded picture elements entering the buffer. 4.3.2 Bit 3.9 – Freeze frame request (FFR) Used to warn a decoder that its received signal may be interrupted after the start of the next supermultiframe for a period of no more than 2 s. On receipt of bit 3.9 set to 1 a decoder will normally “freeze” the contents of its frame store for 2 s or until a field start code is received with bit A set to 1 (see Recommendation H.120 § 1). Both bits 3.7 and 3.9 should pass transparently across an MCU if set on an incoming signal: this is to allow for multipoint conferencing using distributed MCU’s. Bit 3.11.c indicates the power of the sound channel, integrated during 16 ms (period of the supermultiframe) and encoded with 8 bits. It is only used with encrypted multipoint, otherwise it is set to zero. The MCU can use this bit to select the New and Previous Speaker’s channels (see § 6). 4.3.3 Bit 3.13 – Data distribution When a codec received this bit set to one, it must vacate in its transmission channel the same time slots which are vacated with respect to the video signal in its receive channel and which are signalled by bits 4.1, 4.3, 4.5, 4.7. The MCU uses this bit to ensure data continuity during a conference (see § 9). 4.3.4 Bit 3.15 – Loop detection Bit 3.15 may be used by the MCU to detect whether one of its bidirectional 2 Mbit/s ports has been externally looped. It is necessary to monitor this condition since instability may result from such a configuration. The definition of Fascicle III.6 - Rec. H.140 3 bit 3.15 is as follows: Codecs set bit 3.15 to 1 in their outgoing paths. MCUs use a number of consecutive bit 3.15s to transmit a serial random bit stream of length n, repeatedly. If the received bit sequence is the same as the transmitted random serial sequence then a loop has been detected. It should be noted that the received bit sequence may exhibit a phase delay compared with the transmitted sequence. The details of the random sequence need not be rigidly specified as the sequence is only relevant when an individual MCU is in a looped configuration. However precautions must be taken to avoid false loop detection. This is likely to occur when two or more MCUs are connected together or when the transmission medium is subject to errors. A number of recommendations are given below. The length of the transmitted random sequence n should be sufficiently large to avoid duplication when two or more MCUs are connected together. It is suggested that the total length be in excess of 15 bits, thus the possibility of duplication is less than 1 in 65536. The sequence transmission and detection mechanism should be sufficiently resilient to channel errors. This can be achieved in a number of ways, two simple methods are suggested here. First, considering the sequence as a number of individual bits, each bit may be transmitted for 8 consecutive bit 3.15s. The receiver takes a majority 5 from 8 vote as the received sequence bit. Thus to transmit a single sequence takes 8 × n bits. This similar to the method adopted for bits 4 ⋅ x. Alternatively, as the random sequence is transmitted repetitively, the decision as to whether the port is in the looped state or not is taken only when a number of sequences has been received. 4.4 Bit 4 is for time slot allocation. If the following bits are set to 1: Bit 4.1 TS2 even is not used for video Bit 4.3 TS16 is not used for video Bit 4.5 TS17 is not used for video Bit 4.7 TS18 is not used for video Bit 4.11 Graphics transmission Bit 4.13 Use of error correcting code When a codec receives any of the bits 4.3/5/7 set to one, and bit 3.13 is set to 1 (see § 4.3), it also vacates the corresponding time slots in its transmitted stream and sets to one the corresponding bits 4.b in its transmission channel. Bit 4.1 is transmitted transparently by the MCU as the MCU cannot switch half time slots, i.e. the MCU takes no action. Bits 4.9 and 4.15 are used for bit rate signalling. Bit 4.9 Bit 4.15 0 0 2 Mbit/s operation 1 0 4 × 384 kbits/s 1 1 3 × 384 kbits/s 0 1 2 × 384 kbits/s At 5 × 384 kbit/s Time slots 1-15 and 17-31 active At 4 × 384 kbit/s Time slots 1-15 and 17-25 active At 3 × 384 kbit/s Time slots 1-9 and 17-25 active At 2 × 384 kbit/s Time slots 1-6 and 17-22 active 4 Fascicle III.6 - Rec. H.140 The MCU should take account of bits 4.9 and 4.15 in order to set up a minimum operating mode for all the codecs involved in the conference. For each individual port, bits 4.9 and 4.15 from every other port on the MCU are analysed to determine which is the lowest requested bit rate permitted by the facilities bits 3.1.2 and 3.1.7. The code for this bit rate is then used as the outgoing signal in bits 4.9 and 4.15 for that specific port. Again the rule is that an individual port’s bit rate facilities bits should not be echoed back. To avoid a lock up situation, the codec should not return its received bits 4.9 and 4.15 in its transmit path, but should generate them independently. 4.5 Bit 5 carries a 4/kbits message channel This bit is used to convey an asynchronous message channel at 4 kbit/s for signalling between the room and the MCU or between rooms or between MCUs. The protocol of this message channel is under study. 5 Audio processing Each terminal connected to an MCU must receive a mix of the audio from all other terminals. The audio signals should be summed at the MCU without normalisation, i.e. unity gain on each channel. The introduction of dynamic mixing for the suppression of ambient noise may be included but speakers would still enjoy unity gain. Note – Not applicable with encrypted multipoint. 6 Switching decision criteria The criteria for switching to some extent depends on the philosophy of the multiconference service in each Administration. Any solution, automatic or manual, can be implemented without altering the basic arrangement of the MCU. The minimum working mode or “automatic” mode is as follows: the MCU, by comparison of the incoming sound channels or, in case of encrypted sound channels, by the means of the sound power bit (bit 3.11 in TS2 odd), selects the loudest speaker (called new speaker or NS). A second channel is selected by the MCU, being the previous loudest speaker (called previous speaker or PS). The NS is sent the PS channel and the other rooms are sent the NS channel. This mode is always used when the multiconference is established. Details of the switching criterion with respect to sound levels, hangover time, etc., are under study. Five manual overrides are currently identified: a) The system remains automatic but one location is considered to be the chairman of the conference. Participants are able to transmit a “request for the floor” to either the chairman or all rooms. At an appropriate time, the chairman orally gives the floor to the requesting conferee who, as he begins to speak, is automatically selected as the NS. b) One location (e.g. NS or chairman or VIP) is able to choose the allocation of the second selected channel (normally the PS channel) by transmitting a request to the MCU. c) Each location has the choice between the channels, which can be made available by the MCU connected to that location without affecting the displays of other locations. d) Complete manual chairman control with no voice detection. e) Manual forcing, where one location may force the MCU to regard his port as the NS. This override is known as visualisation forcing. It may be used in one of two cases: i) where a chairman or VIP wishes to be seen without interruption, ii) where a terminal is using a graphics camera, but is not equipped with a graphics capable codec. Only the “automatic” mode does not require the use of the message channel in bit 5. Modes a), b), c), d) imply the use of the message channel and extra control equipment (push-buttons, lights, signalling and data connections to the codec, etc.) at the conference room. Mode e) normally makes use of the message channel, but an interim solution is available on a National basis (see § 8.1). 7 MCU procedure for source switching Once the switching decision is taken, (either by monitoring the audio levels or by the message channel), the MCU must prepare the connected codecs and operate as following: Fascicle III.6 - Rec. H.140 5 i) it sends a FFR (bit 3.9) to all the codecs which will be affected by the switch, via the selected transmission channels connected to them. ii) It performs image switching whilst maintaining the basic Recommendation G.704 frame structure continuity in the selected channel(s). iii) It waits for at least 32 ms to allow sync recovery in all decoders. iv) It sends a FUR (bit 3.7) to the codec(s) which are about to be used as a new picture source. A FUR or a FFR must be set to one for at least one supermultiframe (SMF), or 256 frames in the case of non SMF-synchronous MCUs. If the newly selected channels are connected to the MCU via a terrestrial link, the whole operation is likely to take no more than 100 ms. If it is via a satellite link, switch times of 500 ms are typical. 8 Protocols for “who is seen” in a multipoint conference 8.1 Automatic mode This is described in § 6. During automatic operation, it is convenient for the NS and PS to have some local indication that their picture is being transmitted. This facility is known as “visualisation status” or “on-air”. When defined, the message channel will have the capability of signalling such information together with many other useful facilities. In the short term, for existing codecs, an alternative means of signalling using TS2 odd bit 5 which is currently reserved for the message channel may be used for transmission of the visualisation and forcing bit by those countries who wish to implement such a simplified system. Under these circumstances, in a multiple MCU conference, the inter MCU link should be inhibited from sending the visualisation signal to avoid problems of contention. As a long term solution, the message channel is required to ensure compatibility with audioconferencing (this point is under study). In the mean time, the method of transmission should be bilateral agreement. 8.2 Control using message channel Initialization and addressing procedure including the following items are under study; − request for floor, − local selection by request to view, − chairman control. 9 Transmission of graphics during multipoint This concerns the use of graphics modes 1 and 2 in the codec, not separate SPTV systems. 9.1 Automatic mode The general principle is that all participants see the graphics information except the sender who sees the loudest speaker (other than himself). The MCU first needs to establish whether all codecs in the conference have a graphics facility. If both the graphics facilities bits (bits 3.1.0 and 3.1.5) in any of the incoming channels to the MCU are set to zero, then the MCU sets both bits to zero in all its outgoing paths. This forces all codecs to use face-to-face type coding for graphics transmission. When the MCU receives the graphics transmission bit set to 1 (bit 4.11), then the voice detector is overridden and the originating port (say port A) is made the new speaker, and hence transmitted to all other participants. Port A is sent the loudest speaker from the remaining ports (in the PS channel). 9.2 Manual Mode Under study. 10 Transmission of data during multipoint If a participant wishes to transmit data to all other terminals then data continuity must be ensured by the simultaneous vacation of the data channels by all codecs. This involves some delay (800 ms maximum if double satellite hops occur). 6 Fascicle III.6 - Rec. H.140 Time slot 2 even is not used for data distribution so it does no need to be separately switched by the MCU. 10.1 Fully automatic mode (i.e. no message channel) The terminal “A” wishing to broadcast data sets to 1 the relevant bit 4 of TS2 for the data channel to be used. The MCU sets bit 3.13 to 1 in all outgoing streams except A and overrides the speaker detection procedure to make “A” the present speaker. Other terminals on receipt of bit 3.13 and the relevant bit 4 in TS2 set to 1, vacate their outgoing equivalent data ports and set the corresponding bit 4’s to 1. The MCU then allows voice switching by the other ports after 2 s. When A concludes the data transmission it sets its relevant outgoing bit 4 in TS2 to zero. The MCU in turn sets bit 3.13 to zero. Normal voice switched operation then continues. 10.2 Operation with message channel Under study. 11 Outline of output from MCU Each location is sent a 2 Mbit/s channel reconstructed from one of the selected video channels, the corresponding TS2 odd with the possible modifications issued from the MCU in bits 3 or 5, the sound channel resulting of the mixing of the other sound channels and the effective data channels. 12 Multipoint conference configurations 12.1 Terrestrial configuration Figure 1/H.140 shows a terrestrial multiconference using multiple MCU’s. Many multiconferences may need only one MCU in a star formation. 12.2 Possible satellite configurations Figure 2/H.140 shows a multiconference where rooms are connected through the same earth station to a single MCU. This situation is similar to that of § 12.1 but with a double hop between the rooms X and Y. Other possibilities for satellite working are currently under study. Fascicle III.6 - Rec. H.140 7