 
(1)  Short note on Class 2 and Class 2.0

A system that results in the industry standard definition of class
2 being incompatible with the EIA definition of class 2 is clearly
unsatisfactory.  Given the fact that the EIA is supposed to be an
industry-wide body, it borders on farce, though the consequences can
be more serious.  Readers should be warned that if they order an
official version of the TR-29.2 TIA/EIA-592 Service Class 2 standard,
they will almost certainly get the officially approved class 2.0
document.  If you telephone the EIA and ask for any documents, you
are usually put in touch with their major distributor, who are Global
Engineering Documents.  They only have one version of SP-2388 listed,
and have it cross-referenced to TIA/EIA-592.  It costs $85. I'm still
not entirely sure what they are selling, but as the official
distributors, I assume that if they only have one version then it
must be the approved one.  The draft version of class 2 was always
difficult to obtain.  One modem manufacturer (Supra) stated quite
baldly in 1992 that

"Most of those companies which have developed Class 2 fax software
either sit on the TR-29.2 committee or know someone who does."

Supra advised prospective software developers to wait for the approved
version from the TIA/EIA or Global Engineering.  Of course, it is
just as difficult now as it was then to get hold of that version of
the standard as it never was approved.

(2)  Short note on setting a null Local ID string

Setting a null ID with AT+FLID="" is not the same as sending an empty
ID string consisting of 20 spaces, which can be accomplished using
the command AT+FLID=" ".  In the latter case, a single space is padded
out to 20 spaces.

(3)  Short note on AT+FDCC defaults

The presumption of suitable defaults being in force was the reason
why no +FDCC parameter setup was included as a preliminary fifth step
to the 4-step fax sending process we presented earlier in this
chapter.  However, I have seen reports of modems with weird defaults
like fine resolution at 2400 bps.  I suspect such reports are a
result of users not testing the parameters immediately after powering
up the modem, but anything is possible in the modem universe.

To be really safe, we could always issue a universal command like :

AT+FDCC=0,1,0,0,0,0,0,0

which works on all modems.  The effect of this would be to tell the
fax modem you intend to send normal resolution fax images at 4800
bps, which contained the standard 1728 dots across a 215 mm A4 page,
and which consists of standard one-dimensional T.4 fax data.  Error
checking is not to be used, and neither is binary file transfer,
while a scan line time of 0 ms is preferred but is open to
negotiation.  Possibly, setting LN to 2 for unlimited length would be
even safer. Though it is technically a non-mandatory value, and it is
theoretically possible for a fax modem to be made that can't send
unlimited length faxes, nobody has yet done it (deliberately at
least).

(4)  Short note on the difference between AT+FDCC and AT+FDIS

Here's a simple example. Issuing the command AT+FDCC=1 affects
only the first parameter, and enables fine
resolution.  In the absence of instructions to the contrary, any fax
sent after issuing this command, will (assuming the receiver has the
capability) be sent using 7.7 lines/mm. However, if one fax was
prefixed by the AT+FDIS=0 command, then for one session only, normal
resolution of 3.85 lines/mm would be used. Following that single
session, +FDIS would once again be reset to match the master list
maintained by +FDCC.

(5)  Short notes on partial implementations and bugs

i. Our detailed figure showing the responses that may come in during
phase A included the +FNSF: report of the contents of any NSF frame
detected. I haven't seen any Class 2 modem that implements this
report.  All implementations are partial.

ii. As regards bugs, lest anyone think I'm picking on Exar, here's a
somewhat more innocuous bug from the Sierra-based modem we quoted
from in the notes to Chapter 8:

 AT+FDCC=?

 (0,1),(0-3),(0,1),(0-2),(0,2),(0),(0),(0-7)

 OK
 AT+FDCC?

 +FDCS: 0,0,0,0,0,0,0,0

 OK

The modem accepts the test parameter form of the +FDCC command but is
not merely unable to act on the read parameter form; it sends out an
+FDCS: report instead. This is a bug, as the +FDCS: report is
something which ought not to appear at this point.  In fact, it is a
Phase B response code, and appears in the detailed table showing the
progress of a transmission session.

iii. The class 2 standard allows for optional T.30 features such as
the 2400 bps negotiating speed, but states this is to be handled
transparently by the modem. I don't know of any modems that implement
this particular option.

iv.  NSF frames may not always be reported, but bear in mind where
they are that there may be more than one NSF frame.  NSF frames should
always be ignored by class 2 applications software as they are by
definition non-standard.  A number of fax features (such as superfine
resolution) which are now part of the T.30 negotiating procedure were
originally implemented by means of NSF frames and corresponding NSS
responses.  Class 2 does not have any facilities for composing or
sending NSS responses.

(6)  Short note on report the remote ID

The ID characters are sent from the modem in the correct order (which
is opposite to the order in which they were received).  In other
words, ID reporting is another instance of the modem implementing
T.30.

(7)  Short note on the OK at the end of phase A

It's unclear whether the OK is triggered by the fact that a frame
contains a DIS sequence, or if the frame is identified as being the
last in the sequence (by having bit 5 in the control octet set). The
latter would be more in line with the T.30 protocol. However, the
philosophy behind the design of the TIA/EIA class 2 fax modem
specification is that the insides of the T.30 protocol should be
completely hidden from the controlling software.  Therefore the
specification is silent as to what the strategy should be if (for
example) some of the initial frames arrive corrupted.  Such issues
are for the designers of the fax modem to decide.  This isn't in any
way unusual, as designers of fax machines have to make similar
decisions all the time.

(8)  Short note on the less frequently implemented parameters

The strategy to be adopted where there is a mismatch between FDIS:DF
and DIS bits 16, 26 and 31 is a little unclear.  Unlike T.30, the
class 2 specification does not state that T.6 modified modified read
coding is dependent on error checking being available, which must be
considered to be a documentation error. Another error must surely be
that whereas in T.30 uncompressed mode is selectable independently
and is applicable to both T.4 modified read coding and T.6 modified
modified read coding, the authors of the class 2 specification seem
to regard it as being a coding method in its own right.  This seems
to be a conceptual error.  The impact of these errors is minimised by
that fact that no stand-alone class 2 modems supporting either error
correction mode or 2-D MMR T.6 coding have ever been marketed.

There is one PC fax board (the TyIn 2000) that claims to offer most
of the unusual class 2 features, including ECM, MMR and BFT.
Unfortunately it is not only restricted to PC based hardware (like
all PC boards) but it also needs a bootstrap program to load its
firmware from a disk file.  This is currently available only for DOS.
Another problem with using the TyIn board is that the unless you want
to program it blind, you'll need to buy the Developer's Kit for
around $500 from the manufacturer.  It is probably for this reason
that the TyIn is neither widely used nor widely available.  The
manufacturers wouldn't give me any technical details, and the
distributors to whom they referred me not only weren't in a position
to answer my questions, but understandably didn't think that giving
free support to authors was something they were obliged to do.
Consequently, I haven't been able to verify any details concerning
either the general operation of the TyIn or any particular support it
has for uncompressed mode.

If you ever come across a board supporting all the possible FDIS:DF
options, you should be reasonably safe in assuming that uncompressed
mode implies the use of 2-D modified Read coding.  However, the only
thing that can be stated with absolute certainty is that if either
the DIS frame or FDIS specifies 1-D Huffman coding, then that is what
shall be used.

There is a fairly direct relationship between the setting of FDIS:EC
and DIS bits 27- 28.  The TyIn board mentioned earlier as being the
only available class 2 implementation of error checking mode defaults
to the FDIS:EC value of 2, which means that it will send 256 byte
frames.  Note that an error-correcting receiver has to accept
whatever frame size the transmitter decides on.

The relationship between FDIS:BF and DIS bits 51-53 is less than
precise.  However, it is worth noting that the draft EIA SP-2388
class 2 specification used for most modems was issued in 1990, while
the ITU T.434 Binary File Transfer recommendation came out in 1992,
and the T.30 recommendation extending the session protocol to cover
BFT was a year later than that.  So it is hardly surprising that
there is some imprecision in the way that BFT capability is
specified.  The point is somewhat academic however, since T.434 has
not been implemented by any class 2 fax modem vendors.

Even the TyIn PC board we have been mentioning as the fullest
implementation of the draft class 2 specification doesn't properly
implement T.434 BFT.  It does allow the FDIS:BF bit to be set, but
used this to implement DTM (Document Transfer Mode) instead of BFT.
Once again, I have no information on the details of the way this
works.  Bits 51 and 54 in the DIS/DCS frames ought be set for DTM (as
opposed to bits 51 and 54 for BFT proper), but since the only TyIn
technical support document I have seen mistakenly refers to DTM as "a
subset of BFT", it would not be wise to take this for granted.

(9)  Short note on AT+FMINSP

There is a command which can be used to force a class 2 fax modem
not to attempt to negotiate below a certain speed.  This command is
AT+FMINSP, and takes a single numeric parameter taken from the
possible values for the BR parameter as shown by AT+FDIS=?.  For
example, the command AT+FMINSP=3 instructs the modem not to attempt
to negotiate below 9600 bps.  The class 2 specification states that
this is "useful in limiting the cost of a transmission" and says that
if the minimum speed cannot be negotiated then the modem should
politely disconnect ; it also states that the maximum value for
+FMINSP is 3, indicating that it can't be used to force a connection
at speeds above 14400 bps.  The purpose of this restriction isn't
clear.  It is not impossible that it is a mistake.

The AT+FMINSP command shares with the BR parameter an inability to
differentiate between V.17 and V.29 modulations schemes at 9600 bps.
It is another of those class 2 commands whose implementation is by no
means universal.  This doesn't matter too much as any software that
needs to implement a minimum connection speed could just as easily
inspect the final +FDCS: report, and if the speed negotiated is too
low, the session can be aborted by jumping straight to phase E (which
we discuss later in this chapter).  This method can also be used to
disconnect if any other results of the negotiation are unsuitable,
such as the VR (resolution) or DF (fax encoding method) parameters.

Software authors should also note that there are differences in
behaviour between the various makes of class 2 fax modems regarding
the reporting of the contents of the DCS frame.  We have already seen
in the extended class 2 fax transmission table earlier in the chapter
that this is accomplished by means of the +FDCS: report, which
contains a list of class 2 parameters.  We have also described the
various +FDCS:  reports, including the AT+FDCS?  command used to find
out the content of the DCS frame used to negotiate the current
session.  However, the exact circumstances under which the
spontaneous +FDCS: report is generated are far from clear.

The ambiguity stems from the class 2 specification itself.  It states
in the main body of the text that +FDCS: reports can be spontaneously
generated during the execution of +FDT commands whenever a new DCS
frame is generated.  Most existing class 2 modems follow this advice,
and generate FDCS: reports for each DCS frame.  A series of
unsuccessful training check frames will therefore generate a series
of FDCS: reports, with the final one (preceding the CONNECT message)
containing the parameters that eventually proved successful.

However, the sample session A3.9 included in the class 2 specification
doesn't conform to the specification in the text, as it shows equally
clearly that the +FDCS:  report is only generated when a training
sequence results in the receipt of a successful CFR frame.  Whether
we have one +FDCS: report per DCS frame or one per CFR frame received
ultimately makes little difference to a successful fax session, but
there is no doubt for diagnosing what goes wrong on bad sessions, the
more reporting the better.  My view is that it is fortunate that most
modems follow the text of the class 2 specification rather than the
samples in the appendix

(10)  Short note on fill bits and scan line padding

Doubts have been cast on the capability of some class 2 modems to
pad scan line times out to the correct length, though I have not
personally had any experience of this problem. Class 2 fax software
that does not trust the modem to do this properly can do its own
padding if this is preferred. Software packages that cater for class
1 as well as class 2 modems will already have this capability built
in, though it may be difficult to activate it. Some class 2 fax
packages make a point of adding their own fill bit to each line to
ensure minimum scan line times are adhered to.

(11)  Short note on the XON at the start of phase C

It is not clear what the modem is supposed to be doing in between
the time the CONNECT message is generated and the XON is returned, or
why it was thought that both the CONNECT and the XON are required. 
The XON appears to be a relic from the old Sierra Sendfax command
set, which was apparently based on one of the early TR-29.2 proposals
for class 2 fax.  Later evolutionary developments first tried
replacing the XON with an ASCII DC2 (decimal 18, hexadecimal 12) and
then dropped it altogether.  In the class 2.0 specification the
CONNECT message alone is used both to indicate a successful phase B
negotiation and also readiness to accept phase C data. We mentioned
earlier that one of the post-1990 draft of class 2 reportedly got
around the problems involved in using the XON character by replacing
it with a DC2 character instead (18 decimal, 12 hexadecimal). 
However, it might be worth checking for a DC2 instead of an XON if
there are problems at this point of the session, as some class 2
modems might have implemented this variation in their firmware.

(12)  Short note on AT+FBOR and AT+FBUG

It is worth mentioning a somewhat odd decision of the TR-29.2
committee to add two extra settings to the +FBOR command to control
the optional display of HDLC frames.  This is something which class 2
modems can optionally display in phases B and D, along with the
reporting such as +FDIS: and +FDCS: which we have already seen. The
HDLC reports are controlled by the +FBUG parameter, with the default
of AT+FBUG=0 disabling the reports and AT+FBUG=1 enabling them.

If +FBUG=1, all transmitted HDLC frames are reports with the prefix
+FHT: while all received HDLC frames are reported with the prefix
+FHR:.  In both cases, the frame contents are reported in hexadecimal
digits, ending with a new line sequence <cr><lf>.

Both AT+FBOR=0 and AT+FBOR=1 would result in +FBUG reports being in
direct bit order (which means that the bytes reported are actually
reversed from the octet definitions given in the T.30
recommendation).

Two extra +FBOR parameters force +FBUG reports to be in reversed bit
order (which means that the bytes reported correspond to the octets
which are defined in T.30).  AT+FBOR=2 keeps direct bit order for
phase C data while selecting reversed bit order for the HDLC reports,
with AT+FBOR=3 using reversed bit order for both.

The reason why I regard this decision as odd is because the whole
philosophy of class 2 is to hide the innards of T.30 from the modem.
While an AT+FBUG facility is certainly useful for technically minded
users (and possibly also for certain bespoke software applications)
the sort of people who want to debug at the frame level are likely to
be able to cope with either of the possible defaults and are hardly
likely to be concerned about the necessity to invert bits as reported
by the modem.  On the other hand, the extra complexity added to the
+FBOR command adds another layer to what is already an extremely
vexing problem.

It is worth noting in this connection that when the class 2
specification describes the reporting of the contents of NSF frames
in hexadecimal notation, it states "for each frame octet the LSB is
the first bit sent or received".  In other words, the only option
given is for NSF frames is reversed bit order.  Precisely why this
sensible option couldn't also have been made mandatory for +FBUG
reports escapes me.  Neither the +FBOR nor the +FBUG commands are
universally implemented, and in the case of +FBOR, not all the
options are guaranteed to be available even where the command itself
is supported.

(13)  Short note on buffer sizes, response latency, and AT+FPHCTO

Note that if the modem has a 16K buffer, there may be a long delay
between the sending of the <dle><etx> sequence and the return of the
OK response, depending on whether the firmware in the modem
implements this memory in the form of a receive buffer (which stores
data as it is received from the computer) or a transmit buffer (which
hold data which is queued for transmission to the remote fax.  These
types of buffer aren't exclusive, and there is no reason why a modem
can't implement both receive and transmit buffers.  However, the
class 2 standard doesn't mandate exactly where the buffering should
occur, and none of the modem manuals specify how this is
implemented.  When data is automatically buffered as it is received
from the computer, then the <dle><etx> sequence goes into the buffer
with everything else and the modem won't respond with the OK until
the sequence is taken out.  Where a fax is being sent at 9600 bps,
emptying a full 16K buffer would take 17 seconds. The reason for the
RTC not being transmitted as soon as the data is all sent and the
<dle><etx> is detected is not clear.  Portions of the class 2
specification (notably those dealing with optional block mode) are
clear that the end of a data block is not necessarily the end of the
page, and that a second portion can be sent on the same page by means
of a second +FDT command.  However, block mode doesn't use <dle><etx>
characters to terminate data, so the situation is not quite
analogous.

Presumably the TR-29.2 committee assumed that since the T.30 protocol
specifies that a transmitting fax proceed with phase D directly
following the termination of phase C, the RTC should not be sent
immediately the page has ended since until the fax modem receives the
AT+FET page punctuation command it can't know what to do in phase D.

The situation is further muddled by a special +FPHCTO (phase C
timeout) command which controls how long the modem is prepared to
wait after the end of phase C data before a subsequent phase D
command is received.  It holds a numeric value in the range 0- 255
indicating how many 100 millisecond units the modem will wait before
giving up and unilaterally continuing as if an AT+FET=2 command to
end the session had been received.  The default value is 30, which
gives a default delay of 3 seconds.  The class 2 specification
appears to think that +FPHCTO=30 is the T.30 default, but this isn't
in fact true.

There are three T4/T.30 timeouts which need to be considered here. The
only one that applies to a delay between the end of the T.4 data and
the sending of a RTC is the 5 second maximum length of a scan line
which is specified in T.4/3.2.  It is this delay that +FPHCTO should
be referring to, as between the <dle><etx> sequence that marks the
end of phase C data and the AT+FET command that releases the RTC
sequence, the fax modem is transmitting 0 bits to pad out the final
line.  However, the precise amount of time that is available will of
course vary with the length of the last line, so this is possibly not
the best timeout to choose, especially as violating this timeout is
punishable by immediate disconnection with no error recovery
mechanism.

There are two other relevant timers specified in T.30, neither of
which are phase C timeouts .  The first is the 6  1 second T2
timeout (as specified in T.30/5.4.3.1) which would have applied if
the RTC had been sent immediately the <dle><etx> had been detected,
as this is the delay that a receiver can tolerate between the end of
phase C and the phase D post-message command arriving.  The other is
presumably where the +FPHCTO=30 default came from, as it is a 3
second timeout, but it applies to the maximum length of time that can
elapse between the transmission of a command and the reception of a
response.  It therefore can't be used to set a transmitter timeout
anyway.

The +FPHCTO command is, in my opinion, best ignored.  In the first
place, it isn't supported by all class 2 modems, with many models
returning an ERROR response to an AT+FPHCTO? query.  More
importantly, the whole concept of a timeout that is unilaterally
selectable is alien to the ITU fax recommendation, and the exact
relationship between the recommendations and +FPHCTO seems extremely
unclear.  The only possible use of this command that I can think of
is allowing programmers in a hurry to end a fax with as little bother
as possible by allowing a deliberate timeout expiry on a final page. 
Even this isn't to be recommended as it precludes not only reception
of a confirmation from the receiver for inclusion in a fax log, but
also any possibility of resending the page if it was incorrectly
received.

(14)  Short note on the RTC sequence

No doubt you won't be surprised to hear that many class 2 fax modems
have a bug in the way they send an RTC.  When two-dimensional coding
is being used, every EOL is followed by a tag bit which, in the case
of the six EOLs comprising the RTC sequence, should be set to 1. Most
class 2 modems ignore the difference between the one- dimensional
RTCs and two-dimensional RTCs, and send the same bit sequence
consisting of six successive 000000000001 bit patterns for both.

Very often this makes no difference.  The fact that the only valid
occurrence of eight successive 0 bits in a T.4 file is in the EOL
code means that many fax machines, and most fax modem software, takes
the short cut of treating any 00000000 sequence as the start of an
EOL sequence.  All successive 0 bits following this are treated as
fill bits and are ignored until the next 1 bit arrives.  When two-
dimensional coding is used, the removal of the next bit as being a tag
bit simply reduces padding for the following EOL, and the crucial
sequence of eight successive 0 bits remains intact.  While it is true
that the tag bits of these EOLs are 0 rather than 1, there can't
really be any doubt that the codes are EOLs as they simply can't be
construed in any other way.

However, other fax machines are fussier and insist that all EOLs
contain the statutory minimum of eleven successive 0 bits.  The
result of this is that an RTC consisting of 6 successive
one-dimensional 12 bit EOL codes isn't going to be recognised.  When
the tag bit following the first EOL is removed, the second EOL is
reduced to an 11 bit 00000000001 code, and far from being recognised
as being an EOL, is flagged as an error.

This bug is an example is one of a general class of problems which can
affect any fax implementation, and isn't restricted simply to class 2
modems.  The problems all involve minor deviations from the letter of
the ITU specifications, the effects of which aren't apparent until
you try and connect up to a machine that simply can't tolerate the
difference.

Typically, the symptoms of this type of bug are highly irritating.  A
fax which transmits perfectly to one machine fails to get beyond the
end of the first page when sending to a second machine.  Your initial
response is to resend the document, but the result is exactly the
same no matter how many times you try.  Then you print the document
out and send it with a normal fax machine, only to discover that it
gets sent out perfectly well.  The first call for help usually goes
out to the software supplier and the second to the modem distributor.
It isn't unusual to find that nobody is able or willing to track down
the exact cause of the problem, with the result that it gets marked
down as an "incompatibility".

Redefining a bug as an incompatibility is partly a way of saying that
it's something which it is either uneconomical to investigate or else
impossible to fix.  More importantly, it is also a recognition of the
sad fact that the nobody wants to take either the blame for causing
it or the responsibility for fixing it.  The specific problem we have
encountered here could be seen as an inability of certain class 2
modems to send properly formatted RTC sequences when sending
two-dimensionally coded faxes when FDIS:DF=1. Alternatively, it could
be seen as an inability of certain fax machines to conform to the
tolerance levels common throughout most of the industry.  Luckily the
way around the class 2 two-dimensional RTC bug is quite simple ; if
your fax software and modem fall over at the end of phase C when
sending the first page of a two-dimensionally coded fax, then make
sure that the next attempt to transmit the fax uses the command
AT+FDIS=,,,,0 (to set DF=0) and sends a one-dimensional version of
the fax instead.

(15)  Short note on procedure interrupts

The PRI (procedure interrupt) post-message commands are not
something which one naturally associates with fax modems.  For most
users, the whole point of a fax modem is to automate and streamline
the procedure of faxing documents, and a great deal of effort is
often put into making the operation as seamless as possible.  The
existence of an option to break into that carefully crafted process
and start negotiating manually isn't something that would strike most
people interested in the office automation as being a terribly useful
feature. The relevant +FET parameters are as follows :


Ŀ
        T.30 frame Meaning                                    
Ĵ
AT+FET=0 MPS       another page follows                       
AT+FET=1 EOM       another document follows                   
AT+FET=2 EOP       no more pages                              
AT+FET=4 PRI-MPS   procedure interrupt - another page follows 
AT+FET=5 PRI-EOM   procedure interrupt - return to phase B    
AT+FET=6 PRI-EOP   procedure interrupt - no more pages        



(16)  Short note on redefining Class 2 session parameters

It is important to note the use of AT+FDIS to redefine the session
parameters before the start of the high resolution page. We have
already pointed out that redefinition of +FDIS when off-hook is
something that doesn't work on all fax modems.  To anticipate a
little, it is also the case that some low-end fax machines and class
2 fax modems don't support the EOM frame properly and crash when they
try and return to the start of phase B.  So for maximum portability,
don't use AT+FET=1 or AT+FDIS when on-line.  If one page of a fax
needs to be sent in high resolution, then send the whole lot as high
resolution

(17)  Short note on AT+FK

I've found at least one modem where AT+FK didn't seem to hang up the
telephone properly, and issuing an extra ATH under these
circumstances does no harm, and is probably a sensible precaution.

(18)  Short note on AT+FCR

Strictly speaking, the test parameter form of the command AT+FCR=?
should be used before attempting to set +FCR=1, as it is
theoretically possible for a class 2 modem not to have receive
capability.  However, while it is true that the early days of fax
modems, a number of send-only modems were based on the chipsets that
were only able to transmit faxes (the Sierra Sendfax command set was
transmit-only), it is likely that it now would cost more to make a
receive-only class 2 fax modem than it costs to make a model capable
of bidirectional faxing.  There are no send-only class 2 fax modems
that I know of, and omitting this test is quite safe.  In fact,
AT+FCR=?  generates an error on some modems, though AT+FCR=1 is
universally implemented.

(19)  Short note on +FNSS: reports

There is a slight oddity here, in that T.30 states quite clearly
that NSS frames are supposed to be send out only as responses to NSF
frames.  A class 2 modem has no facilities for sending out any NSF
frames, so no NSS should ever arrive.  Precisely why a class 2 modem
needs a facility for reporting frames that ought never to arrive is
something which is not made clear ; the specification simply states
that non- standard frames are outside its scope.

(20)  Short note on forcing a minimum receive speed

Note that inspecting the +FDCS report is the only way to implement an
+FMINSP function when receiving faxes, as even where the +FMINSP
command is supported by a fax modem, it only works when sending.

(21)  Short note on AT+FDR and the passive receiver

In the case of AT+FDR at the end of phase B the command causes the
modem to transmit a CFR frame. It is the transmitter that decides
when to begin sending. There is no command available that lets a fax
receiver tell a transmitter to begin sending. All fax modems must
conform to the T.30 protocol, and this restricts a receiver to a
completely passive role. It can respond, but it cannot initiate.
Under these circumstances, the R in +FDR is probably best understood
as standing for "respond" rather than "receive".

(22)  Short note on the +FDCS: report

Unsurprisingly, the class 2 specification is not clear about the
generation of +FDCS: reports in response to the AT+FDT command.  The
text states that +FDCS:  reports can be spontaneously generated
during the execution of +FDR commands whenever a new DCS frame is
received.

Although the +FDR command has not necessarily been issued, most class
2 fax modems sensibly report the contents of all DCS frames received
during phase B before each training check frame.  The sample sessions
in the documentation show that an ATA and an +FCON is always followed
by +FDCS: report at this stage.  In fact, a misprint in the draft
SP-2388 specification stating that the +FDCS: report contains the
contents of the DIS frame sent out (rather than the DCS frame
received) was been slavishly duplicated in many versions of the class
2 documentation, notably those based on the Rockwell version. Luckily
the misprint appears not to made it as far as the firmware, as all
class 2 modems correctly display the contents of the DCS frame at
this point.

However, most modems also duplicate the last +FDCS: after all +FCFR
reports.  This behaviour is based on a misinterpretation of the
specification, which states that +FDCS: (and also the +FTSI: report)
should be generated if a new DCS frame was received after the +FDR
command.

This cannot happen for the +FDR command preceding the first page of
a session, as a CFR cannot be followed by a negotiating frame.  The
provision for an AT+FDR command to be followed by a +FDCS report is
actually designed only for those pages which end with an EOM frame,
indicating that the session should begin again with phase B.  In this
circumstance, the AT+FDR command to continue the session after the EOM
will proceed to the start of phase B, and will receive a new DCS
frame.  It is only this sort of DCS which a fax modem is supposed to
display after the +FDR.   The generation of a duplicate FDCS: report
by most class 2 fax modems after the +FCFR report for the first page
of a session is neither necessary nor in accordance with the
specification.

(23)  Short note on the +FPTS: report, quality checking, and AT+FCQ

The class 2 standard describes this report as having the form :

+FPTS: <ppr>,<lc>[,<blc>,<cblc>][,<lbc>]

with optional parameters enclosed in [square] brackets.  The placing
of the brackets indicates that if a bad line count is given, a
consecutive bad line count must also appear, but the lost byte count
is independent.  My own reading of this is that a lost byte count can
appear even if no bad line counts are generated.  If the fifth
parameter depended on the previous four being present, the definition
would have read :  +FPTS: <ppr>,<lc>[,<blc>,<cblc>[,<lbc>]]

Consequently, software should count the parameters to be safe.  There
is no problem of identification if only two parameters are given, or
if all five appear.  If exactly three appear, then the third is a
lost byte count, while if four appear, they must be the bad line and
consecutive bad line counts.

Readers of chapter 5 on the TIFF file format will no doubt have
realised that the bad line count and consecutive bad line count are
identical to the TIFF class F definitions for tag 326, BadFaxLines,
and for tag 328, ConsecutiveBadFaxLines.  This isn't a coincidence as
TIFF Class F was defined at about the same time as the TR-29.2 class
2 standard was being developed and the two efforts proceeded in
parallel.  The line count figure is also important for generating
TIFF files from received fax data.  There are three additional
commands that affect the way the +FPTS: report is generated.  They
are +FCQ, +FBADMUL, and +FBADLIN.  They are optional class 2
features, and are so infrequently implemented in class 2 modems that
we won't go into much detail concerning them.  All three commands
control the degree of quality checking that the modem performs for
received faxes.

The +FCQ parameter can take one of three possible values.  If +FCQ=0
then the modem does no quality checking at all, and always returns a
PPR value of +FPTS:1 at the end of each page of phase C data.  If
+FCQ=1 then the modem checks the quality of one- dimensional data,
and if +FCQ=2 then the modem checks the quality of two-dimensional
data also.  The test parameter AT+FCQ=? can be used to find out what
capabilities the modem actually has.  A response of 0 is the most
common answer, indicating that no quality checking at all is done.

For modems that can handle quality checking, +FBADMUL holds an integer
value between 0 and 255 which reflects the proportion of bad lines
that are allowed on a page.  A value of 20 (the default) means that
if more than 1 line in 20 is bad, then the page as a whole is
regarded as unacceptable.  The independent +FBADLIN parameter holds
the maximum number of consecutive bad lines that are permissible in
normal resolution (the number is automatically doubled for a fine
resolution fax).  If this number is exceeded then the page is
regarded as unacceptable.

The exact action to be taken by the modem if +FCQ is non-zero and the
settings of +FBADMUL and +FBADLIN cause an error to be generated is
not specified in the class 2 documentation.  The sensible option
would be to set the <ppr> value in the +FPTS:  report to the value 2.
The acceptable values for <ppr> are identical to those we gave
earlier in relation to single-parameter +FPTS: report generated when
a fax is transmitted, and the commonly acceptable values are as
follows:

Ŀ
 Report T.30 frame Meaning                         
Ĵ
+FPTS:1   MCF      Page received OK                
+FPTS:2   RTN      Page bad : renegotiate/retrain  
+FPTS:3   RTP      Page good : renegotiate/retrain 
+FPTS:4   PIN      Page bad : interrupt requested  
+FPTS:5   PIP      Page good : interrupt requested 


Even when +FCQ is set to 0, an application can always do its own copy
quality checking on received data.  If the quality is regarded as
unacceptable or borderline, then a modified value can be written back
to +FPTS which will then cause the fax modem to release a different
post-message response frame when the next AT+FDR command is issued to
proceed with the session.  For example, the command AT+FPTS=3 could
be used for a borderline quality fax, and would cause the modem to
send an RTP retrain positive frame, telling the transmitter to
re-evaluate the quality of the phone line.

This ability to reset the post-page response can in theory be used to
generate procedure interrupts.  Writing a value of 4 or 5 back to
+FPTS will generate the PIN or PIP frames respectively.  If the
interrupt request is granted by the transmitter, then the modem
should give the +FVOICE response, indicating that the fax session has
been suspended in favour of a return to voice communications.

Despite the claim of many fax modems to be able all five types of
<ppr>, the ability to handle transitions to voice are not widely
supported and should not be assumed.  The ability of a modem to
return to phase B successfully after sending a PRI-Q frame should
also not be assumed.  The situation is somewhat analogous to that of
a transmitter than wants to use the EOM frame to end a page and then
return to the start of phase B.  A number of chipsets simply don't
support phase B negotiations except at the start of a session.

Issuing the command AT+FPTS=? (preferably while the modem is on-hook)
will enable the merely curious to gain some idea of which options any
particular model may support.  Responses such as 1,2,3,4,5 or 1-5 are
the sort thing that might be expected.  However, some modems respond
with an ERROR code, while other (not to put too find a point on it)
simply lie about their capabilities.  While they may seem to accept a
value written back to +FPTS, they ignore it when it comes to sending
the post-page message and simply transmit exactly what they were
going to in the first place.

(24)  Short note on EOL alignment and AT+FREL 

Since the EOL bit pattern consists of eleven 0 bits followed a 1,
a byte-aligned EOL would always consist of two bytes with the values
xxxx0000 00000001.  The bits marked x are don't-care bits, and can be
masked out by ANDing the byte with binary 00001111 (0f hexadecimal). 
So instead of having to pick the bits out of each received byte and
count the number of consecutive 0s, we simply take each byte in turn
and check to see if it contains a binary1.  If it does, we check to
see if the four least significant bits of the previous byte were all
zero.  If that condition is also satisfied, then we have received an
EOL code.  This simple test can be coded in C using two unsigned
character variables this_byte and last_byte.  For the case shown
above, which is actually what class 2 calls reversed bit ordering
 (FBOR=1 or TIFF FillOrder=1) the statement is :

if (this_byte==0x01)&&((last_byte&0x0f)==0) we_have_an_EOL ;
else last_byte=this_byte ;

The same test for direct bit ordering (FBOR=0 or TIFF FillOrder=2)
looks for the bit pattern 0000xxxx 10000000.  It can be coded as
follows :

if (this_byte==0x80)&&((last_byte&0xf0)==0) we_have_an_EOL ;
else last_byte=this_byte ;

Byte-alignment of EOL codes is one of the mandatory T4Options
bitfields for TIFF Class F.  The class 2 +FREL parameter controls
byte alignment of EOL codes.  AT+FREL=0 turns byte alignment off,
while AT+FREL=1 turns byte alignment on.  If data is coded
two-dimensionally, the tag bit indicating whether the next line is
coded one or two dimensionally is not aligned with the EOL codes ; it
is considered to be the first bit of the next line.

(25)  Short note om the +FET: report

For the sake of completeness, we ought to mention the possibilities
not mentioned in the text. If the last page resulted in an FET:1
report (the transmitter sent an EOM command) and the fax modem can
handle it, then the session resumes with a new phase B negotiation. 
The same applies if the receiver had successfully written a AT+FPTS=2
or AT+FPTS=3 to send a PRI-Q frame. Writing a AT+FPTS=4 or AT+FPTS=4
requests a procedure interrupt, which generates a +FVOICE if when
successful.

(26)  Short note on badly supported Rockwell options

We can cite a number of examples of supported options that are of no
use whatsoever.  One example of a useless Rockwell feature is that
although +FCQ is always 0 and no quality checking is possible, the
modem makes a point of returning values for the optional bad line and
consecutive bad line counts in the +FPTS: received page report.  The
counts are always 0, which at least is accurate.  Somewhat more
confusing for a device that doesn't implement +FBUG, many Rockwell
modems claim to support all four possible +FBOR values, and will
quite happily accept +FBOR values 2 and 3 even though they don't do
any phase B or phase D frame reporting.  Anyone implementing software
on a class 2 modem is advised to live with the Rockwell bit ordering
bug and ignore +FBOR settings, since it is clear that they can't be
relied on.

It is also worth mentioning that though the documentation claims to
support the +FET code of 3 (PPS-NULL), this only applies in error
checking mode, which the modem doesn't support at all.

(27)  Short note on the Zyxel Class 2

One of the few modem manufacturers who both write their own firmware
and also encourage developers by making details of their command set
public is Zyxel.  As well as the lowest common denominator command
set given earlier, Zyxel modems implement all of the polling
commands.  They are able to set a polling ID through AT+FCIG, and
implement both the AT+FLPL and AT+FSPL commands, as well as the
+FPOLL response.  Their modems also support operator interrupts, and
are capable of generating the +FVOICE response on receipt of a PIP or
PIN frame. In addition, Zyxel modems are notable for including the
+FNS command as an extension to their class 2 command set.  This is
actually part of the class 2.0 command set, and is discussed in the
next chapter.
