InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1992 / h / h242.asc < prev next >

Wrap

Text File | 1993-08-21 | 59.9 KB | 1,522 lines

C:\WINWORD\CCITTREC.DOT_______________ INTERNATIONAL TELECOMMUNICATION UNION CCITT H.242 THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE LINE TRANSMISSION OF NON-TELEPHONE SIGNALS SYSTEM FOR ESTABLISHING COMMUNICATION BETWEEN AUDIOVISUAL TERMINALS USING DIGITAL CHANNELS UP TO 2 Mbit/s Recommendation H.242 Geneva, 1990 FOREWORD The CCITT (the International Telegraph and Telephone Consultative Committee) is a permanent organ of the International Telecommuni- cation Union (ITU). CCITT is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The Plenary Assembly of CCITT which meets every four years, establishes the topics for study and approves Recommendations pre- pared by its Study Groups. The approval of Recommendations by the members of CCITT between Plenary Assemblies is covered by the procedure laid down in Resolution No. 2 (Melbourne, 1988). Recommendation H.242 was prepared by Study Group XV and was approved under the Resolution No. 2 procedure on the 14 of December 1990. ___________________ CCITT NOTE In this Recommendation, the expression ôAdministrationö is used for conciseness to indicate both a telecommunication Administration and a recognized private operating agency. π ITU 1990 All rights reserved. No part of this publication may be reproduced or uti- lized in any form or by any means, electronic or mechanical, including pho- tocopying and microfilm, without permission in writing from the ITU. PAGE BLANCHE Recommendation H.242 Recommendation H.242 SYSTEM FOR ESTABLISHING COMMUNICATION BETWEEN AUDIOVISUAL TERMINALS USING DIGITAL CHANNELS UP TO 2 Mbit/s 1 Introduction This Recommendation should be associated with Recommendations G.725 (System aspects for the use of the 7kHz audio codec within 64 kbit/ s), H.221 (Frame structure for 64 to 1920kbit/s channels in audiovisual teleservices) and H.230 (Frame-synchronous control and indication signals for audiovisual systems). A number of applications utilizing narrow (3kHz) and wideband (7kHz) speech together with video and/or data have been identified, includ- ing high quality telephony, audio and videoconferencing (with or without various kinds of Telematic aids), audiographic conferencing and so on. More applications will undoubtedly emerge in the future. To provide these services, a scheme is recommended in which a chan- nel accommodates speech, and optionally video and/or data at several rates, in a number of different modes. Signalling procedures are required to estab- lish a compatible mode upon call set-up, to switch between modes during a call and to allow for call transfer. Some services will require only a single channel, which could accord- ing to the procedures in this Recommendation be B (64kbit/s), H0 (384kbit/s), H11(1536kbit/s) or H12 (1920kbit/s). Other services will require the establishment of two or more connections providing B or H0 channels: in such cases the first established is called hereafter the initial channel while the others are called additional channels. Unless otherwise specified, all references to frame alignment signal (FAS), bit rate allocation signal (BAS) and service channel (SC) refer to the initial channel or, in the case of a higher-order channel, to the time-slot No.1 of this channel. All audio and audiovisual terminals using G.722 audio coding and/or G.711 speech coding or other standardized audio codings at lower bit rates should be compatible to permit connection between any two terminals. This implied that a common mode of operation has to be established for the call. The initial mode might be the only one used during a call or, alternatively, switching to another mode can occur as needed depending on the capabili- ties of the terminals. Thus, for these terminals an in-channel procedure for dynamic mode switching is required. The following paragraphs develop these considerations and describe recommended in-channel procedures. 2 Terminal capabilities The procedures in this Recommendation are intended to ensure that only those signals are transmitted which can be received and appropriately treated by the remote terminal, without ambiguity. This requires that the capabilities of each terminal to receive and decode be known to the other terminal. Some capabilities are defined with a hierarchical structure: a ter- minal with capability valueN is then also capable of all lower values. Where there is no hierarchy, then two or more codes of the same type may have to be transmitted in successive frames. The following paragraphs define audio, video, transfer rate, and data rate capabilities of a terminal. It is not necessary that a terminal understand or store all incoming capabilities. Those which are not understood, or which cannot be used (because the terminal has no means to transmit correspond- ing information), can be ignored. The total capability of a terminal to receive and decode various sig- nals is made known to the other terminal by transmission (see º5.1) of its capability set, consisting of the BAS-capability marker followed by all of the current capabilities. The codes are specified in RecommendationH.221, AnnexA; Table1/H.242 (see º12) summarizes the capabilities which may be included in a valid set. The transmission order is immaterial with the exception that video picture format values must be followed by minimum picture interval values. Note û G.725 terminals send only a single capability value without a marker. The value is valid only if repeated at least once: this may be used to identify a G.725 terminal. Having so identified, the H.242 terminal should follow the procedures of RecommendationG.725. 2.1 Audio capabilities Audio capability values are defined in Recommendation H.221, Annex A. All audiovisual terminals intended for interregional operation should be capable of transmitting and receiving A- and m-law G.711. Normally, it is not necessary to transmit G.711 capabilities in a set containing other audio capabilities. Inclusion of just one value (A or m) must be interpreted as a request not to send audio encoded signals to the other law. See º6.3.1. 2.2 Video capabilities Video capabilities are defined in Recommendation H.221, including: û picture format: quarter-CIF, or both quarter-CIF and CIF; û minimum picture interval (MPI): 1/29.97, 2/29.97, 3/29.97, 4/29.97 seconds. The quarter-CIF value must be followed by one MPI value. The full- CIF value must be followed by two MPI values, the first applicable to quar- ter-CIF and the other to CIF. 2.3 Transfer rate capabilities Transfer-rate capabilities are defined in Recommendation H.221. The capability to receive a given number of multiple 64 kbit/s channel includes the capability to receive fewer 64kbit/s channels. Similarly, the capability to receive a given number of H0 channels includes the capability to receive fewer H0 channels. In both cases the receiving terminal will syn- chronize the connected additional channels to the initial channel and main- tain that synchronism throughout the period of connection. All other ranges of capability must be signalled by inclusion in the capability set of more than one transfer rate capability code. For example, a terminal may list its transfer-rate capabilities as {2B and H0 and H11 and H12}; in this case1B capability is also implied. 2.4 Data capabilities Data capabilities are defined in Recommendation H.221. If a terminal is able to accept more than one data rate of whatever type (LSD, HSD, MLP, H-MLP), then all relevant values must be included in the capability set. Statement of one value does not include any other values. 2.5 Terminals on restricted networks: capability A terminal connected to a network whose B-channels are effectively restricted to p ┤ 56 kbit/s (p = 1 to 6), or whose channels at H0 or higher are restricted by ones-density considerations, must declare the capability value (100)[22] as given in RecommendationH.221. All terminals intended for interworking with terminals on restricted networks must have the capability to respond to this code according to AnnexB. 2.6 Encryption and extension-BAS capabilities The capabilities are defined in Recommendation H.221. 3 Transmission 3.1 Transmission modes Audio modes of operation are defined in Recommendation H.221, AnnexA, audio commands. For analogue telephone terminals, it may be assumed that the speech signal is converted to PCM to G.711 at a digital network interface. These terminals are viewed as working in modeOU when connected to wideband speech terminals. The video transmission is governed by the video-on and video-off commands. When switched on, the video signal occupies all of the capacity, both in the initial channel and in any additional channels, which is not spe- cifically allocated to other signals by other commands. Thus different video bit rates will result from audio, transfer-rate, ECS and data commands the resultant video bit rate being: {transfer rate, less audio rate, less data rate if present, less encryption control channel if present, less FAS and BAS in all the channels/time-slots where they are present}. Transfer-rate modes are defined in Recommendation H.221, and spec- ify the total capacity of the communication effective in the subsequent sub- multiframe. Data modes are defined in Recommendation H.221, and specify only the bit rate and bit positions used for a user data signal. The protocol used for data applications is defined by the terminals, but see also º9. 3.2 Establishment of compatible modes of operation At the beginning of the communication phase of a call, all terminals start to work in modeOF (outgoing signal framed). Terminals other than those limited to G.711 capability will then begin an initialization procedure. This procedure (further described in º 6) consists of: û the transmission of information concerning the capabilities of the respective terminals for receiving and decoding audio, video, transfer rate, data rates and other capabilities; û the determination of a suitable transmission mode, consistent with the known capabilities of both terminals. An example is given in ºIV.1, in which the transmission mode is the same in both direc- tions, but the H.242 procedures are equally applicable to systems in which asymmetric bidirectional communication is optimal (examples are surveillance ûsee ºIV.2û and retrieval services); û switching to this mode; and establishing additional channels if rele- vant. The terminals connected to a call may change during the call. This may require re-initialization in order to identify the terminal type and to re-estab- lish the desired mode of operation. In particular, this feature is used in mode0 forcing, which is necessary in the case of a call transfer (see º8). 4 Frame structure The frame structure described in Recommendation H.221 is used for mode initialization and dynamic mode switching (see the following sec- tions) and more generally to define the multiplex of the various bit streams (audio, video, data, encryption control signal, frame structure) within the frame. Recommendation H.221 defines a Bit rate allocation signal (BAS) which is used inter alia to allocate sub-channels and to indicate the coding algorithm(s). BAS codes are classified by the value of the first three bits which rep- resent the BAS attribute: each attribute may therefore have up to32 defined values. Four BAS attributes are commands: they define the multiplex within the next and following sub-multiframes, as well as audio coding algorithm, and therefore command the distant receiver to treat the signals accordingly. The four attributes are independent; that is, a value of one attribute does not modify that of another. Further BAS attributes are defined to signal terminal capabilities to the distant terminal. When received, these attributes do not directly affect the current transmission mode. However, they may lead to the initiation of a specific action to be carried out by the terminal. This feature is utilized in the mode initialization procedure and in the mode0 forcing procedure (see º6). The third bit of the H.221 frame alignment signal (FAS) in odd frames of the initial channel, called the A-bit, is set to 1 on loss of frame or multi- frame alignment, and is set to 0 on acquiring both frame and multiframe alignment (see Note). Consequently, a terminal which is receiving a framed signal with the A-bit set to 0 can assume that the distant terminal is able to act upon a change of BAS. Note û A terminal having capabilities only for single-channel work- ing, and without encryption capability, does not need to seek and gain multi- frame alignment since the latter serves for numbering and synchronizing multiple channels. 5 Basic sequences for in-channel procedures Three signalling sequences are defined in this section. These sequences are used as the building blocks for the procedures defined in ºº6 and7. 5.1 Capability exchange sequence A The capability exchange sequence forces framing in both directions of transmission and the exchange of terminal capability codes. Either terminal may initiate the sequence and there is no problem caused by both doing so simultaneously or nearly simultaneously. Capability BAS should not be sent unnecessarily when the incoming signal is unframed. The terminal X which initiates the capability exchange sequence must first switch to a framed mode if previously transmitting unframed; it then sets a timerT1 (value 10seconds) and transmits its current capability set (see º2) repetitively, or at least one complete set followed by the marker code (to indicate completion of the set); these capabilities will be one or more of the set listed in Table1/H.242. When Y first detects any incoming capability code except neutral (see º5.3), it begins transmission of its own set of capability codes. This, of course, requires switching to a framed mode if transmission had been unframed. To ensure that each receives the complete set of capabilities of the other, they must continue repetitive transmission beyond the time they detect incoming A=0 by at least one complete set and the marker code. Note û See Note on G.725 terminals in º2. There are three possible outcomes: Outcome I: Within the timer expiration period, multiframe alignment has been gained, the A bit is received with a value of zero and the complete set of capability BAS codes of the distant ter- minal has been validated. In this case the sequence is com- pleted successfully. Note û If sequence A is initiated while incoming A = 0, rep- etition of the set is not necessary. Outcome II: The timer has expired without multiframe alignment. In this case, the sequence failed. Outcome III: The timer has expired with multiframe alignment achieved, but without either the validation of the A bit as 0 or the receiving of the complete set of the distant terminal's capability BAS codes (or both). In this case, the sequence is restarted. Out- come III should be notified to the user as a potential fault condition (which might, however, be in the remote terminal). 5.2 Mode switching sequence B Mode switching is performed using BAS command codes, each being effective from the beginning of the even frame following the sub-multiframe in which the code is first transmitted. Mode switching is possible at any time during a communication, after the initialization procedure has been com- pleted. When the transmitting terminal signals the mode of operation, this is valid from the next sub-multiframe. It is essential to note that transmitted signals must always be in accordance with the known capabilities of the remote terminal to receive and decode; in the absence of such knowledge, only mode OF or OU (audio to Recommenda-tionG.711) may be sent. If a change of capability, indicated in performing sequence A, has the result that the current mode is no longer receivable/decodable, there must be a switch as soon as possible to a mode which can be received and decoded. The receiving terminal decodes and validates the BAS code, and switches its receive mode of operation accordingly. If for any reason a ter- minal receives a BAS command it cannot obey, a mode mismatch may result (seeº6.3). In addition to switching of the audio mode, mode switching includes turning video off or on; the adoption/cessation of use of additional channels; the opening/closing of the encryption control channel; the opening/closing of a data channel. The mode switching is in principle performed independently for the two transmission directions; some applications may be fundamentally asymmetric. For conversational services the terminal procedures will gener- ally be such as to provide symmetrical transmission, though this is not man- datory. 5.3 Frame reinstatement sequence C (see Figure 1/H.242) If terminal A is transmitting unframed but receiving framed, frame reinstatement consists in the insertion of FAS and BAS into the first 16 bits of the service channel, waiting for incoming A = 0; the overlaid frame can contain neutral BAS capability to avoid triggering a full capacity exchange. A terminal A which is receiving unframed may wish the remote ter- minal B to reinstate framing: to do this, Amust first itself reinstate framing if it is not already transmitting framed and then send the neutral BAS capa- bility; Bmust respond by reinstating framing in order to return the neutral BAS capability and A=0, and continuing this at least until it receives A=0 itself. 6 Mode initialization, dynamic mode switching and mode 0 forcing Audiovisual terminals will be connected to digital networks where other kinds of terminals will also be connected: G.711 terminals but also data terminals, Telematic terminals, servers, etc. When compatibility between the different services involving those terminals is required, an ini- tialization procedure is necessary. When automatic compatibility is required, a procedure based on the sequences defined in º5 is used. For call transfer or mode mismatch recovery, it is necessary for termi- nals to operate in the common modeOF and a mode 0 forcing procedure is required, again based on the sequences defined in º5. At the commencement of the call, after call transfer and after the pro- cedure of º6.3, there is a need for an initialization procedure to ensure that the two connected terminals can operate in the most suitable common mode. 6.1 Mode initialization procedure 6.1.1 Single channel The initialization procedure begins as soon as a connection message is received from the network, or any indication meaning that the physical con- nection is established. At the beginning of mode initialization, each terminal will start to transmit in mode OF. The receive part of the terminal should be in frame search and the receive audio is modeOF. SequenceA is started. Upon completion of sequence A according to outcome I (see Figure2/H.242 outcomeIa), sequence B will commence. The BAS code which is sent in sequenceB is calculated from the knowledge of the capabil- ities of the local and distant terminals and is used to switch to a suitable working mode. This process may involve terminal procedures effecting choices made by the user or preset in the terminal. An example illustrating conformance to a defined teleservice is given in RecommendationH.320. In the event of outcome II, the terminal will switch its transmission and reception to mode OU. The receive part of the terminal should remain in frame search throughout the call. In the event of outcome III, timer T1 is reset and the terminal remains within sequence A. The initialization procedure is completed when both terminals have switched to the desired working mode(s). 6.1.2 Additional channels A possibility of adding more channels is established from the capabil- ity exchange sequence. The calling terminal may then immediately begin establishing the additional connections. When each is established, it trans- mits only FAS and BAS on that channel, setting a timer Ta of value 10seconds. Synchronization with the initial channel is performed according to RecommendationH.221, º2.7. When the incoming A bits on additional channels are observed to be 0, mode switching to occupy sequentially num- bered channels is initiated by an appropriate transfer-rate command BAS. If the timer Ta has expired without receiving A=0, it is dealt with as a fault condition. As the buffering process may involve the insertion of additional delay in the initial channel, which may already be carrying user information (speech, video, data), it may be necessary to make some provision for this interruption (e.g., short-term muting of audio output). As additional channels achieve synchronization they are sequentially numbered using both FAS and BAS numbering as provided in RecommendationH.221. An example of mode initialization on two channels is given in AppendixI. Figure 2/H.242 = 23.5cm 6.2 Dynamic mode switching (see Figure 3/H.242) The mode switching procedure makes use of the frame structure spec- ified in º4 and of the sequences defined in º5. It should be noted that all terminal receivers must remain in frame search throughout the call. When the terminal is receiving in a framed mode, that is, it is capable of decoding bit A, mode switching should be delayed if the A bit is set to 1; eventually the mode mismatch recovery procedure as described in º6.4 might be used. When the terminal X wishing to make a mode switch is receiving unframed signals, the capability exchange sequence may be used first to force the other terminal Y to a framed mode; hence terminal X can check for incoming A=0. This use of sequence A is particularly necessary if X was previously transmitting unframed signals, since Y would not be in a position to deal with a mode change from X until it had regained frame alignment (see º6.2.3). If X had previously been transmitting framed signals, the capability exchange sequence may be omitted on the assumption that if Y had unexpectedly lost frame alignment it would already have attempted a recovery procedure (see º7). 6.2.1 Dynamic mode switching from a framed mode to another framed mode The basic sequence mode switching described in º 5.2 is used. At the transmitting terminal, if a BAS command is transmitted to sig- nal a new mode, the transmitter must operate in the appropriate mode from the first octet of the next sub-multiframe. Similarly, at the receiving terminal, if the received BAS signals a new mode, the receiver must operate in the appropriate mode from the first octet of the next sub-multiframe. 6.2.2 Dynamic mode switching from a framed mode to an unframed mode As above in º 6.2.1, the basic sequence mode switching described in º 5.2 is used. However, as the BAS for signalling an unframed mode is transmitted for a single sub-multiframe, a mode mismatch may occur in drastic error conditions. Optionally, a method may be used to improve the reliability of the switching: the new BAS value in the basic sequence mode switching is repeated three times; this will cause a temporary corruption of the least sig- nificant bit of the received information. 6.2.3 Dynamic mode switching from an unframed mode to another mode (framed or unframed) The basic sequences frame reinstatement and mode switching are sequentially transmitted, the former including capability exchange if neces- sary. Figure 3/H.242 = 23.5cm 6.3 Mode 0 forcing procedure (see Figure 4/H.242) 6.3.1 Single channel Where it is necessary to ensure that both terminals are operating in mode 0 (for instance before call transfer), this procedure is used. The forcing terminal uses dynamic mode switching (º6.2) with BAS audio command to switch to modeOF, followed by sequenceA using BAS (100) indicating only G.711 audio capability. The value [1 or 2] appropriate to the terminal's own region is used in case the call is to be transferred to a local G.725 type-0 terminal. On receipt of this, the remote terminal is obliged to switch to modeOF also using the indicated law for its encoder and decoder. The procedure is complete when the forcing terminal detects incoming modeOF. Changes of network configuration can now be imple- mented (see º8). 6.3.2 Two or more channels In this case the mode 0 forcing is applied to the initial channel only, and separate considerations apply to treatment of the additional channels. Three cases are considered here by way of guidance for the multiple-B case: a) Additional channels dropped: This would be necessary, for exam- ple, prior to disconnection. The procedure is as for one channel, the forcing terminal declaring capability of PCM audio only with transfer rate capability of 1┤64kbit/s; this will result in mode switches successively to ôdata OFFö, ôvideo OFFö and audio modeOF or OU, such that all additional channels are vacated and can be disconnected. b) Additional channels idle: This is the same as a) above, except that the forcing terminal makes no move to disconnect; the channels carry FAS, the multiframe number and the BAS indicating channel number; the content of the remainder of the idle channels is irrele- vant. c) Additional channels maintained active: This might be beneficial in some recovery procedures. The forcing terminal declares a capa- bility of PCM audio plus transfer rate unchanged from its previous value, and then itself switches to the appropriate mode. An example of mode 0 forcing a) is given in Appendix II. 6.4 Mode mismatch recovery procedure In the case where mode mismatch has occurred, the mode 0 forcing procedure may be used to establish a common working mode. Following this procedure, re-initialization can be achieved by using the mode initializa- tion procedure. Figure 4/H.242 = 23.5cm 7 Recovery from fault conditions The provisions of this section are not wholly mandatory. In general it is expected that fault conditions will be rare and it may be uneconomical to provide elaborate recovery procedures to cover all eventualities. It is manda- tory that proper indications of fault conditions be transmitted on the outgo- ing channel(s) ûin particular, A must be set to 1 where appropriate conditions for A=0 are not met. Other action to be taken on losing frame alignment, multiframe alignment, synchronism, or a connection, or on receiving incoming A=1, is presented here for guidance. 7.1 Unexpected loss of synchronization or frame alignment 7.1.1 Loss of frame alignment in the initial channel If a terminal unexpectedly loses frame alignment on its receive path, a timer T3 is set (value for example 1 second) and incoming information is discarded if unintelligible. During this time the status of the framing in the receive direction is monitored: a) If framing is recovered before the timer expires, the normal opera- tion is resumed. b) If framing is not recovered before the timer expires, the terminal goes to the mode 0 forcing procedure followed by re-initialization. 7.1.2 Loss of frame alignment of synchronization in an additional channel If a terminal unexpectedly loses synchronization (including that due to loss of frame alignment) on an additional channel, a timer T3 is set, out- going A-bit is set to 1 and incoming information discarded if unintelligible; if the loss of this information also causes information on other channels to become meaningless that also is discarded. a) if synchronization is recovered before the timer expires, normal operation is resumed; this takes into account recoverable synchro- nization loss due to bit or synchronization errors on the transmis- sion line; b) if synchronization is not recovered before the timer expires, the mode 0 forcing procedure may be used. 7.2 Recovery from loss of connection(s) Loss of a connection means that end-to-end transmission on that channel has been discontinued, so that all apparently received bits are mean- ingless. The receiver will, of course, lose frame alignment and may follow the procedures of º7.1. However, an indication may be available from the network (D-channel or otherwise) that the connection has been lost; in this case the procedures of this section are followed. It is assumed that connec- tion loss is bidirectional; the case of loss in one direction only is for further study. 7.2.1 Renumbering of channels This procedure is used for reconstructing the remaining normal addi- tional channels when one additional channel breaks down. i) Make the transmission mode of all channels into ôframedö. ii) Vacate the sending additional channel(s). iii) Renumber the additional channel(s). iv) Wait for the synchronization establishment of the remote terminal and then expand communication onto the additional channels. 7.2.2 Loss of an additional connection If any remaining channels are unframed (for example, data transmis- sion) they must immediately have frame structure (according to RecommendationH.221) reimposed and maintained until conditions have returned to normal. The outgoing A-bit on additional channels is set to 1 if the incoming direction is unframed or out of sequence, or if synchronism has been lost. If the lost channel was carrying part of a signal (such as encoded video) which also involved other channels, so that its loss renders the infor- mation in those other channels meaningless, then by dynamic mode switch- ing those channels are vacated. The next step is to renumber the available channels if appropriate, to obtain a continuous sequence; this is done using the procedure of º7.2.1. Dynamic mode switching is applied to re-establish the video or other transmission on the channels for which incoming A-bits are zero. In the event that the lost channel be reconnected, it is added to the capacity in the same way as at the start of the call. 7.2.3 Loss of the initial connection This results in the loss of the initial channel in both directions. Both terminals immediately regard #2 as the initial channel and transmit thereon the following BAS: i) Reinstatement of FAS and BAS in any unframed channels. ii) Transfer rate (001) [0 or 6] û code having the effect of vacating all additional channels; also audio command (000) unchanged from previous value. iii) Transfer rate (001) [17] on original second channel, indicating loss of original channel, and from next sub-multiframe original second channel substitutes for original initial channel; simultaneously any additional channels are renumbered in sequence. iv) Wait for confirmation that the synchronism at the remote terminal is retained/regained (all incoming An=0); v) Expand communication onto all channels using appropriate trans- fer-rate command. (Note û As a result of this procedure, sending and receiving initial channels may not be on the same connection.) vi) The terminal tries to re-establish the lost channel. 8 Network consideration: call connection, disconnection and call trans- fer 8.1 Call connection 8.1.1 Initial channel It is assumed that the terminals for switched network operation will have a signalling arrangement for originating calls over the network. In the case that the network provides an indication that the connection is established (CONNECT-ACK message), the originating terminal will set its transmit and receive audio modes to PCM and begin the mode initializa- tion procedure following the connection establishment indication. Where the network does not provide an indication of connection establishment, the originating terminal will begin the mode initialization procedure immedi- ately. Upon answering a call, the terminal will begin the mode initialization procedure. Terminals for use on leased circuits may have a means for sending the alerting signal to the distant terminal and for answering the alerting signal. In this case, the sending of the alerting signal is equivalent to dialling and the foregoing procedures apply. Whenever a terminal is manually reset, or recovers from a fault condi- tion, the terminal will begin the mode0 forcing procedure of º6.3. Then the terminal will begin mode initialization. 8.1.2 Additional channels Call connection to provide additional channels may be initiated by one of the following: a) manually; b) on completion of the capability exchange sequence indicating mutual additional-channel capability; c) at some time later than in b), prompted by user action. The choice between these will depend on service provision and/or ter- minal procedures. When the establishment of connection is known to the terminal, the mode initialization procedure of º6.1.2 is applied. During call establishment, an originating terminal should reserve additional channels by not answering incoming calls on those channels until it is determined whether the additional channels will be used in the connec- tion. This prevents multiple call collisions and contention for the available channels. A network solution is under study. 8.2 Terminal disconnection When a terminal disconnects from a call, the terminal must first ini- tiate the mode 0 forcing procedure, await completion of the procedure and then allow the actual disconnection of the call to occur. 8.3 Call transfer As a consequence of the above, the terminal which continues to par- ticipate in a transferred call will be receiving in a PCM-forced state and therefore will be transmitting its capability set in framed PCM. When the transferred-to terminal answers, mode initialization will occur in both direc- tions. 8.4 Conferencing Conferencing will be accomplished by means of a multipoint control unit (MCU). Each terminal will be connected to a port of the MCU by a switched connection or a leased circuit. Each connection between the termi- nal and the MCU is considered to be a point-to-point connection as far as call connection, terminal disconnection and call transfer procedures are con- cerned. 8.5 PCM format conversion In the above procedures, no automatic method for establishing A-law or m-law compatible PCM operation was defined. At the beginning of the call, encoding and decoding by each terminal is to the law prevailing in its own region. The decoder must adapt to the cod- ing law of the incoming signals. In a framed signal this will be clear from the BAS command; for unframed audio, signal analysis or local knowledge should be applied, and if this indicates that the other terminal is using a dif- ferent coding law then the H.242 terminal should switch both its encoder and decoder to the coding law of the other terminal. In the case where both terminals transmit framed signals, once the capability exchange is completed they may transmit in either PCM mode if desired. Before call transfer, in the case where both terminals can transmit framed audio, the distant terminal's encoder and decoder must be forced by the relevant BAS capabilities and commands to the coding law of the region where the transfer is to take place. 9 Procedure for activation and de-activation of data channels 9.1 Data equipment not conforming to Recommendation H.200/AV.270 Each terminal must transmit a data-rate capability code (see Recom- mendation H.221) for each data rate it is able to receive. This may be done during the capability exchange sequence at the start of the call or at a later time by initiating a new capability exchange. A terminal may transmit data at any rate which has been indicated in the data-rate capability codes it has received from the other terminal. The appropriate data command (see RecommendationH.221) is sent and in the following sub-multiframe the data transmission is commenced, occupying the bits within each frame defined in RecommendationH.221. However, at the time the data command is first sent, these bits must be unoccupied or contain only video information; therefore audio or any other signals must be removed from this part of the frame with the prior transmission of an appro- priate command. In the case of occupancy by video information, commands are not available to reduce the video rate, but the video decoder continues to operate correctly on the lower flow of information. However, if the video rate is being made very low (for example, less than 30.4kbit/s) or stopped altogether by the introduction of a data stream, it is advisable first to send freeze-picture request, followed by the video OFF command. The command variable LSD identifies as a data path the whole of the I-channel capacity not otherwise allocated by other commands; it must not be used when variable MLP is on, or when another LSD value is in force. If used while video is on, video is excluded from the I-channel. At the conclusion of the data transmission the data OFF command is sent. If video is ON, it will then occupy the freed bits in the next sub-multi- frame and thereafter; otherwise those bits remain unoccupied until another command is sent. At any time during data transmission the rate may be changed by an appropriate data command, subject to the provisions given above. Note û In the case where 64 kbit/s HSD, for example, has been trans- mitted in the highest-numbered channel of a multiple-B channel connection, a slip during this data transmission would leave a misalignment when the HSD is turned off. To avoid corruption of video under these circumstances, it may be advisable to switch off the video stream before sending HSD-off, switching it on again as soon as A=0 is received on the erstwhile data chan- nel. 9.2 Equipment operating with an MLP according to RecommendationH.200/AV.270 Each terminal capable of operating with an MLP must transmit one of the MLP-capability codes. This may be done during the capability exchange sequence at the start of the call, or at a later time by initiating a new capabil- ity exchange. When terminal X wishes to transmit MLP, it transmits MLP ON at the appropriate rate. Receiving the latter, terminal Y must establish an MLP channel at an appropriate rate (not necessarily the same rate) in the return direction. The above provisions apply equally to the use of MLP on the I-chan- nel, or in other channels or time-slots. Normally only one of these is required; however if both are in force, with appropriate commands, then a single MLP sub-channel at the combined rate may be interpreted ûthis would be specified within the appropriate service Recommendation (e.g. MLP rates of about 100kbit/s on a 2Bcall). To change the MLP rate, an appropriate MLP command is sent. To discontinue use of the MLP, this matter may first be negotiated within the MLP itself; then one or both terminals transmit MLP-OFF. 9.3 Simultaneous transmission of low-speed data and MLP LSD and MLP may be active simultaneously, provided that no overlap is implied by the commands in force; however, variable LSD and variable MLP cannot coexist. No more than one LSD channel and one MLP channel may be active at any time (see also º12). 10 Procedures for operation of terminals in restricted networks Under study; the following paragraphs give preliminary consider- ations. Terminals connected to a restricted network shall transmit the BAS capability ôrestrictedö (100)[22] continuously when receiving an incoming A=1 at the start of a call. 10.1 Network aspects In this Recommendation the term ôrestricted networkö applies to a network having restricted 64 kbit/s transfer capability, defined in RecommendationI.464 as 64 kbit/s octet-structured capability with the restriction that an all-zero octet is not permitted. 10.2 Reference connections 10.2.1 Case 1: 56 kbit/s, V.35 interfaces Figure 5a)/H.242 shows a reference connection by a 56 kbit/s data service using V.35 interfaces. A 56 kbit/s clock is available at the V.35 inter- face; 8kHz clock is not assumed. Figure5c)/H.242 shows a reference con- nection, connected by 56kbit/s network service with network clock. 10.2.2 Case 2: n ┤ 56 kbit/s, V.35 interfaces Figure 5b)/H.242 shows a reference connection with more than two 56 kbit/s connections. Frame alignment will be according to H.221. Neither septet timing nor septet alignment is assumed. Figure5d)/H.242 shows a multiple n┤56 kbit/s without septet alignment or septet timing. 10.2.3 Case 3: n ┤ 64 kbit/s with octet timing and alignment Figure 5e)/H.242 shows a reference connection consisting of two visual telephones connected by facilities operating in a private line environ- ment. Unrestricted mode of operation is not assumed. 10.2.4 Case 4: H0 (384 kbit/s) operation When working in a restricted network a ô1ö shall be placed in the eighth bit position of every octet of every time-slot; the service channel is then in the seventh bit. 10.2.5 Case 5: 56 kbit/s satellite operation For further study. 10.2.6 Case 6: 56 kbit/s interconnecting a 64 kbit/s network A 64 kbit/s terminal will interwork with a 56 kbit/s terminal as a rate adapted data call over a 64 kbit/s bearer channel. The terminal connected to the 64kbit/s connection will rate adapt according to RecommendationH.221. In the case of a 64kbit/s terminal connected to ISDN, the terminal may optionally be equipped to intercommunicate through an ISDN V.35 terminal adaptor. In any case, because the 56kbit/s terminal cannot transmit correctly aligned septets, the terminal at the 64kbit/s end cannot assume septet timing. 10.3 Transmission formats 10.3.1 Framing signal (56 kbit/s) The transmission shall be arranged in 80 septet frames as specified in RecommendationH.221. 10.3.2 Transmission formats (56 kbit/s operation) In 56 kbit/s operation the septets of each 7 ┤ 80 bit frame will be trans- mitted in order, most significant bit first at the 56kbit/s rate. Septet align- ment will be recovered from the frame alignment signal as specified in RecommendationH.221. 10.3.3 n ┤ 56 kbit/s operation In n ┤ 56 kbit/s operation each 56 kbit/s connection will be framed and transmitted separately. Septet timing will be recovered independently from the frame alignment signal of each channel, and the different delay between the channels will be compensated for on the basis of the multiframe num- bering method specified in RecommendationH.221. The voice signal will be carried in the initial connection and video, graphics and auxiliary data may be carried in the initial and/or other connec- tions. 10.3.4 n ┤ H0 operation In n ┤ H0 operation, each connection will be framed separately and differential delay between the channels will be compensated according to RecommendationH.221. 10.3.5 Dynamic allocation within a primary-rate connection Intelligent terminals may have a means for dynamically increasing or decreasing the bit rate during a connection. The means for controlling these allocations will be performed according to RecommendationH.221. There may be a need to recover framing by extraction from the received signal independently. 10.4 Interworking between 56 kbit/s and 64 kbit/s terminals In the worst case it must be assumed that neither terminal is aware (by means of a D-channel message or otherwise) that it is connected to a termi- nal of the other type; furthermore septet timing cannot be assumed at the 56kbit/s end. At the 64kbit/s end, byte timing is indispensable, since with- out this it cannot be known which bit (1 in every8) will not be transmitted to the remote end (see Figure2/H.242, outcomeIV). Initially, terminal X (at 64 kbit/s) transmits FAS and capability-BAS on bit 8, on the false assumption that the remote terminal is also at 64kbit/s. Frame search is carried out on the whole incoming signal; clearly, searching only on bit8 will result in outcomeII (see Figure2/H.242). Figure 5/H.242 = 23.5cm If frame alignment is found, and this may be in any bit position, given the lack of septet timing at the other end, then the fact of interworking with a 56kbit/s terminal immediately becomes known from the capability BAS, which terminal Y must include in its capability BAS cycle. Terminal X immediately changes to transmitting FAS and BAS on bit7, since bit8 is the one which is not transmitted through the restricted networks. Initializa- tion should then proceed as in º6.1, with outcomeIb in Figure2/H.242. In the event that no frame alignment is found in any sub-channel, outcomeII of º6.1.1 applies. Note 1 û All 56 kbit/s audiovisual terminals must transmit the appropriate capability BAS (100)[22] in every capability exchange. Note 2 û Unless it is sure that they will never be required to interwork with 56kbit/s networks, terminals manufactured for use on 64kbit/s networks should preferably have the capability to search for frame alignment in all bit positions. Note 3 û It may be advisable to mute audio output until incoming frame alignment has been achieved or a switch to unframed PCM has been decided upon. 10.5 Interworking between H0 or H11 terminals in restricted and unre- stricted networks At the start of the communication, the terminal on the restricted net- work transmits framed signals with the service channel in bit7 of the I-- channel and all ô1ös in bit8; the restricted capability BAS(100)[22] is sent. In the terminal on the unrestricted network, frame search is carried out on the whole incoming signal (or incoming TS1 if synchronization between H0/H11 framing and H.221 framing is maintained). When BAS(100)[22] is detected, a terminal immediately shifts the outgoing service channel to bit7 and sets all ô1ös on bit8 of every time-slot. All terminals intended for interworking with terminals connected to restricted networks must be capable of performing this procedure. 11 Procedure for use of BAS-extension codes Recommendation H.221 provides for the attribute (111) for extension of the use of the BAS position in the subsequent sub-multiframe(s) for other purposes. There are 32values of this attribute, the meanings of these being defined in RecommendationH.221. Note that the value (111)[24] is the capability marker (see º2) which is followed by normal BAS codes, not by any escape values. Values [0-15] are reserved for future extension of the scheme to include attribute class and family. Values [16-23] are defined as single-byte extension (SBE); codes of SBE type may be transmitted at any time and to any terminal. Value [18] gives access to a table of values specifying applications of a data channel (LSD or HSD). The application is active from the sub-multi- frame following that in which the relevant specific application command BAS is transmitted. The closure of the data channel (using LSD/HSD-off) effectively closes the application. All terminals must recognize the SBE attributes, at least to the extent of ignoring the subsequent code, whose meaning is not prescribed in this Recommendation. However, when(111)[17] is received, the subsequent code may be one of the mandatory values specified in RecommendationH.230. The ability of a terminal to use the content of other such codes is governed by other Recommendations. For example, RecommendationH.320 defines the requirements for visual telephone ter- minals to act upon some of the control and indication values. Values [25-31] are of multiple byte extension (MBE); codes of MBE may only be transmitted to a terminal which has previously indicated its capability to receive MBE. It follows that a non-CCITT capabilities mes- sage may not be transmitted in the initial capability exchange, until the MPE-cap has been received. An example of the structure of MBE messages is given in AppendixIII. 12 Bit occupancy and the sequencing of BAS codes In general, when there is no set procedure governing the sequence of BAS codes, priorities may be determined by the sending terminal. When there is no other demand for use of the BAS position, it is advisable to cycle through all the valid BAS commands, so that in the event of a temporary dis- turbance the proper mode will be restored as soon as possible thereafter. Table 1/H.242 summarizes the BAS capabilities that can be simulta- neously valid. The capability set consists of the capability marker (111)[24] fol- lowed by all currently valid values, in any order; this may in turn be fol- lowed by a repetition of the set, or by the marker alone to indicate completion of the set prior to sending commands. No values should be repeated within a set. If it is desired to change the capability set during its transmission, the existing set must first be completed without change, fol- lowed by the marker alone and at least one BAS command before the new, changed set is started. Table 2/H.242 summarizes the BAS commands that can be simultaneously valid. Only one value in each row can be in force at any one instant, up to 17values on the initial channel (all the above values except (001)[18-22] apply only to the initial channel); however in practice many of the combina- tions are precluded by the fact that they would affect the same bits of the channel (for example, (011)[31] and (011)[19] cannot coexist). A command remains in force until another from the same row is transmitted. A command must not be transmitted if to obey it would cause a simulta- neous mode change on another row; in such a case the other row value must be changed first (for this purpose, a change of bit-rate of video or any of the variable data values does not constitute a mode change). In general, unless specified otherwise, a BAS code which is invalid or which contravenes the provisions of this table, or otherwise indicates an impossible frame structure or system status, must not be transmitted. The following notes serve to clarify the application of these rules to the mul- tiplexing of audio, video and the various forms of data. Some examples relating to data transmission are given in AppendixV. a) Audio cannot penetrate into fixed rate Data (LSD or MLP) bit posi- tions. It can expand its capacity into vacant or video or variable data bit positions. It can reduce its capacity within the audio bit positions currently occupied. b) Video occupies all bit positions which are not assigned by other commands (ECS, Audio, LSD/MLP regardless of being fixed rate or variable rate). Video can be turned on at any time even if the available capacity for video is zero at the corresponding sub-multiframe; (it may happen, for example, that video is switched on just before the variable rate LSD or MLP channel is closed); the decoder must not ignore ôvideo onö even in this case, otherwise a mode mismatch occurs. However, if video capacity is less than about 30kbit/s averaged over several sub-multiframes, it may not be practical. It should be noted that video-off, (010)[0], is preferably preceded by freeze-picture request, (010)[16]. c) Fixed rate LSD/MLP cannot penetrate into Audio bit positions nor into fixed rate MLP/LSD bit positions. It can expand its capacity into vacant or video or variable MLP/LSD bit positions. It can reduce its capacity within the data bit positions currently occupied. As a combination, fixed rate LSD/MLP can occupy new bit posi- tions which have previously been either vacant, video, variable rate MLP/LSD or occupied by the same type of fixed rate data. d) Variable rate LSD/MLP occupies all bit positions which are not assigned by other fixed rate commands (ECS, Audio, fixed rate MLP/LSD). If video has been on, it is excluded when variable rate LSD or MLP is turned on. If variable rate LSD/MLP has been on, opening a variable rate MLP/LSD channel should be preceded by closing the existing variable rate LSD/MLP channel. Variable rate LSD or MLP can be turned on at any time even if the available capacity for it is zero at the corresponding sub-multi- frame; (it may happen, for example, that the variable MLP is switched on just before closing the LSD channel which has been occupying all the capacity other than audio); the decoder must not ignore ôvariable rate LSD or MLP onö even in this case, otherwise a mode mismatch occurs. e) LSD/MLP rate may be changed without first closing the data chan- nel û this applies equally to changes between fixed and variable rate. It is emphasized that there can only be one LSD and one MLP channel at any instant. f) Capacity of video or variable LSD/MLP can be temporarily reduced to zero in a sub-multiframe as part of dynamic bit rate allocations. It is impractical, however, if that situation continues for a long time. g) The rules for the use of HSD and H-MLP (in other than the I- -channel) are identical to those given above for LSD and MLP in the I--channel. 13 Procedure for dealing with 6B-H0 interconnection For further study. 14 Procedure for use of encryption control signal channel Each terminal must transmit the encryption capability code if it is able to handle the ECS channel. No terminal may activate the channel without first receiving the corresponding capability code. Once an ECS capability code has been transmitted it cannot be cancelled by omission from a subse- quent capability exchange. That is to say, a terminal having once received, stored and made use of an ECS capability code should assume continued validity until cancelled by the local user. Thus encryption can be discontin- ued by the users themselves but not by a third party tampering with the BAS-capability exchange. The initiating terminal transmits the command ôECS channel ONö; from the next multiframe it opens the 800bit/s ECS channel defined in RecommendationH.221, whose use is specified in the Recommendation defining the encryption system (FAS, BAS and the ECS channel itself are in any case not encrypted). When encryption has been turned off, the BAS command ôECS chan- nel OFFö is used to close the ECS channel. APPENDIX I (to Recommendation H.242) Initialization: Case of Videophone to Recommendation H.320, Type Xb3 Underlined letters in the comments column correspond to points in the asso- ciated Figure I-1/H.242. FIGURE I-1/H.242 = 23.5 cm APPENDIX II (to Recommendation H.242) Mode-0 forcing: Case of Videophone to Recommendation H.320, Type Xb3 Underlined letters in the comments column correspond to points in the asso- ciated FigureII-2/H.242. The mode-0 forcing procedure is not complete: subsequent action depends on the terminal procedure, according to the reason for performing the switch to mode0 FIGURE II-2/H.242 = 9.5 cm APPENDIX III (to Recommendation H.242) Example of use of message structure Send Receive III.1 Initial capability exchange, including MBE-cap (111) [24] Capability-mark (100) [4] Audio Type 2 (G.722, 56kbit/s) (100) [17] 2 ┤ 64 kbit/s transfer rate (101) [21] CIF video capability (101) [22] 1/29.97 MPI for QCIF (101) [23] 2/29.97 MPI for CIF (101) [31] MBE-capability (111) [16] Set to escape table for HSD Send Receive (101) [17] 64 kbit/s HSD-capability (111) [24] Capability-mark, repetition of capability set (100) [4] Audio Type 2 (Rec. G.722, 56kbit/s) . . . . . . . . . decode incoming BAS capabilities: these include (101)[31], so remote end can handle MBE codes III.2 Subsequent capability exchange, including MBE capability message (111) [24] Capability-mark (100) [4] Audio type2 (Rec. G.722, 56kbit/s) (100) [17] 2 ┤ 64 kbit/s transfer rate (101) [21] CIF video capability (101) [22] 1/29.97 MPI for QCIF (101) [23] 2/29.97 MPI for CIF (101) [31] MBE-capability (111) [16] Set to escape table for HSD (101) [17] 64 kbit/s HSD-capability (111) [30] Start of non-CCITT capability message {M} Information will be M bytes {byte1} Country code according to Recommendation T.35 {byte2} Country code {bytes3,4} Manufacturer code (Company XYZ) {bytes5-M} Type identity (111) [24] Capability-mark, repetition of capability set (100) [4] Audio type2 (Rec. G.722, 56kbit/s) . . . . . . . . . incoming capability cycle now includes the same non- standard mode III.3 Mode switch to non-standard mode using MBE command (111) [30] Start of non-CCITT command message {N} Information will be N-bytes {byte1} Country code according to Recommendation T.35 {byte2} Country code {bytes 3,4} Manufacturer code (Company XYZ) {bytes5-N} Type identity The mode switch is effective from the sub-multiframe following that containing byte N. APPENDIX IV (to Recommendation H.242) Examples of symmetrical and unsymmetrical transmission modes IV.1 Example of symmetrical transmission mode IV.2 Example of unsymmetrical transmission mode APPENDIX V (to Recommendation H.242) Examples relating to data transmissions Note û For the examples given below: * These rates are reduced by 800 bit/s when the ECS is active; # ôVideo-onö may not be practical in these cases. V.1 Transfer-rate 1B, audio at 48 kbit/s, no video or video off MLP LSD Forbidden next commands (example) 4k 1200 #, LSD = 4.8k/6.4k/14.4k and over, MLP = 6.4k 4k 8k Au = 56k, #, LSD = 4.8k/6.4k/14.4k and over 4k var #, LSD = 4.8k/6.4k/14.4k and over, MLP = var 6.4*k 8k Au = 56k, #, LSD = 300/1200/4.8k/6.4k/9.6k/14.4k and over var 1200 #, LSD = 16k and over/var, MLP = 6.4k var 6.4k #, LSD = 16k and over/var, MLP = 4k/6.4k var 9.6k Au = 56k, #, LSD = 16k and over/var, MLP = 6.4k V.2 Transfer-rate 1B, audio at 16 kbit/s, no video or video off MLP LSD Forbidden next commands (example) 4k 300 LSD = 4.8k/6.4k/14.4k/48k and over, MLP = 6.4k 4k 8k Au = 56k, LSD = 4.8k/6.4k/14.4k/48k and over 4k 16k Au = 48k/56k, #, LSD = 4.8k/6.4k/14.4k/48k and over 4k var #, LSD = 4.8k/6.4k/14.4k/48k and over, MLP = var 6.4*k 8k Au = 56k, LSD = 300/1200/4.8k/6.4k/9.6k/14.4k/48k and over 6.4*k 40k Au = 48k/56k, #, LSD = 300/1200/4.8k/6.4k/9.6k/14.4k/48k and over var 4.8k #, LSD = 48k and over/var, MLP = 4k/6.4k var 9.6k Au = 56k, #, LSD = 48k and over/var, MLP = 6.4k var 16k Au = 48k/56k, #, LSD = 48k and over/var V.3 Transfer-rate 1B, audio at 16 kbit/s, video on MLP LSD Forbidden next commands (example) 4k 1200 LSD = 4.8k/6.4k/14.4k/48k and over, MLP = 6.4k 4k 8k Au = 56k, LSD = 4.8k/6.4k/14.4k/48k and over 6.4*k 8k Au = 56k, LSD = 300/1200/4.8k/6.4k/9.6k/14.4k/48k and over V.4 Transfer-rate 2B, audio at 48 kbit/s, video on MLP LSD Forbidden next commands (example) var 1200 LSD = 16k and over/var, MLP = 6.4k var 4.8k LSD = 16k and over/var, MLP = 4k/6.4k var 9.6k Au = 56k, LSD = 16k and over/var, MLP = 6.4k 4k 8k Au = 56k, LSD = 4.8k/6.4k/14.4k/16k and over V.5 Transfer-rate 2B, audio at 16 kbit/s, video on MLP LSD Forbidden next commands (example) var 1200 LSD = 48k and over/var, MLP = 6.4k var 4.8k LSD = 48k and over/var, MLP4k/6.4k var 8k Au = 56k, LSD = 48k and over/var var 16k Au = 48k/56k, LSD = 48k and over/var 4k 8k Au = 56k, LSD = 4.8k/6.4k/14.4k/48k and over var Variable LSD Low speed data HSD High speed data MLP Multi-layer protocol