The content on this page was written in about the year 2000 and is obviously quite dated. While it's likely many links are broken, it is retained since it might be of some value to some.
Adapting H.324 For Use With Modems That Cannot Operate In Synchronous Mode
Introduction
This document is for vendors who would like to offer a multimedia terminal based on the ITU-T H.324 Recommendation but using modems that cannot operate in synchronous mode or for interoperating with such a terminal using a V.34 modem that can optionally operate in synchronous mode. A common solution is described that a handful of vendors have already implemented, independent of each other. This is, therefore, not the case of a single vendor imploring other vendors to support its proprietary solution--in this case, the solution is rather obvious. As such, this document simply describes the obvious in order to encourage interoperability between multimedia terminals that allow customers to use the modems they currently own.
Implementation
Here is how it is done. First, only the normal, "duplex data" V.8 call-function octet is used to distinguish this non-compliant terminal from a true H.324 terminal, which uses the 0x21 V.8 call-function octet and H.324 V.8bis codepoints. Thereafter, the terminal basically operates as if it were in V.80 Framed Sub-Mode. The terminal packetizes data and sends it to the modem using V.80 commands. Since the modem is not operating in synchronous mode, the V.80 commands pass through the modem as data and are received by the remote terminal's modem, which is also not operating in synchronous mode, as otherwise unremarkable data. Therefore, the modems do not translate the packets into HDLC-flagged, zero-bit inserted packets and then back again. The remote terminal receives the V.80 commands and interprets them just as if its own modem is in V.80 Framed Sub-Mode.
However, the terminal must only send V.80 commands that are translated back to the same values on the other end. These could be considered "end-to-end" V.80 commands. The remaining, "local" V.80 commands which are intended just for the local modem are not sent. The other end does not expect to see them, so do not send them. The only other thing is that a terminal must not attempt to simulate a synchronous V.34 modem's bit stream by generating HDLC flags or by performing 0-bit insertion.
Note that this imposes a requirement on the DTE/DCE interface that does not exist in H.324. When a terminal is placed in this mode, it always acts as if the modem has a V.80 interface, whether or not it is a V.80 modem. It sends and receives end-to-end V.80 commands that the modem passes through as normal data but does not send or expect to receive local V.80 commands. If the terminal does not otherwise support V.80 modems, the vendor of the terminal may not want to go to the trouble of supporting the V.80 subset that this mode requires.
Whether V.42 error correction or V.42bis compression should be enabled is for further study. My guess is that they should be disabled because, where appropriate, error correction is done by the terminal's Adaptation Layers and compression is done by the codecs, e.g., H.263 and G.723.1.
Mode Selection
A side issue is how one selects in which mode a terminal is placed. For an out-going call, it must be selected by the user. For an in-coming call, it could be selected automatically during call setup or, more typically, by the user beforehand with, for example, a check box in the GUI.
Name
One last thing. This needs a name. "Async H.324 terminal" is self-contradictory, "otherwise-H.324 terminal using a modem that has V.42/V.42bis enabled" is too long, ditto for "otherwise-H.324 terminal with redundant retransmission layers." To minimize confusion, it needs a name that does not contain "H.324." Some vendors call a synchronous modem a "video-ready" modem. Calling the other kind of modem "non-video-ready" sounds like it cannot be used for video, which is clearly not the case. I propose the tongue-in-cheek, "Non-Compliant, Old Modem" mode, or NCOM for short. For example, in a list of features a vendor could say,
- NCOM support for non-H.324-compliant use with older modems
"Older V.34 modems" is too restrictive because it is possible to use, for example, V.32bis modems.
Hey, wanna hear a modem (20k wav file)?