🏆 2026 MSP 501 Winner — Two Years Running — Ranked among the world’s top managed service providers. Learn more

Back to Blog

Stop Fax Over IP Failures Caused by About 2% Packet Loss for IT Teams

California Telecom TeamCalifornia Telecom editorial team
Stop Fax Over IP Failures Caused by About 2% Packet Loss for IT Teams

Stop Fax Over IP Failures Caused by About 2% Packet Loss for IT TeamsMost failed fax over IP sessions trace back to two causes: packet loss or jitter on the network path, or a failed protocol handoff between G.711 and T.38. Confirm which one you're dealing with by pulling call logs and packet metrics, then force G.711 passthrough as an isolation test. If failures repeat despite clean network numbers, the fix may sit outside your network team's reach and point toward managed remediation or cloud fax.

TL;DR:

  • Fax failures over IP are often caused by packet loss exceeding 2% with ECM enabled or by network jitter over 30 milliseconds, degrading fax signaling.
  • Successful T.38 negotiation requires correct SDP capability advertising and matching T.38 versions; failures often result from unsupported or mismatched protocol parameters.
  • Managed services and cloud fax options are recommended when persistent or complex network issues prevent reliable FoIP operation or compliance requirements demand it.

Table of Contents

How Fax Over IP Works: T.30, T.38, and Voice-First Call Setup

Every fax over IP call starts life as a voice call. A SIP INVITE goes out with a standard audio codec offer, usually G.711, and the call connects like any other voice session before either endpoint knows a fax machine is on the line. Only after the two fax machines begin exchanging their T.30 signaling tones does either gateway realize it's handling a fax and attempt to switch the media path to a fax-aware mode. That switchover is the single most fragile moment in the entire call.

T.30 is the original ITU standard for Group 3 fax signaling: it governs the tones and handshakes fax machines use to identify each other, negotiate speed, and confirm page transfer. T.30 doesn't know anything about IP networks; it assumes a clean analog circuit. T.38 is what makes T.30 signaling survive a packet network. It repackages the fax tones into discrete, redundant packets instead of relying on the continuous audio stream that voice codecs expect, which makes it far more tolerant of the jitter and loss that would otherwise scramble the tones.

Those T.38 packets travel over UDPTL, a transport protocol built specifically for this purpose, though some gateways support TCP as a fallback. The alternative, when T.38 negotiation fails or isn't attempted, is G.711 passthrough: the call simply stays in voice mode and the fax tones ride inside the audio stream as if they were speech. It works, but only when the network path is close to pristine.

The mid-call switch from voice to T.38 depends on SIP re-INVITE or UPDATE messages carrying new SDP (Session Description Protocol) attributes that advertise the T.38 media type. If a gateway, session border controller, or ITSP doesn't recognize or pass through those SDP attributes, the switchover request goes nowhere, and the call is stuck trying to send fax tones over a codec never designed to carry them cleanly. Some vendor implementations track this exchange as a "RemoteConnectionDescriptor," a way of confirming what capability the far end actually advertised before committing to the switch. When that confirmation never arrives or arrives with mismatched parameters, the local gateway either times out, falls back to passthrough, or drops the call outright.

SIP voice call switching to T.38 fax relay

RFC 6913 addresses a related problem: how does a caller even know whether the far end supports T.38 before dialing? It defines the "sip.fax" media feature tag, letting a caller signal a preference for "t38" or "passthrough" so the call routes to a fax-capable endpoint from the start rather than negotiating blind mid-call. Advertising this tag, or checking peer capability with a SIP OPTIONS request before sending, cuts down on the failed mid-call attempts that account for a large share of fax transmission failures.

Root Causes: Network and Protocol Problems That Break FoIP

Fax over IP fails for a small number of recurring reasons, and almost all of them show up clearly once you know where to look.

Packet loss is the most common culprit, and its effect depends heavily on whether Error Correction Mode (ECM) is active. Cisco's own fax configuration guidance notes that fax transmissions on VoIP networks commonly fail once packet loss exceeds roughly 2% while ECM is enabled, because ECM triggers repeated retransmission attempts that eventually time out the session instead of recovering it. ECM was designed for lossy analog lines, not for packet networks where loss patterns behave differently, so it can make a marginal IP path worse rather than better.

Fax sessions over IP fail once packet loss exceeds about 2% with ECM active, which means a network that looks "good enough" for voice calls can still reliably break fax transmissions, according to Cisco's fax relay configuration documentation.

Root Causes: Network and Protocol Problems That Break FoIP — overview diagram

Jitter and latency tolerances differ sharply between the two transport modes. Cisco's VoIP fax guidance recommends jitter under 30 milliseconds and effectively zero packet loss for G.711 passthrough, with one-way delay kept under about 1,000 milliseconds. T.38 relaxes the jitter ceiling to roughly 300 milliseconds because its redundant UDPTL packets tolerate more timing variance, but it still needs packet loss close to zero unless redundancy is explicitly configured to compensate.

A short list of the failure modes worth checking first:

  • Codec mismatch or transcoding: any codec other than G.711, especially compressed codecs like G.729, distorts or drops the fax tones a passthrough call depends on, and transcoding between codecs mid-path almost always corrupts fax signaling.
  • NAT and firewall interference: UDPTL and RTP streams that traverse NAT without correct port handling can arrive with altered headers or get blocked outright, especially behind devices running SIP ALG.
  • Missing or mismatched T.38 capability: a gateway that never advertises image/t38 in its SDP, or advertises an incompatible T.38 version, will never successfully switch out of voice mode.
  • Non-T.38-capable ITSP trunks: some SIP trunk providers strip T.38 SDP attributes entirely, forcing every fax call into passthrough whether the network can support it or not.

Version mismatches deserve particular attention because they fail silently. Two gateways can both claim T.38 support and still fail to interoperate if one expects a different T38FaxVersion or datagram size than the other advertises, a scenario RFC 4612 addresses by defining the audio/t38 parameters, including rate management and maximum datagram size, that both ends need to agree on. When those parameters don't line up, calls often start the switchover and then stall mid-negotiation, which is a distinct symptom from a call that never attempts T.38 at all.

T.38 Relay vs. G.711 Passthrough: Choosing the Right Mode

T.38 and G.711 passthrough solve the same problem in different ways, and knowing when to force one over the other saves hours of guesswork.

T.38 was purpose-built for Group 3 fax over packet networks. It transports fax data over UDPTL, occasionally over TCP, and encodes each fax tone as a discrete packet rather than a continuous audio stream, which is what gives it tolerance for jitter and moderate loss that would otherwise destroy passthrough calls. The tradeoff is that both endpoints, and everything in between, must correctly negotiate T.38 capability mid-call. Any SBC, ITSP trunk, or gateway that drops the SDP attributes breaks the handoff before it starts.

G.711 passthrough skips negotiation entirely. The call never leaves voice mode, and the fax tones just ride the audio path as G.711-encoded sound. It's simple and universally supported, which makes it the default isolation test when T.38 won't switch over, but it needs a nearly clean path: near-zero packet loss and jitter under about 30 milliseconds, per Cisco's VoIP fax guidance. It also holds a full 64 kbps of bandwidth for the duration of the call, with no compression benefit.

A practical way to decide which mode fits a given path:

  • Choose T.38 when the path has any measurable jitter or loss, when both endpoints and the ITSP trunk reliably advertise T.38 capability, and when fax volume justifies the redundancy overhead.
  • Choose G.711 passthrough as a deliberate fallback on short, low-latency paths, or as a diagnostic step to confirm whether a failure is a negotiation problem versus a network-quality problem.
  • Force passthrough temporarily whenever T.38 negotiation keeps failing and you need business-critical faxes moving while you fix the underlying SDP or SBC issue.

ECM sits inside this decision too. It strengthens error recovery on lossy analog lines, but on an IP path already struggling with packet loss, ECM's retransmission behavior can turn a marginal call into a failed one, which is why Cisco's T.38 fax relay configuration guide lists disabling ECM as a standard troubleshooting step on lossy links. It's not a permanent fix, and Super Group 3 machines without passthrough support may need ECM left on, but it isolates whether ECM's retry behavior is what's actually breaking the session.

Step-by-Step Troubleshooting Checklist for FoIP Failures

Work through failures in a fixed order. Changing two variables at once turns a five-minute diagnosis into an afternoon of guessing.

  1. Confirm the baseline. Send the same document over a PSTN-only fax line if one is available, then reproduce the failure over the FoIP path with the same document to confirm it's not a source document or machine problem.
  2. Split the call into legs. Identify which call control protocol runs on each segment, SIP, H.323, or MGCP, since a failure on the PBX-to-gateway leg looks different from one on the gateway-to-ITSP leg.
  3. Collect the metrics that matter. Pull one-way delay, jitter, and packet loss for the exact call window, along with the codec negotiated in the SDP and whether a T.38 advert appeared at all.
  4. Run the Cisco debug commands for the platform in use. debug fax relay t30 all-level-1 shows the T.30 signaling exchange, show voice call summary confirms codec and call state, debug mgcp packets or debug sip messages exposes the signaling layer, debug voip rtp session named-event shows RTP event handling, and show voice dsp confirms DSP resource allocation, all per Cisco's fax relay troubleshooting guide.
  5. Run isolation tests one at a time: force G.711 passthrough first, then if that fails too, disable ECM, then try enabling T.38 UDP redundancy, then adjust playout-delay settings, testing with a simple one-page fax after each change.
  6. Read the T.30 training events in the debug output. A TCF (Training Check Field) failure means the receiving modem couldn't validate the training signal, usually a signal quality problem. A CFR (Confirmation to Receive) that never arrives means the far end rejected the proposed parameters. An FTT (Failure to Train) means the negotiated speed was too aggressive for the path. NSE (Named Signaling Event) messages that appear without a following successful switchover are a strong signal that T.38 negotiation started but never completed.

Pro Tip: Always test with a plain one-page fax during isolation steps. Multi-page or image-heavy documents introduce variables, like extended transmission time and larger TCF payloads, that can mask which specific change actually fixed or broke the call.

Cisco's own troubleshooting model for fax relay boils this down to three stages: split the call legs, identify the protocol running on each, and check the gateway's state and dial-peer matching. That third stage catches a problem easy to miss: dial-peers on either end of a gateway that don't agree on codec or T.38 settings will produce intermittent failures that look like network flakiness but are actually configuration drift.

If your environment includes SIP trunking, validating that trunk's behavior under load and failover conditions is worth doing before you blame the fax path specifically. A SIP trunk failover runbook gives a structured way to confirm the trunk itself is stable before layering fax-specific diagnostics on top.

Configuration and Network Changes That Improve FoIP Reliability

Once you've isolated the failure mode, the fixes usually fall into a handful of categories.

QoS and traffic prioritization. Fax traffic needs the same DSCP marking discipline as voice: EF (Expedited Forwarding) for the RTP or UDPTL stream, placed in a priority queue ahead of best-effort data, with policing configured so bursty data traffic can't starve it during a transmission. A network that handles voice calls cleanly can still let fax packets queue behind a large file transfer if fax traffic isn't explicitly marked and prioritized.

Codec policy. Standardize on G.711 for any leg where passthrough might be used, and avoid routing fax calls through G.729 or other compressed codecs entirely. Transcoding a fax call between codecs mid-path is one of the more reliable ways to corrupt the tones a receiving machine needs to lock onto.

  • Advertise T.38 explicitly in SDP using the image/t38 media type, and consider the sip.fax tag from RFC 6913 so upstream routing can favor fax-capable paths before the call even connects.
  • Pre-check peer capability with SIP OPTIONS rather than discovering mid-call that the far end can't negotiate T.38.
  • Choose strict or loose T.38 mode deliberately: strict mode avoids wasted switchover attempts when a peer's capability is unknown, while loose mode attempts T.38 opportunistically and falls back if it fails, a tradeoff worth setting per trunk rather than globally.

Buffer and redundancy tuning. Adjust jitter and playout buffers to absorb the timing variance your metrics show, and configure T.38 packet redundancy along with T38FaxMaxDatagram and T38FaxMaxBuffer parameters to match what both endpoints can actually handle, values documented in RFC 4612 and the base ITU-T T.38 recommendation.

Firewall and NAT rules. Open the specific UDPTL and RTP port ranges your gateway uses rather than a broad range, and disable SIP ALG on any firewall in the path unless you've confirmed it correctly rewrites fax-related SDP; ALG implementations frequently mishandle T.38 attributes even when they handle voice SDP correctly.

Pro Tip: If fax traffic shares a WAN path with video or bulk data, check for the same jitter and loss patterns documented in general jitter and latency troubleshooting; a fax fix that ignores the underlying network problem tends to resurface the next time link utilization spikes.

When to Move Beyond FoIP: Cloud Fax and Hybrid Options

Not every fax workload belongs on a self-managed FoIP path, especially once failure rates or compliance exposure make troubleshooting cycles too expensive to repeat.

  • Cloud-hosted fax removes protocol negotiation and PSTN interop entirely from your infrastructure. It's the more practical option for regulatory or compliance-heavy workloads, since fax remains common in healthcare and legal document exchange even as most other communication has moved elsewhere, and a cloud provider handles the T.38 or passthrough decision on the far end of the connection instead of your gateway.
  • Hybrid architecture keeps a local gateway for routine internal fax traffic while routing critical or high-volume sends through a cloud relay, with a POTS line kept as a fallback for the rare fax that absolutely must go out regardless of network conditions.
  • Managed FoIP services hand the ongoing diagnostic burden, carrier relationship management, and SLA enforcement to a provider with dedicated fax expertise, which matters most for organizations without staff who regularly read T.30 debug output.

For organizations handling protected health information over fax, the reliability question sits alongside a compliance one; HIPAA-ready VoIP guidance covers what regulated environments should require from any voice or fax path carrying patient data. The right choice generally comes down to volume, criticality, and how much internal expertise you have to keep feeding a self-managed gateway through repeated firmware and carrier changes.

Where Managed Remediation Fits When In-House Fixes Stall

When the isolation steps above don't resolve a persistent failure, the bottleneck is often outside a single gateway's configuration: a carrier-side T.38 mismatch, an SBC silently stripping SDP attributes, or a WAN path with intermittent loss that only shows up under load. Approaches to these cases start from the same root causes covered above, network quality and protocol negotiation, but apply them across a carrier-neutral footprint sourced from multiple providers and monitored by a 24/7 U.S.-based NOC, which shortens the loop between spotting a pattern and getting a carrier to fix their side of it.

A typical engagement runs through diagnostics on the reported failure, QoS remediation where packet loss or jitter is the driver, SIP trunk validation against the dial-peer configuration on both ends, and, where a gateway simply can't be made reliable, a controlled migration to a managed fax service instead of continued patchwork fixes.

Before reaching out to any provider, gather the same evidence a good in-house diagnosis needs anyway: sample logs from failed calls, one-way delay and packet loss figures for the affected window, and a topology diagram showing where the fax traffic enters and leaves your network.

When I Escalate to Managed Services Instead of Continuing In-House

A few thresholds tell me it's time to stop troubleshooting internally: the same failure recurring across multiple carriers or sites, a fax workload tied to a regulatory deadline, or a team without anyone comfortable reading T.30 debug output under time pressure. None of those are failures on the IT team's part, they're just signals that the return on further internal diagnosis is dropping.

When handing off to a managed provider, bring the failed call logs, the dial-peer configurations on both legs, any SIP trace you've captured, and a topology diagram with traffic profiles. That package turns a multi-day diagnostic cycle into a same-day root cause conversation.

The cost-versus-uptime tradeoff is straightforward: a managed SLA costs more than free internal labor until you count the hours lost chasing a carrier-side issue no dial-peer change will ever fix.

— Jim

How California Telecom Can Help With Persistent Fax Failures

If your fax failures trace back to WAN packet loss, jitter, or SIP trunk instability rather than a one-off configuration error, that's exactly where Managed SD-WAN, UCaaS, Managed LAN/WAN, and Cloud Faxing through CTFAX address the root causes covered throughout this piece: unstable multi-site connectivity, unreliable trunk behavior, and the ongoing burden of maintaining gateway compatibility across carriers.Before reaching out, pull together a sample of a failed call log, your network topology, and any recent debug output you've collected. That's enough for an engineer to start narrowing down whether the fix is a network change, a trunk configuration, or a move to managed fax entirely. Start with a free consultation to walk through what you've found.

Standards and Vendor Documentation Worth Bookmarking

For exact parameter syntax, ITU-T Recommendation T.38 remains the base reference for values like T38FaxMaxBuffer and T38FaxMaxDatagram. RFC 4612 and RFC 5347 cover the audio/t38 transport mapping and gateway procedures, while RFC 6913 defines the sip.fax feature tag for capability signaling.

For debug command syntax and real troubleshooting sequences, Cisco's fax relay troubleshooting guide and T.38 fax relay configuration guide walk through the exact commands referenced in this article.

Sources

FAQ

Can you send a fax over VoIP?

Yes, fax over IP works using either T.38 relay or G.711 passthrough, though success depends heavily on network quality and whether both endpoints correctly negotiate the same protocol. A path with jitter under 30 milliseconds and effectively zero packet loss will reliably support either mode; a noisier path often needs T.38 specifically.

Do people still use fax in 2026?

Fax remains common in healthcare, legal, and government workflows where document exchange formats and compliance requirements haven't shifted away from it. Many organizations now handle that volume through cloud fax services rather than physical machines, which sidesteps most of the protocol negotiation issues covered above.

Why is the fax failing to send?

The most frequent causes are packet loss or jitter exceeding the thresholds fax transmission needs, or a failed T.38 negotiation that leaves the call stuck in an unsuitable voice codec. Checking call logs for T.30 training events like TCF, CFR, and FTT usually pinpoints which phase of the call broke down, per Cisco's fax relay troubleshooting documentation.

Which fax machines can work with VoIP?

Standard Group 3 fax machines work over VoIP through T.38 relay or G.711 passthrough, provided the gateway and ITSP trunk support the same protocol. Super Group 3 (SG3) machines can pose additional compatibility challenges since some of their higher-speed features assume passthrough rather than T.38 relay.

Recommended

Ready to Get Started?

Talk to our team about how California Telecom can help your business with enterprise-grade solutions.

Get a Free Network Assessment