Fax over IP (FoIP): How T.38 Works and Why Your SBC Matters

A lot of people think fax is dead. It is not. Healthcare organizations transmit patient records by fax because HIPAA treats it as a compliant transmission method. Courts accept faxed filings. Government agencies require faxed forms. Financial institutions close loans with faxed signatures. As long as these industries depend on fax, every voice network that migrates from the PSTN to IP needs a plan for carrying fax traffic reliably.
The problem is that fax and Voice over IP do not get along naturally. The same packet loss, jitter, and codec compression that a voice call tolerates will affect a fax transmission. This article explains how Fax over IP (FoIP) works, why the T.38 protocol exists, how T.38 relay differs from G.711 passthrough, and what your Session Border Controller (SBC) needs to do to keep fax working after you move to IP.

What Is Fax over IP (FoIP)?

Fax over IP is exactly what the name suggests: transmitting fax documents across an IP network instead of a traditional circuit-switched PSTN line.
Traditional fax machines communicate using the T.30 protocol, which was designed for analog telephone circuits. When a sending fax machine calls a receiving fax machine, they negotiate capabilities (speed, resolution, compression) via a handshake of modem tones. The sending machine then modulates the scanned image data into audio-frequency signals and transmits them over the phone line. The receiving machine demodulates those signals back into image data and prints the page.
This process depends on a continuous, low-latency analog circuit with predictable timing. A PSTN circuit-switched call provides exactly that. A VoIP transmission built for carrying voice does not.
On an IP network, voice (and fax) audio is sampled, digitized, chopped into packets, and (if using the public internet) sent across a best-effort network where packets can arrive late, out of order, or not at all. Voice codecs like G.729 aggressively compress audio to save bandwidth, which works well for human speech but mangles the precise modem tones that fax machines use to communicate. Even uncompressed G.711 can fail if packets are lost or if jitter buffers introduce timing variation.
The result: fax transmissions that fail partway through, produce garbled pages, or never connect at all. As the PSTN continues to sunset and voice networks consolidate onto IP, solving this problem is not optional for service providers, MSPs, and enterprises that serve fax-dependent industries.

How T.38 Works

T.38 is an ITU-T recommendation (standard) designed specifically for real-time fax transmission over IP networks. Rather than trying to force fax audio through a voice codec and hoping for the best, T.38 takes a fundamentally different approach: it demodulates the fax signal into structured data, transports that data as packets with built-in redundancy, and re-modulates it back into fax audio at the receiving end.
Here is how a T.38 fax call flows through a typical network:

1. Voice call setup. The sending fax machine initiates a standard phone call via SIP. The call is established as a normal voice session with an audio codec (typically G.711).
2. Fax tone detection. When the sending fax machine emits a CNG (Calling) tone (a 1,100 Hz tone that repeats every 3 seconds) and the receiving machine responds with a CED (Called) tone (a 2,100 Hz tone), the network detects that this call is a fax, not a voice conversation.
3. SIP re-INVITE to T.38. The gateway doing the TDM to IP conversion sends a SIP re-INVITE to the other side, proposing to switch the media type from audio/RTP to image/T.38. If the other side accepts, both legs switch to T.38 media. An SBC will relay these re-INVITEs and switch to T.38.
4. T.38 media transmission. The sending gateway demodulates the T.30 fax audio into T.38 data packets. These packets carry the fax image data in a structured format (IFP — Internet Facsimile Protocol packets) and are transported using UDPTL (UDP Transport Layer) or, less commonly, RTP. UDPTL includes built-in redundancy: each packet carries copies of previous packets so the receiver can reconstruct lost data without retransmission.
5. Re-modulation and delivery. The receiving gateway takes the T.38 data packets, re-modulates them back into T.30 fax audio, and delivers them to the receiving fax machine over its local connection (which may be analog, ISDN, or another IP leg).
6. Call teardown. When the fax transmission completes, the call ends with a standard SIP BYE.

The key insight is that T.38 isolates the fax data from the impairments of the IP network. Packet loss that would corrupt a G.711 fax audio stream is handled by UDPTL’s redundancy mechanism. Jitter that would throw off fax timing is absorbed because the data is structured, not a raw audio waveform. Codec transcoding never touches the fax content because it is carried as data, not audio.

T.38 Relay vs. G.711 Passthrough

There are two approaches to carrying fax over an IP network, and understanding the difference is critical for configuring your SBC correctly.
G.711 Passthrough treats the fax call exactly like a voice call. The fax machine’s modem audio is sampled at 8 kHz, encoded as G.711 (PCMU or PCMA) RTP packets, and sent across the network. No demodulation occurs. The raw fax audio (T.30) travels end-to-end as standard RTP.
This is the simpler approach, but it is fragile. For G.711 passthrough to work, every device in the path must cooperate: silence suppression (VAD) must be disabled (or it will cut the fax signal during pauses), echo cancellation must be disabled (or it will interfere with modem tones), no codec transcoding can occur anywhere in the path (G.729 or any compressed codec will destroy the fax), and packet loss must be near zero. Even 1-2% packet loss can cause a fax page to fail in passthrough mode because there is no redundancy mechanism.
T.38 Relay demodulates the fax audio at the sending gateway, carries the fax data as T.38 packets with built-in redundancy, and re-modulates at the receiving end (as described in the section above). This approach is more resilient because it separates the fax content from the audio transport and includes its own error correction.

When to Use Each

T.38 relay is the preferred method when both endpoints (or gateways) support it. It handles network impairments better, uses less bandwidth, and produces higher fax success rates.
G.711 passthrough is the fallback when one or both endpoints do not support T.38. It works on networks with low packet loss and jitter, but requires careful configuration to avoid common failure modes.
In many real-world deployments, the SBC handles a hybrid scenario: T.38 on the carrier-facing leg (where the SIP trunk provider supports T.38) and G.711 passthrough on the customer-facing leg (where the fax device or PBX does not support T.38), or vice versa. The SBC bridges the two by demodulating one side and re-modulating for the other. This is one of the most valuable functions an SBC provides for fax traffic.

Why Fax Fails on VoIP Networks

If you are troubleshooting fax failures on an IP network, the cause is almost always one of these issues:
Codec transcoding is the most common culprit. A compressed codec (G.729, G.726, AMR) somewhere in the path destroys the fax modem tones. Fax audio must remain in G.711 or be handled via T.38. If any trunk group, PBX, or carrier in the path forces a lossy codec, fax will fail.
Packet loss becomes critical in G.711 passthrough mode, where even 1% loss can corrupt a fax page. Unlike voice, where the human ear can tolerate brief dropouts, a fax machine interprets every bit of the audio waveform. A single lost packet can invalidate an entire page.
Silence suppression (VAD) saves bandwidth by not sending packets during silence. Fax machines produce pauses between pages and during negotiation phases. If VAD interprets these pauses as silence and stops transmitting, the receiving fax machine loses synchronization and the session fails.
Echo cancellation presents a risk because echo cancellers designed for voice can interfere with the 2,100 Hz CED tone and other modem signals. Many echo cancellers are designed to disable themselves when they detect a 2,100 Hz tone, but not all implementations work correctly.
SIP re-INVITE failures occur when the SBC or gateway detects fax tones and sends a SIP re-INVITE to switch to T.38, but the re-INVITE must reach the other side and be accepted. Firewalls, NAT devices, and SIP-unaware middleboxes can block or corrupt re-INVITEs, preventing the T.38 switchover. The call falls back to G.711, and if passthrough conditions are not met, the fax fails.

The Role of the SBC in Fax over IP

An SBC sits at the boundary between network segments: between your internal network and a SIP trunk provider, between two carriers in a peering arrangement, or between a customer’s PBX and your hosted voice platform. This boundary position makes the SBC the natural point of control for fax handling.

Key SBC Functions for FoIP

T.38 re-INVITE relay is the primary fax handling function. When a gateway on one side of the call detects fax tones and sends a SIP re-INVITE to switch to T.38, the SBC relays that re-INVITE to the other side and switches to the configured fax mode. The SBC does not detect fax tones itself; it responds to the re-INVITE signaling from the gateways and applies the fax relay configuration you have set (T.38 relay or G.711 passthrough).
Independent per-leg negotiation is where a Back-to-Back User Agent (B2BUA) SBC architecture becomes important. A B2BUA terminates the SIP session on each leg independently. This means the SBC can handle a T.38 re-INVITE from one side and negotiate the appropriate fax mode on the other leg independently. A SIP proxy cannot do this; it merely forwards SIP messages without modifying them, which means both sides must agree on the same fax transport method.
Protocol conversion comes into play when one side speaks T.38 and the other does not. The SBC performs the demodulation/re-modulation function: it receives T.38 data from one leg, converts it to G.711 fax audio, and sends it out the other leg (or vice versa). This interoperability function is critical in multi-vendor environments where not all endpoints have the same capabilities.
SIP header normalization covers the differences in how SIP implementations format T.38 offers. The SBC normalizes the SDP (Session Description Protocol) attributes — T.38 version, maximum bit rate, fax rate management, error correction mode — so that both sides can agree on a common set of parameters even if they use different SDP formatting.
Reliability safeguards ensure that silence suppression, echo cancellation, and codec transcoding are disabled on fax call legs. When the SBC receives a T.38 re-INVITE, it applies the configured fax relay profile, which should have these safeguards already set.

How ProSBC Handles Fax over IP

ProSBC includes a dedicated Fax/Modem Relay feature set designed for exactly these scenarios. The configuration options include:
Enable Fax/Modem Relay activates fax relay handling on the relevant NAPs (Network Access Points).
Relay Mode: T.38 or Passthrough lets you choose T.38 relay or G.711 passthrough. When a T.38 re-INVITE arrives from a gateway, ProSBC applies the configured relay mode. T.38 is the recommended mode when both endpoints support it; passthrough is the fallback.
Prevent Direct Invite in T.38 controls whether ProSBC allows the initial INVITE to establish a T.38 session directly, or requires the call to start as audio and transition to T.38 after a re-INVITE. Some endpoints send a direct T.38 INVITE without starting in audio mode first; this setting controls how ProSBC handles that behavior.
Detection Type: Silence Suppression Off ensures silence suppression is disabled during fax relay, preventing the loss of fax signal during pauses.
When ProSBC receives T.38 from one side and passes it to the other as T.38, no transcoder hardware is needed — the SBC performs a T.38-to-T.38 relay. ProSBC’s B2BUA architecture means each call leg is handled independently, so T.38 negotiation on the carrier side does not have to match the configuration on the customer side. This is particularly useful when interconnecting a SIP trunk provider that insists on T.38 with a legacy PBX that only supports G.711 passthrough, or when routing fax traffic between carriers with different T.38 implementations.
ProSBC’s programmable Ruby routing engine also allows operators to apply custom logic to fax calls, for example, routing fax traffic to dedicated trunk groups optimized for fax, applying different quality-of-service policies to fax sessions, or logging fax call detail records separately for billing purposes.

Best Practices for Reliable FoIP Through Your SBC

Getting fax over IP working reliably comes down to eliminating the failure modes listed above. Here is a practical checklist:

• Use T.38 relay when both endpoints support it. T.38 handles network impairments far better than G.711 passthrough. Configure your SBC to offer T.38 by default and fall back to passthrough only when the other side rejects the T.38 re-INVITE.
• Disable silence suppression on fax trunks. VAD will kill fax sessions. Ensure it is disabled on every trunk group and NAP that carries fax traffic.
• Disable echo cancellation for fax calls. Your SBC should automatically disable echo cancellation when it detects fax tones. Verify this is happening by checking call traces.
• Use G.711 only — never a compressed codec. If using passthrough mode, the codec must be G.711 (PCMU or PCMA). If any device in the path transcodes to G.729 or another compressed codec, fax will fail. Configure your SBC to force G.711 on fax-designated trunk groups.
• Ensure SIP re-INVITEs can pass through firewalls. T.38 requires a mid-call SIP re-INVITE to switch media types. If your firewall or NAT device blocks re-INVITEs, the T.38 switchover will fail. Confirm your firewall rules allow re-INVITEs on the SIP signaling path.
• Test end-to-end before production. Send test faxes through the complete path — from the fax machine or server, through the SBC, across the SIP trunk, to the receiving endpoint. Test multi-page faxes, high-resolution faxes, and faxes during peak traffic periods.
• Have G.711 passthrough as a fallback. If T.38 negotiation fails, the SBC should fall back to G.711 passthrough gracefully rather than dropping the call.

Industries That Still Depend on Fax — and Why FoIP Matters

Fax persists because regulation and inertia keep it in place. Healthcare providers in the United States transmit patient records by fax because HIPAA recognizes fax (both analog and FoIP) as a compliant transmission method for protected health information (PHI). Legal firms fax court filings and signed documents where jurisdictions still accept or require them. Government agencies at all levels require faxed submissions for certain processes. Financial institutions use fax for loan documents, compliance reporting, and transaction confirmations.
For any service provider, MSP, or enterprise serving these industries, FoIP support is not a nice-to-have feature in your SBC; it is a requirement. A single failed fax in a healthcare or legal context can delay patient care, miss a court deadline, or cause a compliance violation.
The PSTN is sunsetting. Analog fax lines are disappearing. Every organization that depends on fax is moving to FoIP whether they planned to or not. The question is whether their voice network, and specifically their SBC, handles the transition correctly.

Frequently Asked Questions