By Sarah Martinez · Published April 23, 2026 · Updated June 8, 2026 · 14 min read
Quick Summary: T.38 is the ITU-T standard for real-time fax over IP. It converts T.30 fax tones into UDP packets with built-in redundancy, handles up to 10%+ packet loss, and requires both endpoints to negotiate support via SIP re-INVITE. For a shorter overview, see our T.38 fax protocol introduction. For everything — including UDPTL, redundancy settings, ECM, and a full troubleshooting checklist — read on.
The T.38 protocol has been around since 1998, yet it remains one of the most misunderstood pieces of enterprise telephony. IT administrators encounter it when fax breaks on a new VoIP deployment. Telecom engineers debate its settings in forum threads. Network teams spend hours chasing down why a perfectly healthy IP network is killing every fax.
This guide covers the T.38 protocol from the ground up — its history, how it works at the packet level, the SIP negotiation that enables it, redundancy and error correction settings, a three-way protocol comparison, configuration best practices, and a thorough troubleshooting checklist.
If you manage VoIP infrastructure or troubleshoot fax failures, this is the reference you need.
Just Need to Send a Fax?
If you don't manage VoIP infrastructure and just need faxes to work reliably, mFax.to handles all protocol negotiation for you. Upload a document, enter a fax number, send. No T.38 setup required — 98% delivery rate.
What Is the T.38 Protocol?
T.38 is an ITU-T recommendation that defines procedures for real-time Group 3 fax communication over IP networks. Published by the International Telecommunication Union in 1998 (as ITU-T T.38) and updated through several revisions since, it remains the primary standard for making fax work reliably on VoIP infrastructure.
The problem T.38 solves is fundamental: traditional fax uses the T.30 protocol, which was designed for the analog Public Switched Telephone Network (PSTN). T.30 depends on a continuous, high-fidelity audio channel with minimal latency, zero compression, and virtually no packet loss. IP networks provide none of these guarantees. They were built for voice and data, not the precise millisecond-level timing that fax requires.
T.38 bridges this gap by acting as a translation layer. Instead of sending fax as audio over IP (which breaks under normal network conditions), T.38 decodes the fax signal at a gateway, converts it into fax-specific IP packets with built-in error recovery, and reassembles it into analog fax tones at the destination.
Core technical facts:
| Property | Value |
|---|---|
| Standard | ITU-T T.38 (first published 1998) |
| Full name | Procedures for real-time Group 3 facsimile communication over IP networks |
| Transport | UDPTL (preferred) or TCP |
| Call setup | SIP (most common) or H.323 |
| Bandwidth | ~64 Kbps per direction (128 Kbps total) |
| Packet loss tolerance | Up to 10%+ with full redundancy |
| Fax standard supported | Group 3 (T.30) only |
| Real-time | Yes — as opposed to T.37 store-and-forward |
Brief History: Why T.38 Was Created
In the mid-1990s, organizations began migrating voice infrastructure to VoIP to reduce costs. Fax machines stayed. The first attempts to run fax over VoIP used G.711 passthrough — simply treating fax tones as uncompressed audio. It worked on pristine networks but failed routinely on anything less.
The ITU-T Study Group 8 recognized this as a systemic problem and developed T.38 as a dedicated fax relay protocol. The first version published in 1998 defined the core relay mechanism. Subsequent revisions added:
- 1998 (v1) — Core UDPTL-based relay, redundancy model
- 2000 (v2) — Enhanced error correction, gateway interoperability improvements
- 2004 (v3) — SIP/SDP negotiation refinements, ECM support over IP
- 2010+ (v4+) — Ongoing maintenance, modern VoIP alignment
Today, T.38 is supported by virtually every business-grade VoIP platform: Cisco UCM, Asterisk/FreePBX, 3CX, Avaya, and most SIP trunk providers — though support depth and quality vary significantly.
How T.38 Works: The Technical Architecture
The Core Problem T.38 Solves
Traditional fax (T.30) works like this: a sending fax machine emits a series of audio-frequency tones over the phone line. These tones encode the fax page data, control signals, and handshake commands. The receiving machine listens for these tones and decodes them.
IP networks introduce three problems that destroy this process:
- Packet loss — IP packets occasionally disappear. Even 1% loss corrupts the continuous audio stream fax depends on.
- Jitter — Packets arrive with variable timing. Fax machines expect constant audio; gaps cause timing failures.
- Codec compression — VoIP codecs like G.729 compress audio by removing "unnecessary" frequencies. Fax tones look like noise to a codec, so they get mangled.
T.38 solves all three by abandoning the audio approach entirely.
The T.38 Relay Process
Fax Call Is Initiated
The sending fax machine dials the destination number through a VoIP ATA or PBX. The call is set up as a standard voice call using SIP. At this point, the fax machine has no knowledge of IP — it is generating normal T.30 tones.
Gateway Detects Fax Tones (CNG Detection)
The T.38-capable gateway (ATA, PBX, or media server) detects the CNG (Calling Tone) signal — a 1100 Hz tone that fax machines send during the initial handshake. This triggers the T.38 switchover mechanism.
SIP Re-INVITE Negotiates T.38
The detecting gateway sends a SIP re-INVITE message to switch the media session from voice (RTP/G.711) to fax (T.38/UDPTL). The remote gateway accepts with a 200 OK if it supports T.38. If it rejects with a 488 (Not Acceptable Here), the call falls back to audio passthrough.
T.38 Gateway Decodes T.30 Signals
Once T.38 is active, the sending gateway intercepts all T.30 fax tones and decodes them — extracting the actual fax commands and page data rather than treating them as audio. This demodulation is the critical step that separates T.38 relay from audio passthrough.
IFP Packets Are Transmitted via UDPTL
The decoded fax data is packaged into IFP (Internet Fax Protocol) packets and sent via UDPTL (UDP Transport Layer). Each packet includes redundant copies of previous packets to handle loss. The receiving gateway buffers incoming packets and reconstructs any that are missing.
T.38 Spoofing Hides Network Latency
Both gateways use a technique called spoofing: they generate artificial T.30 timing signals to keep the fax machines' protocol timers from expiring while packets traverse the IP network. Without spoofing, a fax machine would time out after 60–90 seconds of perceived silence.
Receiving Gateway Reconstructs and Delivers
The receiving T.38 gateway reassembles the IFP packets back into T.30 tones and delivers them to the destination fax machine or server. The fax machine receives what looks and sounds like a normal PSTN fax call.
UDPTL: T.38's Transport Layer
Why Not RTP?
RTP (Real-time Transport Protocol) is the standard transport for voice over IP. You might expect T.38 to use it — but T.38 uses UDPTL (UDP Transport Layer) instead, for two reasons:
- Smaller headers — UDPTL requires only a 2-byte header per packet. RTP's basic header is 12 bytes. At T.38 speeds with many small packets, this overhead adds up.
- Built-in redundancy — UDPTL has a native redundancy mechanism for handling packet loss. RTP has no such mechanism.
TCP is also defined in the T.38 specification as an alternative transport, but is rarely used in practice. TCP's retransmission behavior introduces variable delays that break fax timing requirements.
UDPTL Packet Structure
A UDPTL packet carries three components:
- Sequence number (2 bytes) — identifies the packet's position in the stream
- Primary payload — the current IFP data (fax commands or page data)
- Error recovery data — redundant copies of previous packets, or FEC (Forward Error Correction) data
The redundancy model works like this: if redundancy level is set to 2, each packet contains the current payload plus the payloads of the 2 previous packets. The receiver can reconstruct any single packet from the following packet alone.
Redundancy Settings
T.38 supports two types of redundancy:
| Type | What It Covers | Typical Setting |
|---|---|---|
| Control redundancy | Fax control commands (handshake, speed negotiation) | 2–3 (controls are small, redundancy is cheap) |
| Data redundancy | Fax image data packets | 1–2 (data packets are larger; higher redundancy = more bandwidth) |
General guidance:
- Set control redundancy to 3 on networks with any packet loss
- Set data redundancy to 1 on good networks, 2 on poor ones
- Higher values increase bandwidth consumption proportionally — at redundancy 2 with data, you're sending 3× the data payload
Matching Redundancy Levels Matters
Both gateways must use compatible redundancy settings. Mismatched levels cause decode errors. When troubleshooting, explicitly set both sides to the same value rather than relying on defaults.
The SIP Re-INVITE Mechanism
What Is a SIP Re-INVITE?
A SIP re-INVITE is a second SIP INVITE sent mid-call to modify the parameters of an existing session. In the context of T.38, it is used to switch the media session from voice mode (RTP/G.711) to fax mode (T.38/UDPTL) after fax tones are detected.
The negotiation follows this sequence:
- Initial call — established as G.711 voice (SDP contains only RTP/G.711 offer)
- CNG detection — fax tone detected by the gateway
- Re-INVITE sent — SDP offer updated to include
udptl t38media description - Remote gateway responds — either accepts (200 OK with T.38 SDP) or rejects (488)
- Media switches — both sides switch to UDPTL transport for fax data
- Fax transmits — page data flows as T.38 IFP packets
- Re-INVITE back to voice — after fax completes, another re-INVITE may return the call to voice mode
Why Re-INVITE Fails
The SIP re-INVITE is the single most common failure point in T.38 deployments. Common causes:
- SBC blocking re-INVITEs — Session Border Controllers may strip or reject mid-call re-INVITEs for security reasons
- NAT traversal issues — the re-INVITE may carry the wrong IP address in the SDP Contact header after NAT
- Firewall blocking UDPTL ports — once T.38 is negotiated, media flows on different ports that may be blocked
- Provider-side rejection (488) — the upstream SIP provider does not support T.38 on that trunk
Diagnostic approach: Enable SIP trace logging on your PBX or ATA. Look for the re-INVITE and its response. A 488 means the far end doesn't support T.38. A 5xx means a proxy or SBC is rejecting it. No response at all usually means a firewall or NAT problem.
T.38 vs. G.711 Passthrough vs. T.37 Store-and-Forward
These are the three main methods for sending fax over IP networks. Understanding all three is essential for choosing the right architecture.
| Feature | T.38 Fax Relay | G.711 Passthrough | T.37 Store-and-Forward |
|---|---|---|---|
| Mechanism | Decodes T.30 → IFP packets → re-encodes | Passes fax audio as uncompressed RTP | Converts fax to email attachment (TIFF) |
| Real-time | Yes | Yes | No |
| Packet loss tolerance | 10%+ with redundancy | <1% | N/A (store-and-forward) |
| Jitter tolerance | High (spoofing handles timing) | Low (depends on network quality) | N/A |
| Bandwidth | ~64 Kbps | 64 Kbps (no compression) | Low (delivery over SMTP) |
| Both ends required | T.38-capable gateways | G.711 codec only | T.37 email gateway |
| Delivery confirmation | Per-session (T.30 ECM) | Per-session | Email delivery receipt |
| Interoperability | Wide (all major VoIP platforms) | Universal (all VoIP systems) | Limited (email-to-fax use case) |
| Setup complexity | High | Low | Medium |
| When to use | Fax on VoIP with any packet loss | Pristine LAN-only networks | Store-and-forward, non-real-time |
T.37 (Store-and-Forward): A Brief Note
T.37 is the ITU-T standard for non-real-time fax over IP — essentially converting the fax into an email attachment (TIFF format) and delivering it via SMTP. It is not a real-time protocol and is rarely used in enterprise environments today. Cloud fax services use T.37-like store-and-forward models internally, though they abstract this entirely from the user.
For more on the VoIP fax problems that led to these protocols, see our in-depth troubleshooting guide.
Error Correction Mode (ECM) Over T.38
What Is ECM?
Error Correction Mode (ECM) is a feature of the T.30 fax protocol that adds checksums and retransmission to each page of data transmitted. When ECM is enabled:
- The page is split into 256-byte frames
- Each frame has a CRC checksum
- The receiving machine requests retransmission of any corrupted frames
- The page is only accepted when all frames are verified
ECM was designed for the analog PSTN world, where line noise could corrupt individual portions of a page. Over T.38, the situation is more nuanced.
ECM Over T.38: Recommendations
| Scenario | Recommendation |
|---|---|
| Reliable T.38 network, both ends support ECM | Enable ECM — it adds error checking with minimal overhead |
| Network with >2% packet loss | Disable ECM — retransmission loops can exhaust T.30 timers and cause call failure |
| Provider explicitly disables ECM | Match the provider setting — mismatched ECM causes negotiation failures |
| High-stakes documents (healthcare, legal) | Enable ECM when the network supports it reliably |
ECM and Fax Speed
When ECM is enabled, the fax machine and gateway negotiate a compatible speed. Most T.38 deployments operate at 9600 bps for reliability. Forcing a lower speed (4800 bps) can reduce the impact of packet loss but increases transmission time.
Network Requirements for Reliable T.38
Minimum Network Conditions
T.38 tolerates packet loss better than G.711, but it has limits. These are the practical thresholds:
| Metric | Acceptable | T.38 Starts Struggling | Likely Failure |
|---|---|---|---|
| Packet loss | < 5% | 5–10% | > 15% |
| One-way latency | < 150 ms | 150–300 ms | > 400 ms |
| Jitter | < 30 ms | 30–80 ms | > 100 ms |
| Bandwidth per fax | 128 Kbps (both directions) | — | Contention causes loss |
QoS Recommendations
T.38 packets should be marked with QoS (Quality of Service) DSCP values to prevent them from competing with bulk traffic:
- Use DSCP EF (Expedited Forwarding / 46) for T.38 UDPTL traffic — same priority as voice
- Apply QoS markings on all network segments, not just the LAN edge
- Configure ingress/egress traffic shaping on links with bandwidth constraints
Firewall and NAT Considerations
T.38 requires specific ports to be open and properly forwarded:
- SIP signaling: UDP/TCP 5060 (or provider-specified port)
- UDPTL media: Usually UDP ports in the range 8000–65535 (configurable per PBX/ATA)
- Re-INVITE: Firewall must allow mid-call SIP re-INVITEs — many firewalls block these by default under SIP ALG
Disable SIP ALG
SIP ALG (Application Layer Gateway) on consumer routers and many enterprise firewalls actively interferes with T.38 re-INVITE by rewriting SDP headers incorrectly. Disable SIP ALG on any device between your fax equipment and the SIP provider.
T.38 Configuration: Key Settings Reference
The exact configuration location varies by platform (Asterisk, 3CX, Cisco, Grandstream, etc.), but these are the universal settings to verify:
| Setting | Recommended Value | Notes |
|---|---|---|
| T.38 enabled | Yes | Must be enabled at device, PBX, and provider levels |
| UDPTL enabled | Yes | Preferred over TCP for T.38 transport |
| ECM | Enabled (unless provider disables) | Reduces page errors on clean networks |
| Max datagram size | 176 bytes | Default for most equipment; larger values can fragment |
| LS-redundancy (low speed) | 3 | Redundancy for control packets |
| HS-redundancy (high speed) | 3 | Redundancy for data packets; reduce to 1–2 on fast, clean links |
| Fax speed | 9600 bps | Lower is more reliable; 14400 bps is usable on very clean links |
| Initial codec | G.711 a-law or u-law | Start voice call with G.711 before re-INVITE to T.38 |
| SIP re-INVITE | Allowed | Verify SBC and firewall permit mid-call re-INVITEs |
| DTMF mode | RFC 2833 | Keeps DTMF reliable during the voice phase of the call |
Asterisk-Specific Notes
In Asterisk (/etc/asterisk/sip.conf or PJSIP):
t38pt_udptl=yes,redundancy,maxdatagram=176
faxdetect=yes
Set t38pt_udptl to yes and include redundancy to enable error recovery. faxdetect=yes enables CNG tone detection to trigger the T.38 switchover automatically.
Common T.38 Problems and Solutions
Even with T.38 configured, failures happen. Here are the most common problems and their root causes.
Checklist: Before Calling Your Provider
Problem: Fax Connects but Pages Come Through Corrupted
Cause: Packet loss exceeding the redundancy buffer, or mismatched ECM settings.
Fix: Increase redundancy to 3 for both control and data. If the network has >5% loss, disable ECM — the retransmission loops will exhaust T.30 timers before finishing. Verify with a packet capture that UDPTL packets are arriving continuously without bursts of loss.
Problem: T.38 Re-INVITE Gets a 488 Response
Cause: The remote gateway (or SIP provider) doesn't support T.38 on that call path.
Fix: Confirm T.38 support with your provider. Ask specifically: "Does your network support T.38 end-to-end, including to PSTN breakout?" Partial support (only to the SIP trunk edge, not to the PSTN gateway) is a common source of 488s. If T.38 is unavailable, use G.711 passthrough only on a very clean, low-latency network.
Problem: Fax Works Internally but Fails on External Numbers
Cause: The SIP trunk provider's PSTN gateway does not support T.38. Internal faxes go gateway-to-gateway (T.38 supported); external calls break out to PSTN through a gateway that may use G.711 passthrough only.
Fix: Test with the provider's own fax test line. If T.38 fails only on external numbers, the issue is at the PSTN breakout point. Request T.38 all the way to the PSTN gateway or switch to a cloud fax service for external-facing fax.
Problem: SIP Re-INVITE Never Arrives at the Remote End
Cause: Firewall or SBC is blocking the re-INVITE. SIP ALG is rewriting the SDP.
Fix: Enable SIP debug logging, capture a SIP trace, and check whether the re-INVITE is sent and received. If SIP ALG is present, disable it. If an SBC is in the path, verify it is configured to pass T.38 re-INVITEs rather than terminate them.
Problem: One-Page Faxes Work, Multi-Page Faxes Fail
Cause: Page-level error recovery (ECM) is timing out on longer transmissions, or bandwidth is insufficient for sustained T.38 traffic.
Fix: Check available bandwidth during a fax call — T.38 uses ~128 Kbps bidirectionally for the duration of the transmission. On constrained links, QoS prioritization is essential. Also verify ECM retransmission settings; on long faxes, the T.30 retransmission timer (90 seconds) may expire before all bad frames are resent.
For a broader view of why VoIP fax fails and how to diagnose it, see the VoIP fax problems guide.
T.38 vs. Cloud Fax: Choosing the Right Architecture
T.38 solves a real problem — but it solves it by adding infrastructure complexity. Before committing to a T.38 deployment, consider whether cloud fax is the simpler answer for your use case.
| Factor | T.38 on VoIP | Cloud Fax (mFax) |
|---|---|---|
| Reliability | 85–95% when configured correctly | 98% |
| Setup | ATA/PBX + provider + firewall config | Sign up and send |
| Physical fax machines | Supported (via ATA) | Not required |
| Send from mobile | No | Yes |
| PSTN breakout T.38 | Requires provider support | Handled by cloud provider |
| Ongoing maintenance | Regular — settings drift, providers change | None |
| HIPAA compliance | Depends on provider/configuration | Available with mFax Business |
| Cost | VoIP plan + ATA hardware | Per-fax or subscription |
When T.38 Is the Right Choice
- You have physical fax machines on a VoIP phone system that cannot be replaced
- You are managing a PBX (Asterisk, 3CX, Cisco) and need to integrate fax with your existing phone infrastructure
- Your SIP trunk provider and destination fax endpoints both reliably support T.38 end-to-end
- You have IT resources to configure and maintain the deployment
When Cloud Fax Is the Right Choice
- You need high reliability (98%+) without managing protocol configuration
- You fax from phones, computers, or tablets — not fax machines
- Your VoIP provider has unreliable T.38 support
- You want HIPAA-compliant fax without building your own compliance infrastructure
mFax Bypasses the T.38 Problem Entirely
mFax.to routes faxes through dedicated fax infrastructure — not your VoIP system. T.38, G.711, and SIP re-INVITE are problems you never have to solve. Upload a document, enter a fax number, receive a delivery confirmation.
For an overview of how cloud fax handles the protocol layer, see our cloud fax guide.
Frequently Asked Questions
For quick answers to common T.38 questions, see the FAQ section above. For questions not covered here, the T.38 fax protocol overview and VoIP fax troubleshooting guide cover the most frequent deployment scenarios.
Send Faxes Without the Protocol Headache
T.38 is a well-designed protocol for a hard problem. If you run VoIP infrastructure with legacy fax machines, it is the best available tool. But "best available" in the T.38 world still means careful configuration, provider vetting, SBC rules, firewall settings, and ongoing troubleshooting.
For most organizations today — especially those who have moved workflows to mobile and cloud — cloud fax is the pragmatic choice.
mFax.to delivers faxes with a 98% success rate, from any device, with delivery confirmation — no VoIP configuration, no T.38 debugging, no fax machines needed.
For business teams, mFax Business adds virtual fax numbers, HIPAA-ready infrastructure, team accounts, and a shared dashboard starting at about $9/mo (billed annually). Pricing is fully customizable — instead of fixed tiers, you build your own plan with a live calculator, choosing the exact number of seats and pages you need and paying only for what you use. Everything T.38 was meant to provide, minus the configuration overhead.