T.38 real time FAX over IP message handling

There are two ITU recommendations which address sending FAXes over IP networks. T.37 specifies a method of encapsulating FAX images in e-mails, and transporting them to the recipient (an e-mail box, or another FAX machine) in a store-and-forward manner. T.38 defines a protocol for transmitting a FAX across an IP network in real time. The core T.38 modules implements the basic message handling for the T.38, real time, FAX over IP (FoIP) protocol.

The T.38 protocol can operate between:

• Internet-aware FAX terminals, which connect directly to an IP network. The T.38 terminal module extends this module to provide a complete T.38 terminal.
• FAX gateways, which allow traditional PSTN FAX terminals to communicate through the Internet. The T.38 gateway module extends this module to provide a T.38 gateway.
• A combination of terminals and gateways.

T.38 is the only standardised protocol which exists for real-time FoIP. Reliably transporting a FAX between PSTN FAX terminals, through an IP network, requires use of the T.38 protocol at FAX gateways. VoIP connections are not robust for modem use, including FAX modem use. Most use low bit rate codecs, which cannot convey the modem signals accurately. Even when high bit rate codecs are used, VoIP connections suffer dropouts and timing adjustments, which modems cannot tolerate. In a LAN environment the dropout rate may be very low, but the timing adjustments which occur in VoIP connections still make modem operation unreliable. T.38 FAX gateways deal with the delays, timing jitter, and packet loss experienced in packet networks, and isolate the PSTN FAX terminals from these as far as possible. In addition, by sending FAXes as image data, rather than digitised audio, they reduce the required bandwidth of the IP network.

What does it do?

How does it work?

Timing differences and jitter between two T.38 entities can be a serious problem, if one of those entities is a PSTN gateway.

Flow control for non-ECM image data takes advantage of several features of the T.30 specification. First, an unspecified number of 0xFF octets may be sent at the start of transmission. This means we can add endless extra 0xFF bytes at this point, without breaking the T.30 spec. In practice, we cannot add too many, or we will affect the timing tolerance of the T.30 protocol by delaying the response at the end of each image. Secondly, just before an end of line (EOL) marker we can pad with zero bits. Again, the number is limited only by need to avoid upsetting the timing of the step following the non-ECM data.