A fax server replaces the machine with software. It answers a call, negotiates with the sending device, receives the image data, and drops a PDF where you want it. Sending runs the same path backwards. Everything interesting happens in the negotiation, which is also where fax over an IP network usually goes wrong.
This is a technical explainer of what happens on a fax call and where a server fits, written from building ICTFax, an open source fax server built on FreeSWITCH.
What a fax call actually does
Fax is older than most of the software talking to it, and the protocol still shows its age in a useful way: it’s completely deterministic.
When a fax call connects, both ends run T.30, the protocol that governs the conversation. It goes like this:
- The receiving side announces itself with a tone and sends its capabilities: which resolutions it supports, which compression schemes, its maximum speed, and its station identifier.
- The sending side picks the best set both ends support and confirms.
- Both sides train, meaning they send a known pattern to test whether the line is good enough for the speed they agreed. If it fails, they drop to a slower speed and try again.
- Page data flows, compressed with one of the T.4 or T.6 schemes.
- After each page the receiver confirms it arrived intact. A bad page is re-sent.
- The sender signals the end and both sides hang up.
That per-page confirmation is why fax survives in healthcare and law. You don’t get a “probably delivered”. You get a page-by-page acknowledgement from the receiving device, with a timestamp and the remote station identifier. Email has no equivalent.
Why fax breaks on VoIP, and what fixes it
Every step above assumes the audio arrives complete and in order. On a traditional circuit it does. On a packet network it doesn’t.
Three things go wrong. Compression codecs designed for speech mangle fax tones, because they’re optimised to preserve what a human voice sounds like rather than exact frequencies. Jitter reorders packets so tones arrive out of sequence. And packet loss removes data entirely, which the fax protocol interprets as line noise, so it retrains, drops speed, and eventually gives up.
The symptom is distinctive: short faxes work, long ones fail partway, and failures look random. Teams often blame the far end for weeks.
There are two answers.
T.38 is the real one. Instead of carrying fax as audio, the gateway demodulates it back into the original digital data, sends that data over IP with redundancy, and re-modulates tones at the far end. Lost packets can be recovered, and ordinary jitter stops mattering. Any serious fax server speaks T.38 natively.
G.711 passthrough sends fax as uncompressed audio. It works on a controlled local network and fails across the public internet. Use it as a fallback when a carrier won’t do T.38, not as a design.
Practical implication: the first question when planning a fax server is not which software to run. It’s whether your SIP provider supports T.38 properly. Some claim support and implement it badly. Test with a ten-page document before committing.
Where the server software sits
A fax server is three layers, and understanding the split makes troubleshooting much easier.
The telephony layer handles SIP signalling, media, and T.38 negotiation. In ICTFax this is FreeSWITCH, which does the actual modem work through its fax modules. When a fax fails mid-transmission, this layer is almost always where the cause is.
The application layer decides what happens around the call: which account owns which number, where an inbound document is routed, when a failed send is retried, and what the audit trail records. In our stack that’s ICTCore, the communications framework ICTFax is built on.
The document layer converts between formats. Inbound fax data becomes TIFF, then usually PDF. Outbound PDFs and Word documents become the TIFF the fax protocol expects, at the right resolution and page size. Most “the fax arrived blank” problems live here, not in telephony.
Keeping those layers separate in your head saves hours. A page that transmits but arrives unreadable is a document layer problem. A page that never completes is a telephony one.
What a server gives you that a machine cannot
The obvious answer is no paper. The useful answers are these:
Faxing becomes programmable. Once sending is an HTTP call, the systems that generate documents can fax them without a person. That’s where the real labour saving is. Our fax REST API tutorial shows the actual calls.
Routing by number. Each DID can land in a different inbox, department queue, or folder. A physical machine has exactly one destination: the tray.
Email in both directions. Users send by emailing an address and receive PDFs in their inbox, with no new software to learn. The email to fax guide covers the setup.
Real records. Every transmission has a status, timing, page count, and the remote identifier, queryable rather than printed on a curling thermal roll.
Multi-tenancy. One installation can serve separate organisations with their own numbers, users, and billing, which is the difference between a departmental tool and a service you can resell.
Running it yourself
ICTFax is open source under GPL-3.0. The source is on GitHub, there’s an official Docker image that gets you running in one command, and the installation guide covers the manual route if you’d rather understand each piece.
What you need before starting: a server (a small cloud instance is plenty for departmental volume), a SIP trunk from a carrier that does T.38, and one DID to test with. The software is the quick part. Getting the carrier right is what takes the time.
A realistic first hour looks like: run the container, point it at your SIP credentials, send a fax to a number you control, then receive one. If both work, send a ten-page document in each direction. That last test catches the T.38 problems a single page hides.
FAQ
How does a fax server work in simple terms? It answers or places a phone call in software, runs the T.30 fax protocol against the device at the other end, and converts between fax image data and ordinary files like PDF. To the far end it’s indistinguishable from a fax machine.
Do I need special hardware? No. With a SIP trunk it’s software only. Analog fax cards exist for connecting physical lines, but if you’re building new, a SIP trunk with T.38 is simpler and cheaper.
Can a fax server talk to old fax machines? Yes, and that’s the normal case. The protocol negotiation handles the difference in capability, dropping to whatever speed and resolution both ends support.
What’s the difference between an internet fax service and a fax server? A service sends your documents through someone else’s infrastructure and bills per page. A server runs on your own machine, so documents never leave your control and cost doesn’t scale with volume. The service is easier to start, the server is cheaper and more private at volume.
Why does my fax fail on page four every time? Almost always a T.38 or packet loss problem. A short fax completes before the line quality matters; a long one doesn’t. Confirm T.38 is actually negotiated rather than assumed, and check for loss on the path to your carrier.
Is ICTFax really free? Yes. The community edition is the complete application under GPL-3.0, not a trial. Paid support and a commercial white label edition exist for teams that want them, but nothing in the fax path is held back.
If you want to skip the reading, the download page has the Docker image and the source, and the technologies page lists exactly what’s underneath.