We've spent over two decades building fax server software. Our parent company, iFAX Solutions, ships HylaFAX Enterprise to organizations that depend on fax at scale. We know what these systems can do when they're connected to infrastructure that respects T.30, the fax protocol.
So when a new customer tells us their fax server "doesn't work over SIP," we already know the shape of the story. Sometimes it's a RightFax or HylaFAX Enterprise installation that ran fine for years on POTS or PRI, migrated to a SIP trunk, and started failing. Sometimes it's a brand-new deployment, built on SIP from day one, with no legacy fax history to compare against. Either way, the pattern is the same: pages drop mid-transmission, calls connect but nothing comes through, and the SIP provider's advice is to lower the baud rate, turn off ECM, and try again.
The fax server was never the problem.
Three Things Voice Carriers Get Wrong About Fax
Most SIP trunk providers are voice companies. They built their networks for phone calls, added T.38 because customers asked for it, and moved on. When fax fails on their network, the troubleshooting advice reveals the gap: slow it down, disable features, hope for the best. That advice comes from a team that doesn't understand the fax protocol well enough to find the actual cause.
There are three specific ways this shows up.
1. No in-house T.38 stack
Most SIP providers don't run their own T.38 infrastructure. When your fax server initiates a T.38 session, your provider's network passes it upstream to a carrier they don't control. The T.38 conversion happens on hardware your provider has never tested against your fax server, operated by a company your provider might not even have a direct relationship with.
This is why fax failures are intermittent. It's not your configuration changing between calls. It's the carrier's routing. Different calls take different paths through different equipment with different T.38 implementations. Monday's fax works; Tuesday's identical fax to the same number fails. Your settings haven't changed. The upstream path has.
2. ECM disabled by default
Error Correction Mode (ECM) divides each fax page into frames, checksums each frame, and retransmits any frame that arrives corrupted. Without it, a page can arrive with garbled sections, missing lines, or half-blank areas, and neither the sender nor the recipient knows. The transmission completes, the confirmation page prints, and the content is wrong.
Most carriers disable ECM because it adds processing load to their switching equipment. Over 90% of T.38 calls across the industry proceed without it. The word "facsimile" means exact copy. Without ECM, you don't have one. We wrote about this in detail in ECM: T.38's Dirty Little Secret.
3. Fax-ignorant support
When you call your SIP provider about fax failures, you're talking to voice engineers. They know SIP, RTP, and codec negotiation for audio. What they don't know is T.30 fax negotiation, ECM partial-page retransmission, or why your 200-page fax fails consistently at page 47.
The advice to lower your baud rate or switch to G.711 pass-through isn't a diagnosis. It's a workaround that masks the real problem by degrading your fax quality. A support team that understands fax will never tell you to turn off ECM. They'll pull a call trace and show you exactly where the session failed and why.
Your Fax Server Isn't the Weak Link
OpenText RightFax, HylaFAX Enterprise, and GFI FaxMaker all use the Dialogic Brooktrout SR140 T.38 stack. SR140 is one of the most mature, most widely deployed T.38 implementations in the world. It's been embedded in fax server products for years, and it works. Over POTS, over PRI, and over properly implemented SIP trunks, these fax servers send and receive reliably at scale.
The fax server's T.38 implementation has been tested and refined across thousands of deployments. The weak link is the carrier between your fax server and the PSTN. When that carrier doesn't run its own T.38 stack, doesn't enable ECM, and can't produce a call trace when you report a failure, no amount of baud-rate adjustment will fix the underlying problem.
Three Questions to Ask Your SIP Provider
If you're evaluating a SIP trunk for a fax server deployment, or trying to figure out why your current one keeps failing, ask your provider these three questions. The answers will tell you whether they actually run T.38 or just pass it through.
Where does your T.38 conversion happen? If the answer involves "upstream carrier," "network partner," or "our wholesale provider," your fax traffic is being handed off to infrastructure your provider doesn't control. They can't diagnose failures on equipment they don't operate.
Is ECM enabled on your T.38 sessions? If the answer is no, or "we can enable it on request," or "we recommend disabling it for better performance," you're looking at a carrier that treats fax as a secondary use case. ECM exists because fax pages need to arrive intact. Disabling it is not an optimization.
Can you show me a T.38 call trace when I report a failure? A carrier that runs its own T.38 stack can produce a protocol-level trace showing exactly where a fax session failed, what was negotiated, and what went wrong. A carrier that passes T.38 upstream can't, because the failure happened on someone else's equipment.
What We Built and Why
T38Fax exists because we couldn't find a carrier to recommend to our own HylaFAX Enterprise customers. We tested every major SIP provider's T.38 implementation. Not a single one passed. So we built our own T.38 stack, placed our media gateways inside carrier networks, and went through Dialogic's interoperability testing process. T38Fax appears on Dialogic's list of recommended SIP trunks for SR140.
ECM is enabled on every call. Our support team diagnoses with protocol analysis, not guesswork. We have step-by-step configuration guides for RightFax and Dialogic SR140 in our knowledge base, written by people who've configured these systems in production.
If your fax server works fine until it hits your SIP trunk, the problem is solvable. See how Power-T.38 connects to enterprise fax servers, or start a 30-day free trial and test it against your own environment.