T.38 Fax Relay (Fax over IP)

What T.38 is

T.38 is the ITU-T Recommendation titled "Procedures for real-time Group 3 facsimile communication over IP networks." Its base edition is dated 06/98, and the ITU-T's own edition listing then runs 03/02, 04/04, 09/05, 04/07 and 09/10, with the 11/15 edition in force. Successive editions and amendments added protocol versions, RTP as a transport option, V.34 half-duplex support and call-establishment procedures for SIP and SDP. Because those additions arrived over seventeen years, any statement about what "T.38 does" should name the edition it describes; trade coverage that dates the standard to 1996, or treats it as a single 2002 document, is describing something the ITU-T's own record does not contain.

Two boundaries define the entry. First, T.38 is not an IETF standard. Sources that cite a "T.38 RFC" are conflating the Recommendation with the small set of IETF documents that make it usable inside SIP: RFC 3362 registers the image/t38 media type so an SDP offer can name a T.38 session, RFC 4612 registers audio/t38 for IFP packets carried inside RTP, and RFC 6913 defines the sip.fax media feature tag. RFC 4612 is classified Historic, which is a fact worth stating whenever it is cited.

Second, T.38 is not VoIP and is not "fax over SIP." Call control and media are separate layers. SIP, H.323, MGCP or a vendor call-control protocol negotiates the switch into a fax session; T.38 governs what crosses the network once that switch has happened. Confusing the two produces the common but wrong claim that a T.38 call is a voice call with a different codec.

Why the audio cannot simply be carried

A Group 3 fax machine is a modem attached to a scanner and a printer. On a voice-grade telephone circuit it worked because the circuit was indifferent to what it carried: it reproduced a waveform, and a modulated carrier is a waveform like any other. A packet voice channel makes no such promise. It is engineered for speech, and the three things it does to make speech cheap and tolerable — lossy low-bit-rate coding, a jitter buffer that reorders and discards, and an acceptance that a small percentage of packets will simply not arrive — are each individually destructive to a modem signal. A vocoder models the human vocal tract; it has nothing to model when handed a V.29 carrier, and what emerges is not a degraded fax tone but a different signal altogether.

The alternative to relay is therefore not "no standard." ITU-T V.152 standardises voice-band data: the transport of modem, fax and text-telephony signals across a packet voice channel using a codec appropriate to such signals, typically G.711, with negotiation at call setup. Its 09/10 edition explicitly contemplates hybrid deployments in which fax may travel either as voice-band data or as T.38 relay. Pass-through is a specified mode, not a workaround; the honest framing is a choice between two standardised approaches with different costs, not a standard versus a hack.

The bandwidth difference is not marginal. A patent filed in February 1999 for real-time facsimile over data networks describes packetising the recovered signal at roughly one-twentieth the bandwidth of carrying the same call as VoIP audio — a figure from a period filing rather than a measured benchmark, but one that explains why relay was pursued at all. It was cheaper as well as more robust.

The gateway mechanism

Vendor documentation for fax relay states the mechanism in four stages, and they are the clearest available description of what an implementation actually does.

1. 1

   Demodulate

   The transmitting gateway receives the incoming T.30 fax signals from the attached terminal and demodulates them — the V.21 low-speed control channel that carries the T.30 messages, and the V.27ter, V.29 or V.17 carrier that carries page data — recovering the underlying bit stream.

2. 2

   Translate

   The recovered T.30 signals are translated into T.38 IFP packets, the Internet Facsimile Protocol packet format defined by the Recommendation.

3. 3

   Exchange

   IFP packets are exchanged between the two gateways across the IP network, under whichever transport was negotiated.

4. 4

   Re-modulate

   The receiving gateway translates the IFP packets back into T.30 signals and modulates them onto the analogue line for the terminal at its end, which hears an ordinary fax call.

IFP packets, UDPTL and redundancy

The unit T.38 defines is the IFP packet, which carries either a T.30 message recovered from the control channel or a run of image data. How IFP packets reach the far gateway is a separate question, and it is the one most often reported backwards. T.38's own UDP transport layer, UDPTL, is the dominant transport: a UDPTL datagram carries a primary IFP frame together with a number of redundant copies of previously sent frames, with the redundancy count carried in the UDPTL header's control field. TCP is defined as an alternative, and RTP was added as a further option by a later edition rather than being present from the start.

The distinction matters because the error-recovery machinery differs by transport. Under UDPTL, resilience comes from that in-band redundancy — a lost datagram is recoverable if a later one still carries a copy of the frame it contained — whereas the IETF's redundant-payload and generic-FEC mechanisms apply only where IFP packets are carried inside RTP.

Redundancy also has a hard ceiling. It protects against loss up to the depth configured; beyond that, frames are simply gone, and what the terminal experiences is a corrupted page or a failed session. Error Correction Mode, defined in T.30 itself, retransmits damaged frames within the fax protocol and is enabled by default in at least one major vendor's implementation — which also recommends disabling it on links with two percent or greater packet loss, because ECM retransmission across a lossy relay can turn a degraded page into a failed call.

Spoofing the T.30 clock

T.30 is a timer-bound protocol. It was written for a circuit where the far terminal's answer arrived after a propagation delay measured in milliseconds, and its response windows encode that assumption. Once the two terminals are talking to gateways instead of to each other, the network delay between the gateways sits inside those windows, and the terminals will time out on silence that is not really silence.

The resolution is spoofing — a term that in this literature has nothing to do with security. Each gateway generates artificial T.30 signalling toward its attached terminal, stretching or synthesising the parts of the handshake that keep the terminal inside its own timers while packets are in transit. Vendor documentation describes this for its own products, along with the related constraint that low-bit-rate vocoders cannot carry T.30 modem signals at all. Specific timeout figures quoted in such guides are observations about particular implementations, and should not be presented as ITU-T requirements.

TCF and rate management

Before page data flows, a T.30 call includes a training check field — a burst at the proposed speed that lets the receiver confirm the line will sustain it. Relay creates a genuine branch point here, because there is no longer a single line to test. T.38 defines two rate-management models. Under localTCF, the gateway generates the training check toward its own terminal and evaluates the one it receives, so the sequence never crosses the network. Under transferredTCF, the training check is carried across. The choice is not an implementation detail: T38FaxRateManagement is a required SDP parameter in the audio/t38 registration, so the two ends must agree on a model before the session can carry a training check at all. Writing that "the gateway forwards the training sequence" describes only one of the two models.

How a call becomes a T.38 call

SIP handles fax voice-first, and the IETF has said so in its own words: a fax call is indistinguishable from a voice call at the time the initial INVITE is sent, so the intent to use T.38 is unknown at call setup. That is why fax over IP is normally a mid-call renegotiation rather than an initial offer — the call is established as voice, the fax is detected, and the session is re-negotiated to a T.38 media stream. RFC 6913 defines the sip.fax media feature tag, using the caller-preferences framework, precisely so that this capability can be indicated rather than discovered by accident.

Detection itself relies on the tones the fax protocol already emits. RFC 4734 defines events for modem, fax and text-telephony signals, including the 1100 Hz CNG calling tone sent by a terminal operating in automatic mode, the 2100 Hz CED answer tone from an answering terminal, the phase-reversed variant used to disable echo cancellers, and the V.21 preamble flag that marks the start of T.30 messages. Signalling these events over IP lets a gateway recognise what it is carrying and switch payload types at the right moment. Note that CNG is not universal — a manually originated fax commonly sends none — which is one reason detection-based switchover is not perfectly reliable.

Why fax over IP still fails

• Packet loss beyond the configured redundancy depth is unrecoverable at the UDPTL layer, and ECM retransmission on a lossy link can convert a degraded page into a failed session.
• Interoperability between independent implementations is genuinely hard. The ITU-T maintains an Implementors' Guide for T.38 recording ambiguities and defects found in the field — the standard's own maintainers documenting that deployments diverge.
• Rate management is a required SDP parameter, so localTCF and transferredTCF ends must agree; no source located for this entry quantifies how often they do not.
• V.34 fax at 33.6 kbit/s was not an original feature. The ITU-T's edition notes list V.34 half-duplex support as an amendment addition, so claims that T.38 has always carried Super G3 are anachronistic. Conversely, forcing fax down to V.17 at 14.4 kbit/s over IP is a widespread deployment convention, not something the Recommendation mandates.
• Spoofing is bounded. A gateway can hold a terminal inside its timers for a while; it cannot do so indefinitely, and a long enough network stall still surfaces as a timeout at the terminal.
• The switch into T.38 can be missed entirely if the far end does not indicate fax capability, if detection fails, or if an intermediary rewrites the media negotiation.