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 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.

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 does not reach the other side or is rejected. 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

Fax tone detection allows the SBC to relay T.38 re-INVITEs from gateways, enabling protocol conversion when needed.
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 negotiate T.38 with the carrier on one leg and G.711 passthrough with the customer’s PBX on the other, bridging the two transparently. 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.
Relay, not conversion describes the SBC’s role: it relays fax traffic in whatever mode is configured on each leg, but does not convert between T.38 and G.711. Both sides must be configured for the same method (either both T.38 or both G.711 passthrough). If endpoints do not have matching capabilities, the SBC configuration should route them to the appropriate trunk group or apply different settings per leg, but the gateways at each end handle the actual demodulation and re-modulation.
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 enable automatic fax-safe handling. When configured for G.711 passthrough, a well-designed SBC automatically applies a complete fax-safe profile: G.711 codec, echo cancellation off, static jitter buffer, no packet loss concealment, and silence suppression disabled.

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 detection and relay handling on the relevant NAPs (Network Access Points).
Relay Mode: T.38 or Passthrough lets you choose T.38 relay (demodulate-transmit-remodulate) or passthrough (G.711 end-to-end). T.38 is the recommended mode when both endpoints support it.
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 only after fax tone detection. Some endpoints send a direct T.38 INVITE without starting in audio mode first; this setting controls how ProSBC handles that behavior.
G.711 Passthrough Mode causes ProSBC to automatically apply a full set of fax-safe audio handling when passthrough is selected: G.711 codec, echo cancellation disabled, static jitter buffer size, and no packet loss concealment. This is not just silence suppression; it is a complete passthrough profile optimized for fax reliability.

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.
• Confirm your SBC handles passthrough correctly. A well-designed SBC like ProSBC automatically applies fax-safe settings when passthrough mode is configured: G.711 codec, echo cancellation off, static jitter buffer, no packet loss concealment, and silence suppression disabled. You should not need to configure these individually.
• 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