Fax is one of the few technologies where the thing at the far end has genuinely not changed. A machine built in 1995 will still answer a call placed today, and that backwards compatibility is the whole reason fax has outlived so many replacements. What has changed is everything on the near side of the call.
What a fax actually is
A fax is not a document in the sense a word processor means. It is an image of a page, encoded as a run of black and white, transmitted as sound over a voice call, and reassembled as an image at the other end. There is no text in it, no formatting, and nothing a receiving system can parse without doing optical character recognition afterwards.
That is worth internalizing, because it explains most of fax's characteristics. It is why a fax of a form is not searchable. It is why quality depends on the line. And it is why fax has an unusually strong delivery signal: the two machines talk to each other, page by page, and the sending end knows whether the receiving end acknowledged.
The call, step by step
Strip away the modern parts and the sequence is unchanged.
- The sending end places a call to the destination number.
- The receiving end answers and identifies itself as a fax machine.
- The two negotiate: what resolution, what encoding, how fast a line they can both manage.
- Page image data is sent, at the agreed rate.
- The receiving end confirms each page, or asks for a retransmission.
- The call ends, and the sending end records the result.
The negotiation matters more than it looks. Fax adapts to the line it finds, dropping speed when a connection is poor. That adaptability is why fax works over infrastructure that would defeat most protocols, and it is also why a transmission can succeed slowly rather than fail quickly.
What changed underneath
Almost none of that sequence assumes an analog telephone line, but all of it assumes the call carries the sounds faithfully. Once calls travel across data networks, that assumption stops holding on its own. Voice codecs are designed to make speech intelligible, and they take liberties that speech tolerates and fax data does not: dropped packets, timing jitter, and compression that discards what a listener would not miss.
The answer is a protocol written for the problem. ITU-T Recommendation T.38 sets out procedures for real-time Group 3 facsimile communication over IP networks, and it works by carrying the fax signaling and image data as data rather than as audio, reassembling it at the far end. Two IETF registrations define how it is carried in practice: RFC 3362 registers the image/t38 MIME sub-type, and RFC 4612 registers audio/t38. We look at the alternative in T.38 versus G.711.
Why a fax takes as long as it does
People are often surprised that a fax is not instant, and the reason is in the sequence above. The call has to be placed and answered. The two ends have to agree terms. Each page is then transmitted at whatever rate the line supports and confirmed before the next one starts. A ten page document is ten of those cycles, not one transfer.
That is also why a busy destination is such a common outcome. A fax machine handles one call at a time, so a department with one number and a steady inbound flow will refuse calls for long stretches of the working day. Retrying is not a workaround; it is the normal operating mode, and it is one of the things worth automating rather than leaving to whoever noticed the failed slip.
Where a service sits in that chain
An electronic fax service does not change the far end and does not change the protocol. What it changes is where the near end lives.
Instead of a machine on your premises holding a line, the service holds the connection to the fax network and you reach it over the internet: by email, by an inbound number, or by an application calling an API. The negotiation, the retries, the page confirmations and the result all still happen; they just happen somewhere you do not have to maintain.
What you gain is not a better fax. It is a better record of one. A machine printed a confirmation slip that somebody filed or did not. A service records a transmission with an identity, an origin, a destination, a time and an outcome, and can hand that back to whatever asked for it.
What this means in practice
Three consequences follow from the mechanics, and they explain most of what people find surprising.
- Delivery confirmation is real but narrow. It tells you a receiving machine acknowledged the pages. It does not tell you a person read them, or that the number belonged to who you thought.
- A wrong number fails silently and successfully. The transmission works perfectly; it simply arrives somewhere else. No protocol can catch that, which is why destination verification is a workflow control rather than a feature.
- Quality is negotiated, not fixed. A poor connection produces a slow, low-resolution success rather than a clean failure.
Why it has not been replaced
Every few years something is announced as the end of fax, and fax continues. The reason is not affection for the technology. It is that fax is the only document channel that a very large number of organizations have already agreed on, that needs no account, no onboarding and no shared platform, and that produces a delivery acknowledgment both sides accept. A portal is better in every respect except the one that matters, which is that the other organization has to agree to use it.
Where to go next
If the terminology is the unfamiliar part, what electronic fax is covers the ground plainly, and fax over IP goes deeper into the transport. For what the LABUSA service does with all this, see how it works, or tell us what you are working with.
Sources
- ITU-T Recommendation T.38. Procedures for real-time Group 3 facsimile communication over IP networks, in force at edition 11/15.
- RFC 3362, Real-time Facsimile (T.38) image/t38 MIME Sub-type Registration.