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 Telecommunication 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 prepared 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 utilized in any form or by any means, electronic or mechanical, including photocopying 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 7 kHz audio codec within 64 kbit/s), H.221 (Frame structure for 64 to 1920 kbit/s channels in audiovisual teleservices) and H.230 (Frame-synchronous control and indication signals for audiovisual systems).
	A number of applications utilizing narrow (3 kHz) and wideband (7 kHz) speech together with video and/or data have been identified, including 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 channel accommodates speech, and optionally video and/or data at several rates, in a number of different modes. Signalling procedures are required to establish 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 according to the procedures in this Recommendation be B (64 kbit/s), H0 (384 kbit/s), H11 (1536 kbit/s) or H12 (1920 kbit/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 capabilities 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 terminal with capability value N 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 corresponding information), can be ignored.

	The total capability of a terminal to receive and decode various signals 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 Recommendation H.221, Annex A; Table 1/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 Recommendation G.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 quarter-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 64 kbit/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 synchronize the connected additional channels to the initial channel and maintain 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 case 1B 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 Recommendation H.221. All terminals intended for interworking with terminals on restricted networks must have the capability to respond to this code according to Annex B.

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, Annex A, 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 mode OU 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 specifically 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 specify 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 mode OF (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 directions, 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 relevant.
	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-establish the desired mode of operation. In particular, this feature is used in mode 0 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 sections) 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 represent the BAS attribute: each attribute may therefore have up to 32 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 mode 0 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 multiframe 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 working, and without encryption capability, does not need to seek and gain multiframe 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 and 7.
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 timer T1 (value 10 seconds) 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 Table 1/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 terminal has been validated. In this case the sequence is completed successfully.
				Note – If sequence A is initiated while incoming A = 0, repetition 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. Outcome 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 completed.
	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-tion G.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 terminal 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 generally be such as to provide symmetrical transmission, though this is not mandatory.
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 terminal B to reinstate framing: to do this, A must first itself reinstate framing if it is not already transmitting framed and then send the neutral BAS capability; B must 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.

Frame reinstatement sequence C
(without consideration of restricted networks)				
Is current outgoing signal
64 kbit/s data? (mode 10)				

N	
½½½½½½½½½½¯	
	½	Y
	½
	Send framed signal with suitable data command (62.4 kbit/s or less) – note that data is corrupted in the receiver until FAS is recovered at other end; interleave neutral-cap if relevant.	
Is current outgoing signal
64 kbit/s Video?				

N	
½½½½½½½½½½¯	
	½	Y
	½
	Send framed signal with (000) [31] and (010) [1] – note that video is corrupted in the receiver until FAS is recovered at other end; interleave neutral-cap if relevant.	
Is current outgoing signal
Audio Mode 1?				

N	
½½½½½½½½½½¯	
	½	Y
	½
	Overlay framing without mode change; use (000) [6] and interleave neutral-cap if relevant.	
The current mode must be
PCM audio.				
	½
	½

				Send mode OF with (000) [18 or 19] and interleave neutral-cap if relevant.	
Frame reinstatement sequence C
(application to restricted networks)				
Is current outgoing signal
56 kbit/s data? 				

N	
½½½½½½½½½½¯	
	½	Y
	½
	Send framed signal with suitable data command (54.4 kbit/s or less) – note that data is corrupted in the receiver until FAS is recovered at other end; interleave neutral-cap if relevant.	
Is current outgoing signal
56 kbit/s Video?				

N	
½½½½½½½½½½¯	
	½	Y
	½
	Send framed signal with (000) [31] and (010) [1 or 2] – note that video is corrupted in the receiver until FAS is recovered at other end; interleave neutral-cap if relevant.	
Is current outgoing signal 56 kbit/s
of Recommendation G.722?				

N	
½½½½½½½½½½¯	
	½	Y
	½
	Overlay framing without mode change and interleave neutral-cap if relevant.	
The current mode must be
PCM audio.				
	½
	½
				Send mode OF with (000) [18 or 19] and interleave neutral-cap if relevant.	
FIGURE 1/H.242

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 initialization 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 terminals to operate in the common mode OF 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 procedure 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 connection 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 mode OF. Sequence A is started.
	Upon completion of sequence A according to outcome I (see Figure 2/H.242 outcome Ia), sequence B will commence. The BAS code which is sent in sequence B is calculated from the knowledge of the capabilities 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 Recommendation H.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 capability exchange sequence. The calling terminal may then immediately begin establishing the additional connections. When each is established, it transmits only FAS and BAS on that channel, setting a timer Ta of value 10 seconds. Synchronization with the initial channel is performed according to Recommendation H.221, § 2.7. When the incoming A bits on additional channels are observed to be 0, mode switching to occupy sequentially numbered 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 Recommendation H.221.
	An example of mode initialization on two channels is given in Appendix I.
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 specified 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 signal 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 significant 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 necessary.
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 mode OF, followed by sequence A 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 mode OF also using the indicated law for its encoder and decoder. The procedure is complete when the forcing terminal detects incoming mode OF. Changes of network configuration can now be implemented (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 example, 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 ´ 64 kbit/s; this will result in mode switches successively to “data OFF”, “video OFF” and audio mode OF 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 irrelevant.
c)	Additional channels maintained active: This might be beneficial in some recovery procedures. The forcing terminal declares a capability 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 initialization 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 mandatory that proper indications of fault conditions be transmitted on the outgoing 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 operation 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, outgoing 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 synchronization loss due to bit or synchronization errors on the transmission 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 meaningless. 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 connection 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 additional 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 transmission) they must immediately have frame structure (according to Recommendation H.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 information in those other channels meaningless, then by dynamic mode switching 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 transfer-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 transfer
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 initialization 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 immediately.
	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 condition, the terminal will begin the mode 0 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 terminal 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 connection. 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 initiate 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 participate 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 directions.
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 terminal and the MCU is considered to be a point-to-point connection as far as call connection, terminal disconnection and call transfer procedures are concerned.
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 coding 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 different 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 Recommendation 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 Recommendation H.221) is sent and in the following sub-multiframe the data transmission is commenced, occupying the bits within each frame defined in Recommendation H.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 appropriate 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.4 kbit/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-multiframe 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 transmitted 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 channel.
9.2	Equipment operating with an MLP according to Recommendation H.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 capability 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-channel, 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 100 kbit/s on a 2B call).
	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 considerations.
	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 Recommendation I.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 interface; 8 kHz clock is not assumed. Figure 5c)/H.242 shows a reference connection, connected by 56 kbit/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. Figure 5d)/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 environment. 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 64 kbit/s connection will rate adapt according to Recommendation H.221. In the case of a 64 kbit/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 56 kbit/s terminal cannot transmit correctly aligned septets, the terminal at the 64 kbit/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 Recommendation H.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 transmitted in order, most significant bit first at the 56 kbit/s rate. Septet alignment will be recovered from the frame alignment signal as specified in Recommendation H.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 numbering method specified in Recommendation H.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 connections.
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 Recommendation H.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 Recommendation H.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 terminal of the other type; furthermore septet timing cannot be assumed at the 56 kbit/s end. At the 64 kbit/s end, byte timing is indispensable, since without this it cannot be known which bit (1 in every 8) will not be transmitted to the remote end (see Figure 2/H.242, outcome IV).
	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 64 kbit/s. Frame search is carried out on the whole incoming signal; clearly, searching only on bit 8 will result in outcome II (see Figure 2/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 56 kbit/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 bit 7, since bit 8 is the one which is not transmitted through the restricted networks. Initialization should then proceed as in § 6.1, with outcome Ib in Figure 2/H.242.
	In the event that no frame alignment is found in any sub-channel, outcome II 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 56 kbit/s networks, terminals manufactured for use on 64 kbit/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 unrestricted networks
	At the start of the communication, the terminal on the restricted network transmits framed signals with the service channel in bit 7 of the I-channel and all “1”s in bit 8; 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 bit 7 and sets all “1”s on bit 8 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 32 values of this attribute, the meanings of these being defined in Recommendation H.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-multiframe 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 Recommendation H.230. The ability of a terminal to use the content of other such codes is governed by other Recommendations. For example, Recommendation H.320 defines the requirements for visual telephone terminals 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 message 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 Appendix III.

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 disturbance the proper mode will be restored as soon as possible thereafter.
	Table 1/H.242 summarizes the BAS capabilities that can be simultaneously valid.
TABLE 1/H.242
Capability summary
Audio	One or more values from A-law, m-law, G.725-T1, G.725-T2, Au-16 kbit/s, Au-ISO	
Video	Absent, or (QCIF plus one MPI value), or (QCIF + CIF plus two MPI values), and/or video‑ISO and/or AV-ISO	
Transfer rate	Absent (meaning rate = 64 kbit/s only a)) or up to four values: max. no. of 64, 384 kbit/s channels, 1536, 1920 kbit/s; and optionally any relevant values from {128, 192, 256, 512, 768, 1152, 1472 kbit/s}	
Restricted network	Absent or present	
Low-speed data (LSD)	Absent or all relevant values	
High-speed data (HSD)	Absent or all relevant values	
Low-speed MLP	Absent or all relevant values	
High-speed MLP	Absent or all relevant values	
Applications in data channel	Absent or all relevant values	
Encryption	Absent or present	
Multiple-byte extension	Absent or present	
a)	When reducing the transfer-rate capability to 64 kbit/s from a higher value, the value transfer-capacity = 64 kbit/s must be included.

	The capability set consists of the capability marker (111) [24] followed by all currently valid values, in any order; this may in turn be followed 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, followed 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.
TABLE 2/H.242
Command summary
Attribute	Alternative values
(last value only is valid)	Default assumed	Comments	
Audio (000)	[0, 4-7, 13-19, 24-31]	[18 or 19]		
Transfer
 rate (001)	[0-15, 23, 24, 26, 29]
[17]
[18-22]	[0]	See § 7.2.3 
additional channels only 	
Video and
other (010)	[0-4]
[6, 7]
[16]
[17]
[18, 21]
[19, 21]
[20, 21]
[25, 26]
[27, 28]	[0]
[7]

[21]
[21]
[21]
[26]
[28]	

Cancelled by command in video frame
Expires after fast update completed	
LSD and
MLP (011)	[0-15, 31]
[16-19]	[0]
[16]		
HSD and
H-MLP 	[0, 17-22]
[2-8, 13, 14]	[0]
[14]	Escape table (111)[16]	

	Only one value in each row can be in force at any one instant, up to 17 values on the initial channel (all the above values except (001) [18-22] apply only to the initial channel); however in practice many of the combinations 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 simultaneous 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 multiplexing of audio, video and the various forms of data. Some examples relating to data transmission are given in Appendix V.
a)	Audio cannot penetrate into fixed rate Data (LSD or MLP) bit positions. 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 30 kbit/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 positions 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-multiframe; (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 channel – 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 subsequent 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 discontinued 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 800 bit/s ECS channel defined in Recommendation H.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 channel 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 associated Figure I-1/H.242.
SUCCESSIVE SUB-MULTIFRAMES AT TERMINAL “X” ONLY
TRANSMITTED					RECEIVED						
FAS,
A-bit	BAS
Attr.	Value	Audio
mode	Video
rate	FAS,
A-bit	BAS
Attr.	Value	Audio
mode	Video
rate	Comments	
xx	xx	xx	xx	xx	xx	xx	xx	xx	xx		
F,1	(111)	[24]	0	(off)	 xx	 xx	 xx	xx	xx	A cap-mark	
F,1	(100)	[5]	0	(off)	xx	xx	xx	xx	xx	audio BAS-cap 1)	
F,1	(100)	[4]	0	(off)	xx	xx	xx	xx	xx	audio BAS-cap 2)	
F,1	(101)	[20]	0	(off)	xx	xx	xx	xx	xx	video Capability-QCIF	
F,1	(101)	[24]	0	(off)	xx	xx	xx	xx	xx	MPI 3/29.97	
F,1	(100) 	[17]	0	(off)	xx	xx	xx	xx	xx	Transfer rate capability 2B	
F,1	(111)	[24]	0	(off)	xx	xx	xx	xx	xx	Repeat capability-set	
F,1	(100)	[5]	0	(off)	xx	xx	xx	xx	xx		
	(continue to cycle caps)				(searching for frame alignment)					About one transit?	
F,1	(101)	[24]	0	(off)	xx	xx	xx	xx	xx		
F,1	(100)	[17]	0	(off)	F,1	[111]	[24]	0	(off)	B incoming capability-set	
F,1	(111) 	[24]	0	(off)	F,1	(100)	[5]	0	(off)	. . .	
F,1	(100)	[5]	0	(off)	F,1	(100)	[4]	0	(off)		
F,1	(100) 	[4] 	0	(off)	F,1	(101)	[20]	0	(off)	. . .	
F,1	(101)	[20] 	0	(off)	F,1	(101)	[24]	0	(off)	. . .	
F,1	(101)	[24]	0	(off)	F,1	(100)	[17]	0	(off)	. . .	
F,1	(100)	[17]	0	(off)	F,1	(111)	[24]	0	(off)	capability-set complete	
					(searching for multiframe align.)					up to 320 ms	
F,0	(101)	[24]	0	(off)	F,1	(100)	[17]	0	(off)	C mfa achieved, A = 0	
F,0	(100)	[17]	0	(off)	F,1	(111)	[24]	0	(off)		
					(waiting for incoming A = 0)						
F,0	(100)	[17]	0	(off)	F,1	(111)	[24]	0	(off)		
F,0	(111)	[24]	0	(off)	F,0	(100)	[5]	0	(off)	D incoming A = 0	
F,0	(100)	[5]	0	(off)	F,0	(100)	[4]	0	(off)		
F,0	(100)	[4]	0	(off)	F,0	(101)	[20]	0	(off)	. . .	
F,0	(101)	[20]	0	(off)	F,0	(101)	[24]	0	(off)	. . .	
F,0	(101)	[24]	0	(off)	F,0	(100)	[17]	0	(off)	. . .	
F,0	(100)	[17]	0	(off)	F,0	(111)	[24]	0	(off)		
F,0	(111)	[24]	0	(off)	F,0	(100)	[5]	0	(off)	capability-set complete	
F,0	(000)	[29]	0	(off)	F,0	(100)	[4]	0	(off)	E start mode switch	
F,0	(010)	[1]	7	(off)	F,0	(101)	[20]	0	(off)	(Note)	
F,0	(000)	[29]	7	46.4	F,0	(101)	[24]	0	(off)		
F,0	(010)	[1]	7	46.4	F,0	(100)	[17]	0	(off)		
F,0	(000)	[29]	7	46.4	F,0	(111)	[24]	0	(off)		
F,0	(010)	[1]	7	46.4	F,0	(100)	[5]	0	(off)		
					(waiting for incoming mode changes)						
F,0	(010)	[1]	7	46.4	F,0	(101)	[24]	0	(off)		
F,0	(000)	[29]	7	46.4	F,0	(000)	[29]	0	(off)	F incoming switch	
F,0	(010)	[1]	7	46.4	F,0	(010)	[1]	7	(off)	16 kbit/s audio	
F,0	(000)	[29]	7	46.4	F,0	(000)	[29]	7	46.4	video ON	
F,0	(010)	[1]	7	46.4	F,0	(010)	[1]	7	46.4	repeat valid	
F,0	(000)	[29]	7	46.4	F,0	(000)	[29]	7	46.4	commands	

TRANSMITTED					RECEIVED						
FAS,
A-bit	BAS
Attr.	Value	Audio
mode	Video
rate	FAS,
A-bit	BAS
Attr.	Value	Audio
mode	Video
rate	Comments	
xx	xx	xx	xx	xx	xx	xx	xx	xx	xx		
(now deal with second B-channel, once connection is completed)											
FF,01	(010)	[1]	7	46.4	Fx,0x	(000)	[29]	7	46.4	G	
FF,01	(000)	[29]	7	46.4	Fx,0x	(010)	[1]	7	46.4		
				(searching for frame alignment on channel No. 2)							
FF,01	(010)	[1]	7	46.4	FF,01	(000)	[29]	7	46.4	H alignment recovered	
FF,01	(000)	[29]	7	46.4	FF,01	(010)	[1]	7	46.4		
			(finding multiframe alignment and buffering to synchronize)								
FF,00	(010)	[1]	7	46.4	FF,01	(000)	[29]	7	46.4	I send A = 0 on	
FF,00	(000)	[29]	7	46.4	FF,01	(010)	[1]	7	46.4	channel No. 2	
					(waiting for incoming A2 = 0)						
FF,00	(010)	[1]	7	46.4	FF,00	(000)	[29]	7	46.4	J incoming A2 = 0	
FF,00	(001)	[1]	7	46.4	FF,00	(010)	[1]	7	46.4	start mode switch to	
FF,00	(001)	[1]	7	108.8	FF,00	(000)	[29]	7	46.4	expand video (Note)	
FF,00	(010)	[1]	7	108.8	FF,00	(010)	[1]	7	46.4		
FF,00	(000)	[29]	7	108.8	FF,00	(000)	[29]	7	46.4		
FF,00	(001)	[1]	7	108.8	FF,00	(010)	[1]	7	46.4		
(continue to cycle BAS commands)					(waiting for incoming mode changes)						
FF,00	(010)	[1]	7	108.8	FF,00	(001)	[1]	7	46.4	K incoming mode sw.	
FF,00	(000)	[29]	7	108.8	FF,00	(001)	[1]	7	108.8		
(initialization completed)											
Note – The modes selected for switching are governed by terminal procedures which in general depend on the application; in the present case of videophone service, the procedure is specified in Recommendation H.320.

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 associated Figure II-2/H.242.

SUCCESSIVE SUB-MULTIFRAMES AT TERMINAL “X” ONLY
TRANSMITTED					RECEIVED						
FAS,
A-bit	BAS
Attr.	Value	Audio
mode	Video
rate	FAS,
A-bit	BAS
Attr.	Value	Audio
mode	Video
rate	Comments	
FF,00	(010)	[1]	7	107.6	FF,00	(000)	[29]	7	107.6	Video is ON (Rec. H.261)	
FF,00	(000)	[29]	7	107.6	FF,00	(001)	[1]	7	107.6	Audio is 16 kbit/s	
FF,00	(001)	[1]	7	107.6	FF,00	(011)	[2]	7	107.6	Transfer rate is 2 ´ 64	
FF,00	(011)	[2]	7	107.6	FF,00	(010)	[1]	7	107.6	Data is ON at 1.2 kbit/s	
FF,00	(010)	[1]	7	107.6	FF,00	(000)	[29]	7	107.6		
FF,00	(011)	[0]	7	107.6	FF,00	(001)	[1]	7	107.6	L Data to go off	
FF,00	(010)	[0]	7	108.8	FF,00	(011)	[2]	7	107.6	Video to go off	
FF,00	(001)	[0]	7	(off)	FF,00	(010)	[1]	7	107.6	Transfer rate 64 kbit/s	
FF,00	(000)	[18]	7	off	FF,00	(000)	[29]	7	107.6	Audio A-law, OF	
FF,00	(000)	[18]	OF	off	FF,00	(001)	[1]	7	107.6		
FF,00	(010)	[0]	OF	off	FF,00	(011)	[2]	7	107.6		
FF,00	(000)	[18]	OF	off	FF,00	(010)	[1]	7	107.6		
FF,00	(111)	[24]	OF	off	FF,00	(000)	[29]	7	107.6	M capability mark	
FF,00	(100)	[16]	OF	off	FF,00	(001)	[1]	7	107.6	64 kbit/s-capability only	
FF,00	(100)	[1]	OF	off	FF,00	(011)	[2]	7	107.6	A-law capability only	
FF,00	(111)	[24]	OF	off	FF,00	(010)	[1]	7	107.6	capability mark	
(continue to cycle these caps) 					(awaiting incoming mode change and cap. set)						
FF,00	(100)	[16]	OF	off	FF,00	(000)	[29]	7	107.6		
FF,00	(100)	[1]	OF	off	FF,00	(011)	[0]	7	107.6	N Incoming data to go off	
FF,00	(111)	[24]	OF	off	FF,00	(010)	[0]	7	108.8	Incoming video to go off	
FF,00	(100)	[16]	OF	off	FF,00	(001)	[0]	7	(off)	Incoming channel No. 2 off	
FF,00	(100)	[1]	OF	off	FF,00	(000)	[18]	7	(off)	Incoming audio to be OF	
FF,00	(010)	[0]	OF	off	FF,00	(111)	[24]	OF	off		
FF,00	(001)	[0]	OF	off	FF,00	(100)	[5]	OF	off		
FF,00	(000)	[18]	OF	off	FF,00	(100)	[4]	OF	off		
FF,00	(011)	[0]	OF	off	FF,00	(101)	[20]	OF	off		
FF,00	(010)	[0]	OF	off	FF,00	(101)	[24]	OF	off		
FF,00	(001)	[0]	OF	off	FF,00	(100)	[17]	OF	off		
FF,00	(000)	[18]	OF	off	FF,00	(111)	[24]	OF	off		
(continue to cycle all valid BAS commands)											

	The mode-0 forcing procedure is not complete: subsequent action depends on the terminal procedure, according to the reason for performing the switch to mode 0
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, 56 kbit/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, 56 kbit/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 type 2 (Rec. G.722, 56 kbit/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
{byte 1}		Country code according to Recommendation T.35
{byte 2}		Country code
{bytes 3,4}	Manufacturer code (Company XYZ)
{bytes 5-M}	Type identity
(111) [24]	Capability-mark, repetition of capability set
(100) [4]		Audio type 2 (Rec. G.722, 56 kbit/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
{byte 1}		Country code according to Recommendation T.35
{byte 2}		Country code
{bytes 3,4} 	Manufacturer code (Company XYZ)
{bytes 5-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

	Audio	Video	Transfer
rate	LSD	HSD	MLP	
Capabilities of Terminal X	16 kbit/s	Yes	1B	1.2 kbit/s	–	No	
Capabilities of Terminal Y	Type 2
+16 kbit/s	Yes	2B	1.2 kbit/s	–	Yes	
Mode in X-to-Y direction	16 kbit/s	ON	1B	1.2 kbit/s	–	OFF	
Mode in Y-to-X direction	16 kbit/s	ON	1B	1.2 kbit/s	–	OFF	

IV.2	Example of unsymmetrical transmission mode

	Audio	Video	Transfer
rate	LSD	HSD	MLP	
Capabilities of Terminal X	PCM	Yes	2B	1.2 kbit/s	No	No	
Capabilities of Terminal Y	16 kbit/s	No	2B	56 kbit/s	No	No	
Mode in X-to-Y direction	OFF	OFF	2B	56 kbit/s	–	OFF	
Mode in Y-to-X direction	OFF	ON	2B	1.2 kbit/s	–	OFF	

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