May 18, 2001
Facsimile technology has been in use for over 100 years, but in 1968, the International
Telecommunications Union (ITU), the international standards body for telecommunications,
published the standard for Group 1 fax. In 1976, it published Group 2. In 1980, it first published
Group 3.
Group 3 is specified in several standards: T.4 specifies the image-transfer protocol. T.30 specifies
the session-management procedures that support the establishment of a fax transmission. T.30
allows the two endpoints to agree on such things such as transmission speed and page size.
Since G3 is specified for the switched analog network, and it is an all-digital procedure, it must use
modems or fax relay. They are also specified in ITU standards: V.21 (300 bps) for the T.30
procedures, and for image transfer V.27ter (2400/4800 bps) and, optionally, V.29 (7200/9600 bps)
and V.17 (7,200/9,600/12,000/14,4000). Real-time IP fax transport is specified in T.38. It replaces
modems.
To understand G3 fax, and the options it offers the system designer, it's important to
understand the basics of T.30. T.30 sets the session-control procedures for G1, G2,
and G3. It divides a call into five phases:
Phase A - Call set up
Phase B - Pre-message procedure for identifying and selecting call-specific
facilities
Phase C - Image transfer
Phase D - Post-message procedures (EOM and multi-document
procedures).
Phase E - Call release
The tones that calling and called faxes send at the beginning of a fax call are necessary because
G3 is intended for transmission over the voice network. There must be in-band procedures for
establishing that there is a fax terminal on each end of the call before proceeding further. So, the
calling terminal periodically transmits a Calling Tone (CNG - 1100 Hz for 0.5 sec.) that identifies it
as a fax machine. The called station answers with Called Station Identification (CED) a 2100 Hz
tone. This marks the end of Phase A since it's established that there's a fax at each end of the call.
The next task is for each end to agree which end will transmit, at what speed, for what page size,
and so on. That's handled in Phase B.
The session-control procedures used to control the call from Phase B to E (Call Release) use
HDLC procedures at 300 bps as defined in V.21. Phase B begins with the called station
transmitting the mandatory "facsimile control field", Digital Identification Signal (DIS), a packet
which characterizes the called station's capabilities:
Group?
Data rate?
Vertical resolution? (7.7 lines/mm yes/no)
Two-dimensional encoding? (y/n)
Page-width capabilities
Maximum page-length capability
Handshake speed
Error-correcting mode (y/n)
And so on
DIS, and the other facsimile control fields (DTC and DSC), may each be associated with one or two
optional packets, the first optional packets identifies the terminal sending the control field; the
second is undefined by T.30. This non-standard field provides the opportunity to solve the problem
of inbound fax routing without using voice prompts or DID. The reason it has not been used for this
purpose is because T.30 didn't specify it and no de-facto standard has emerged. However,
MultiFax allows the system developer to set and read these fields in a standardized manner.
The calling station, which is still in control of the session, can then either command the called
station to receive or transmit. If the calling station commands the called station to transmit, it's a
poll. If the caller wishes to transmit, it must, with the facilities of the called station now determined
from the DIS, set the parameters of the fax to be sent (sends DCS). The called station
acknowledges with a Confirmation to Receive (CFR). If the calling station is polling the called
station, it's a little more involved.
To initiate a poll, the calling station sends a Digital Transmit Command (DTC). As with DIS, the
DTC can be sent with station ID and the non-standard field. The non-standard field can be used to
identify the particular fax to be sent (the caller wishes to receive) as well as the polling station's
password, if required. If polled, the called station assumes control of the session. If it has nothing
to transmit it sends a disconnect to the caller and hangs up. Therefore, the calling station should
always transmit any queued documents before polling. If the polled station has a document to
transmit, it sends DCS, the command to receive. Note that, as with the other control fields, the
transmitter can send its station ID, as well as the ID of the individual recipient.
The G3 in-message procedures are specified in T.4. It divides the page into horizontal picture
elements (pels) of, nominally 1728 pels/line of 215 mm, and either 3.85 or 7.7 lines/mm. Minimum
transmission time per line is controlled to eliminate overrun in printing faxes with limited buffers.
T.4 specifies the G3 data-compression coding schemes, often referred to as Huffman encoding or
READ encoding (Relative-Element Address Decoding) One-dimensional, run-length encoding
involves fixed codes for white/black run lengths (e.g., the number of contiguous white or black
pels). A special code is used for EOL. Six EOLs at the end of the document marks the end of
Phase C. Two-dimensional (Modified READ) encoding provides additional compression by
encoding two lines at a time; the second line specifies changes from the first. Modified-Modified
READ (MMR) encoding encodes the entire fax image as picture elements relative to a first
reference line. Therefore, if there are any transmission errors, the entire fax following the error is
unintelligible. However, Error-Correcting Mode solves the problem.
G3 faxes can also be transmitted using the T.30, Annex A, error-correcting standard. It uses the
HDLC transmission-control procedures used in the session-management procedures in Phase B,
D, and E to transfer the image data in Phase C. HDLC includes cyclic-redundancy error checking.
This allows the receiver to detect errors in the received image data. If there is an error in a
received data packet, the transmitting end retransmits at the request of the receiver (Automatic
Repeat Request - ARQ). Less than 25% of installed G3 faxes include error-correcting mode.
Several options are available when document transmission is complete:
From the transmitting station:
Switch directions (turnaround polling).
Change resolution, paper size, transfer data rate.
End of Message (EOM), return to Phase B.
Multi-page Signal (MPS), go to the beginning of
Phase C for next page.
End of Procedures (EOP), go to Phase E.
From the receiving station:
Message Confirmation (MCF).
Retrain, retry, etc.
If the transmitting station follows EOP with the Disconnect Command (DCN), it and
the receiving end will then both hang-up.
A typical page of ASCII-coded text will require a few thousand bytes of storage. ASCII is the most
highly encoded form of image representation typically used in document storage, but it is limited to
representing the defined ASCII symbols. Also, as we know, it must be translated to the Group 3
line-by-line representation of black and white pels before it is presented to the fax modem. For a
typical page of text, a Huffman-encoded file will be roughly 10 times larger than its ASCII
equivalent, or about 35,000 bytes. Of course, ASCII doesn't support graphic images, so most fax
software products support various graphic file types, with the most common being TIFF-F (Tagged
Image File Format-F). TIFF-F is quite common and is exported by most scanners.
The tags in TIFF specify such things as page size and compression. Actually, the compression tag
is often omitted, in which case the TIFF standard defaults to "class one storage", which is no
compression at all. Storage classes two, three, and four are variations of ITU-defined modified
Huffman encoded data. One of these is the run-length encoding defined in T.4, and is what
constitutes a TIFF-F (for fax) file. Commetrex uses an ordered TIFF-F file format, which is the
output from its conversion or fax receive processes. There are no known incompatibilities between
the Commetrex implementation and other products.
Others graphics file formats supported by various fax software products include PCL, PCX, GEM,
IMG, etc. These are graphics formats developed by printer and graphics software manufacturers.
The graphics formats must be supported by the fax software to allow direct use of the outputs of
these packages.
Some fax products support what is called "conversion on the fly". Typically, this means that the
product will accept an ASCII file and convert it to the Huffman-encoded format required for
transmission without requiring intermediate disk storage. Some products modify this by accepting
the source file in its format, executing the conversion and spooling it to disk for transmission when
the conversion is complete. Some PC add-in products can execute the ASCII-to-Huffman
conversion on the fax board. This not only saves disk storage, but off loads the task from the host
PC. Of course, if the source-file format is not handled by the board-level process, the conversion
must be performed on the host PC. For fax-on-demand systems, where the bulk of the function is
to transmit graphic files, the converted file is usually stored as the source file.
There are two major categories of fax APIs: one supports the development of applications for the
individual PC user, the other is for multi-line fax applications such as fax servers and fax-on-
demand systems.
The first of the single-user APIs, Communicating Applications Specification (CAS), was established
to allow third-party developers to use fax boards in a DOS environment. In 1991 the FaxBios
Association, published the FaxBios API for DOS and Windows. FaxBios, which is incompatible
with CAS, provides a superset of CAS's functionality by adding directory management, graphics,
and other services.
The third single-user fax API, called variously T.APPLICOM, T.APPLI/COM, and T.611, was
developed by France Telecom. It was designed to be downward compatible with CAS. Therefore,
existing CAS applications should work without modification. Class 1 partitions G3 fax functionality
between fax-modem DCE and DTE, and shown above, and defines 6 commands, four of which are
transmit/receive HDLC frame and transmit/receive image data. The fax modem can be stand-
alone or an add-in board. In 1988 the AT+F command set was developed. It allows PC-based fax
applications to communicate with fax modems via the PC's serial port similar to the way data
communications applications interface with modems using the AT command set.
The problem with Class 1 and Class 2 interfaces (Class 2 moves T.30 to the board) is that
they don’t scale well. The interface is the PC’s serial port, which is an inefficient character-by-
character I/O transfer mechanism. So called intelligent fax boards use block-transfer
techniques, and can comfortably scale to 120 ports on one PC.
There are only about a half-dozen manufacturers of PC add-in multi-line fax boards that serve as
the OEM foundation for fax systems. Each of these manufacturers has developed a proprietary
API. However, in the late ‘90s the ECTF published its S.100 recommendation, which includes a fax
sender-receiver resource API. Four vendors have released an S.100-conformant telephony-
middleware product: Aculab, Brooktrout, Commetrex, and Intel.
The world’s telecommunications networks have begun their evolution from the 127-year-old circuit-
switched model (the public switched telephone network—PSTN) to a packet-based model that
uses the Internet Protocol (IP) to transport voice, fax, data modem, and video, in addition to normal
Internet traffic. The benefit of this converged network goes beyond the lower costs to the network
owner for equipment, maintenance, and management. IP-based networks, due to the low cost and
ubiquity of the technology and the enhanced signaling available in packet networks, make it
possible to offer high-value communications services that are simply not economic with the PSTN.
Gateways serve as bridges between the legacy PSTN and next-generation IP networks by
transforming the PSTN call stream to data packets, and vice versa. Since the installed based of
video conferencing systems, telephones, fax terminals, and dial-up data modems assume that
there is a circuit connection between correspondent terminals, and IP is a “connectionless”
transport, PSTN-IP gateways must have specialized processing for each call type. Special
processing for voice over IP is needed to conceal lost packets, for example. If a service provider is
to offer dial-up access over a metro IP network, special modem-relay functions are required for the
service to offer reliable modem connections. Similarly, clean faxes over an IP network require fax-
specific processing functions called fax relay. The international interoperability standard for fax
relay is called T.38.
The T.30 standard specifies the protocol used by PSTN-connected fax terminals to send faxes in
real time, which means the fax is received at the same time it is transmitted. So, T.30 governs the
end-to-end protocol in the diagram below, while T.38 governs the protocol between the two
gateways. (Examination of the diagram reveals the T.38 gateways must be transparent to the fax
terminals.)
But, what if we wanted to terminate the IP fax within the IP network, as would be necessary to
implement an IP-based fax broadcast or a network-based corporate fax-server facility? This
means the gateway and the fax terminal on one end of the transaction disappears. What must take
its place is equipment that combines the function of the T.38-capable gateway and the fax terminal
which implements one side of the end-to-end T.30 fax protocol, as shown below.
Commetrex’ TerminatingT38™, a combination of its T.38 and T.30 fax protocol engines, gives the
developer of a network-service platform or an enterprise fax server the technology necessary to
terminate T.38 (IP network) real-time fax transmissions the same as it would real-time faxes from
the PSTN using high-density analog fax modems. Think of removing the fax modems from a
PSTN-based server and replacing with T.38 for the IP-based server.
|
