T.38 vs G.711

Fax over IP can travel two ways: T.38, which demodulates the fax and carries it as data with error correction, and G.711 pass-through, which carries the raw modem tones as audio. Faxart supports both, but not as a setting you pick.

One configuration, not a fork

A fax starts as a G.711 voice call and tries to upgrade to T.38 by re-INVITE. If the far end accepts, the fax rides T.38. If it declines, the fax stays on the audio path. So “support both” is the default behavior, not a branch in your config: Faxart offers T.38, accepts T.38, pins the audio codec, and runs error correction (ECM) on both paths. A new T.38-capable carrier lights up automatically, with no redeploy.

Why it matters

• G.711 pass-through works against legacy paths but is fragile on lossy or jittery links: it is a raw modem carrier with no forward error correction. A burst of jitter can corrupt the carrier mid-page, and ECM alone can’t recover a long enough gap.
• T.38 is built for imperfect networks. It demodulates the fax to data and adds forward error correction, so it survives packet loss and jitter that would destroy a pass-through fax.

On a trunk with a jitter problem, moving to T.38 is a reliability fix, not just a tidier protocol. That’s the case where the automatic upgrade earns its keep.

Getting real T.38 negotiated

Faxart already offers and accepts T.38; whether a call actually negotiates it depends on the path. Every hop (the session border controller, the call manager, the carrier) has to permit T.38 end to end. Those are voice-team config changes on the gateway side, not Faxart changes. Until they land, Faxart rides G.711 automatically; the moment they land, the same config upgrades to T.38.

A separate axis: encryption

Neither T.38 nor G.711 encrypts media by itself. If on-wire PHI encryption is required, that’s a separate SRTP / SIP-TLS change on the gateway side, independent of the transport choice here.

See also

• Architecture
• High availability