Troubleshooting · Symptoms
Fax Over VoIP and T.38: Making Fax Work (or Replacing It)
Fax machines are audio modems from another era, and they assume a circuit that delivers every tone intact and on schedule. VoIP — compressed codecs, jitter buffers, packet loss concealment — violates every one of those assumptions. A one-page fax may survive; a ten-page transmission through G.729 with 2% loss is a coin flip. The industry's answer is T.38, a protocol that stops pretending fax is voice and carries it as data instead.
This guide explains why fax-over-VoIP fails, how T.38 is supposed to work, the settings that decide success, and the honest point at which a hosted eFax service is the professional recommendation.
Why fax fails on voice-optimized VoIP
- Compression: G.729 and similar codecs are speech models; modem tones are not speech and are mangled beyond recognition. Fax pass-through demands G.711 — and even then the remaining issues apply.
- Jitter and loss: fax modem protocols (V.21/V.27ter/V.29/V.17) time their handshake and page data tightly; jitter buffer adjustments and lost packets break training and drop pages mid-document.
- Echo cancellation and voice processing: ECAN, VAD and silence suppression treat fax tones as noise or echo and 'helpfully' destroy them; fax paths must bypass voice processing.
- Clock slips: pass-through fax across gateways with unsynchronized clocks drifts; long documents fail near the end — the classic 'page 9 of 10 fails' pattern.
How T.38 fixes it — when it's actually on
With T.38, the gateway near the fax machine demodulates the fax tones into the T.30 fax protocol data and sends that data (UDPTL packets, with redundancy) across IP; the far gateway re-modulates it for its local machine. IP impairments now hit a data protocol with error recovery instead of a live modem signal. The catch: T.38 must be supported and negotiated end-to-end on the media path — your ATA, the provider, and any SBC between. A common failure is the mid-call switchover: the call starts as G.711 audio, the gateways detect fax tones and re-INVITE to T.38, and a NAT/ALG quirk breaks the re-INVITE — fax dies at page one. In the capture you will see the re-INVITE; confirm it succeeds (200 OK) and the media type changes to T.38/UDPTL.
Settings and sequence that maximize success
- Confirm every element on the path advertises T.38 support (ATA/gateway, PBX, provider trunk) and that it is enabled; disable 'fax pass-through only' modes where T.38 is available.
- On the fax machine itself: set maximum baud to 9600 (or V.17 off) and turn ECM (Error Correction Mode) OFF for VoIP paths — ECM's retrains amplify every network hiccup into a failure; these two settings fix more fax issues than any network change.
- Ensure the ATA's port for the fax disables echo cancellation, VAD/silence suppression and jitter-buffer adaptation (fixed buffer) per the vendor's fax profile.
- Capture a failing fax: verify the T.38 re-INVITE succeeds and UDPTL flows both ways; if the call never leaves G.711, find which element refused the switchover.
- Set expectations and a threshold: if fax volume is high or documents are long/legal-critical, move the workflow to a reputable eFax service (priced in the clinic budget guide) and keep a tested ATA path as backup — reliability is the requirement, nostalgia is not.
Frequently asked questions
- Why do short faxes work and long ones fail?
- Probability and drift: every page is another exposure to loss, jitter and clock slip, and pass-through impairments accumulate over minutes. Long-document failure with short-document success is the signature of a marginal pass-through path — exactly what T.38 exists to replace.
- Is fax over VoIP HIPAA-appropriate for clinics?
- The transport question and the compliance question are separate. eFax vendors serving healthcare sign BAAs and encrypt in transit/at rest; a random ATA pass-through setup may not meet your safeguards. Clinics should use a BAA-covered service — see the medical clinic budget guide.
- Our provider says T.38 is enabled but faxes still fail at page 1.
- Page-one failures usually mean the T.38 switchover itself failed (re-INVITE rejected or media path broken by NAT/ALG). The capture distinguishes it: look for the re-INVITE at fax-tone detection and its response.
Sources and further reading
- ITU-T T.38: Procedures for real-time Group 3 facsimile communication over IP networks
- ITU-T T.30: Procedures for document facsimile transmission