Fax Technology Primer

Group 3

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

Phase A – Call Set UP (Verify Fax Machine At Each Endpoint)

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.

Phase B – Pre-Message Procedure (Identify And Select Required Facilities)

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.

Phase C – Image Transfer…Message Transmission

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.

Phase D – Post-Message Procedures

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.

Phase E – Call Release

If the transmitting station follows EOP with the Disconnect Command (DCN), it and the receiving end will then both hang-up.

File Formats

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.

Fax Applications Programming Interfaces (APIs)

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.

IP Fax

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.