Now that the V.34 compatibility battle is finally being won, a new problem has surfaced. How do two fax terminals that were attempting to use V.34 mutually decide to abandon it, fall back to V.17 and complete sending their pages? When the "Super G3" V.34 fax modulation was initially released as an integral part of the ITU T.30 protocol, it was implemented on a nearly proprietary basis. Two same make same model machines could communicate using V.34 but, otherwise, their call fell directly back to V.17 which was familiar territory. In the 2003 - 2004 time frame, this began to change.

True V .34 interoperability went from a nice idea to a working reality and numerous V.34 devices from different manufacturers began to exchange pages at the  high data rates that V.34 facilitates. However, PSTN and VoIP connections can still pose transmission problems that cause a fallback to the older but much more reliable V.17 and earlier modulations. Where the first of the V.34 machines went directly to V.17 as soon as a V.8 message revealed the presence of an 'other' fax machine, these newer devices must be able to go back to V.17 from well into or even through the V.8 negotiations. But why fall back at all?

V.34 uses just about every trick in the book, and a few that bear a suspicious resemblance to magic, in order to squeeze more data bits through a PSTN line than its predecessor modulations. It does this by using a massive array of modulation symbols and selecting them via a process that plays distortion off against signal power level. Shell mapping, pre-emphasis, power control and constellation shaping techniques are employed to select just the right phase angle and amplitude for each symbol to get as much data transmitted as quickly as possible. Full duplex operation speeds up the slow control channel communications and the use of all these modulation tricks can dramatically speed up the primary channel that carries the page data. Add to this V.34's ability to operate all the way from 33,600 bps down to 2,400 bps and falling back to V.17 starts to sound superfluous. There are, however, three aspects of a call's progress that can make it necessary.

The most obvious balk to this amazing new high speed process is the attempt of a V.34 machine to call or answer a non-V.34 device. To complete the call, the data rate has to fall back to a modulation that the other machine can handle. The key to this compatibility determination is the ANSam signal.

A V.17 answering device will respond to a call with a CED tone that is a 2100Hz sine wave. A V.34 answering device responds with an ANSam tone that is a 2100Hz sine wave with a half-phase reversal and a 15Hz tone amplitude modulated on top of it. The V.34 originator sees the half-phase reversal and 15Hz modulation and begins V.8 negotiations by sending a CM signal. The V.17 originator sees only the 2100Hz tone and waits for a DIS V.21 signal. When the answerer does not get its expected CM, it eventually times out and begins to send a V.21 DIS to establish negotiations for a V.17 call. By the same token, a V.17 answerer responds to a V.34 originator with a CED signal that causes that originator to wait for the following V.21 DIS message. This stopping of V.8 negotiations before they begin is a fairly straightforward process that is usually successful. Things get more interesting when the drop back has to happen after V.8 is underway.

The key to completion of V.8 negotiations and the start of V.34 line probing is the successful exchange of the CM (originator) and JM (answerer) messages acknowledged by the originator's transmission of CJ. But, sometimes, that just doesn't happen. If either the answerer doesn't see the CM or the originator doesn't see the JM, V.8 can't complete its task. This situation will commonly result in the answerer timing out and sending its V.21 DIS to prompt V.17 operation with the originator. This requires that both terminals be prepared to notice that the fall back is happening and respond appropriately.

An answerer that just keeps on sending JM may cause an originator that just doesn't get it to go back on hook. An originator that sends its CM over the V.21 DIS coming from the other end may never recognize that it is time to fall back. This is further complicated by two complementary features included in V.8 by the ITU.

Bit number 6 in the DIS message has been changed from a reserved bit that had no meaning to one that can be set to indicate V.8 negotiation capability. Thus, an answerer that has given up on V.8 negotiations and sent its V.21 DIS can still hold out the possibility of V.34 by saying "I really do know about V.8... I do!" If the originator is equipped to notice this, it can respond with the CI signal which is essentially a CM that urges the answerer back toward a V.8 signal exchange. The presence of this capability means that FoIP gateways that use T.38 but don't support version 3 of that protocol must suppress the setting of bit 6 in any DIS that they convey to an originator lest it start to respond with CI messages instead of receiving a V.21 DIS and responding with a V.21 DCS. This gets us down to the last unfortunate instance of a necessary fall back.

On occasion, an answerer and originator will exchange their V.8 messages right down to the return of CJ by the originator that should prompt the transition to V.34 and the simultaneous exchange of INFO0 messages but doesn't. The answerer doesn't see the CJ and never sends INFO0a. Most devices will simply drop the call at this point. However, some will still pursue recovery via a drop back. The answerer will start sending its DIS (sometimes with bit 6 set) and the originator may start sending CI. On even more rare occasions they may actually pick up and complete the transition to V.34 or the originator will take the DIS hint to return a V.21 DCS but more commonly there are a few miscued messages followed by a dropped call.

From a design standpoint, the drop back process needs to be approached earlier rather than later in the V.8 message exchange. If there is a problem with reading either CM or JM messages, it is not likely to get better further into the call. The best plan is simply to stop CM, wait out the timeout of the answerer to its transmission of a V.21 DIS then ignore bit 6 and make this a V.17 call. The use of the more simplistic V.17 modulation can sometimes carry a higher data rate than an attempt to force V.34 to work under really poor connection conditions. From the answerer end, leave bit 6 set at '0', ignore CI and continue to send the V.21 DIS until a V.21 DCS answers it. This simple change of operating strategy will drastically reduce the number of calls lost during a fumbled attempt to complete V.8 exchanges.

Or do you disagree? Please post a response, I'd like to read your point of view.