VoIP

Fax over IP and T.38: Why Fax Breaks on VoIP (and When T.38 Is the Wrong Answer)

Himanshu Pal

Himanshu Pal

Why fax and VoIP fight each other

Fax was designed for an analogue circuit: a continuous, dedicated path with predictable timing. It encodes page data as modem tones and assumes those tones arrive intact and in order, at exactly the right speed.

VoIP provides none of that. Packets arrive out of order, occasionally not at all, and with variable timing. A voice conversation shrugs off a lost packet — the listener's brain fills the gap. A fax transmission does not: a corrupted tone sequence means a garbled page or an aborted transfer.

Compression makes it worse. Codecs such as G.729 are tuned specifically for the human voice, and modem tones are not human speech. They emerge distorted enough to be unreadable. A compressed codec will not carry fax reliably at any quality setting.

What T.38 does

T.38 is the ITU-T standard for fax over IP, and its approach is to stop pretending fax is audio. Rather than transporting the modem tones, a T.38 gateway demodulates them, extracts the underlying fax data, and sends that data as packets. At the far end the process reverses and the tones are regenerated for the receiving fax machine.

Because the actual page data is being carried rather than a fragile audio representation of it, the transmission survives conditions that would destroy an audio-based fax. T.38 also includes redundancy mechanisms so lost packets can be reconstructed.

The transport is usually UDPTL, and Asterisk exposes the relevant knobs including redundancy and error-correction settings for the UDPTL layer.

The counterintuitive part: T.38 is not always better

Here is the thing most guides omit, and it changes how you should configure trunks.

Traditional fax has its own reliability mechanism: ECM (Error Correction Mode), negotiated directly between the two fax machines. When ECM is active, the machines detect corrupted blocks and retransmit them, which is what makes fax reliable in the first place.

ECM and T.38 handle errors differently, and they do not compose well. Crucially, when a T.38 call passes through a T.38-to-G.711 gateway — as it must if the far end is on the PSTN — ECM is lost in the transcoding. You give up the fax machines' own end-to-end error correction in exchange for T.38's packet-level redundancy, and on a path that is partly PSTN you can end up with neither working properly.

The practical rule that follows:

  • Use T.38 only when the call is T.38 end to end. Both endpoints and every hop between them must speak it.
  • If you are faxing over the PSTN, disable T.38 and set the codec to G.711µ only. Staying on uncompressed G.711 keeps ECM alive and negotiated directly between the two fax machines, which is the more reliable arrangement on a mixed path.

This is the opposite of the common assumption that T.38 should always be enabled. Whether T.38 helps depends entirely on what the whole path looks like.

Configuring for reliable fax

For the G.711 approach, lock the codec down so nothing negotiates its way to a compressed codec mid-call:

[fax-trunk]
type=endpoint
disallow=all
allow=ulaw

Also disable anything that processes the audio. Echo cancellation, comfort noise and silence suppression all assume they are handling speech, and each will mangle modem tones. Silence suppression is especially destructive: fax contains long steady tones that a voice-activity detector happily classifies as silence and discards.

For the T.38 route, enable it on the endpoint and confirm your carrier supports it end to end — ask explicitly rather than assuming, since "we support T.38" sometimes means "we have a gateway", which is exactly the ECM-destroying case above.

Diagnosing fax failures

Fax problems are usually reported vaguely ("faxes don't work"), so establish the pattern first:

  • Short faxes succeed, long ones fail. Classic packet loss — errors accumulate with page count. Fix the network before touching fax settings.
  • Pages arrive but are garbled. Tone distortion. Check for a compressed codec, or audio processing that should be disabled.
  • Transmission aborts immediately. Negotiation failure — the two ends did not agree on T.38, or one attempted a switch mid-call that the other refused.
  • Works to one destination, fails to another. The difference is in the far end's path, which is where the T.38-versus-G.711 question usually bites.

Watch a live attempt with SIP logging on. A T.38 switch appears as a re-INVITE mid-call, and seeing whether that re-INVITE is accepted or rejected tells you immediately which side is refusing.

The honest recommendation

Fax over IP is achievable but fragile, and it consumes an amount of engineering attention out of all proportion to its value in most businesses.

If fax is genuinely business-critical — as it remains in parts of healthcare, law and government — consider whether it needs to be on your VoIP path at all. A dedicated analogue line for the fax machine, or a hosted fax service that handles the transport as a document rather than a call, removes the entire class of problem. Both are frequently cheaper than the hours spent tuning trunks.

Frequently asked questions

Why does fax fail over VoIP?

Fax encodes data as modem tones that need an intact, correctly timed audio path. Packet loss, jitter and codec compression all corrupt those tones. Voice tolerates that damage; fax does not.

Should I always enable T.38?

No. Use T.38 only when the call is T.38 end to end. If the path crosses to the PSTN, a T.38-to-G.711 gateway strips ECM — in that case G.711µ with T.38 disabled is more reliable.

What is ECM and why does it matter?

Error Correction Mode is negotiated between the two fax machines and retransmits corrupted blocks. It is what makes fax dependable, and it is commonly lost when T.38 is transcoded at a gateway.

Which codec should I use for fax?

G.711 (µ-law or A-law) and nothing else. Disable compressed codecs, echo cancellation and silence suppression on any path carrying fax.