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:

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.

Generated on Tue Oct 7 20:25:52 2008 for spandsp by  doxygen 1.5.6