Fax over IP is the name for carrying fax across data networks rather than analog telephone lines. It exists because the obvious approach, treating a fax call as an ordinary voice call and letting it travel like any other, does not work reliably, and the reasons it does not work are worth understanding before you buy anything that depends on it.
Why fax needed an answer of its own
A fax call is two machines exchanging data as sound. That data is precise: page image content, timing, and confirmations that depend on both ends staying in step.
Voice networks are not built for precision of that kind. They are built to make speech intelligible, and speech is extraordinarily tolerant. A listener does not notice a lost packet, a few milliseconds of jitter, or a codec that discards frequencies nobody uses. Every one of those tolerances is a corruption from a fax machine's point of view, and unlike a person it cannot infer what was meant.
The practical result is a familiar set of symptoms: transmissions that fail partway, pages that arrive with bands of noise, calls that connect and then drop, and a failure rate that rises with document length because there is more time for something to go wrong.
What T.38 does about it
ITU-T Recommendation T.38 sets out procedures for real-time Group 3 facsimile communication over IP networks. Rather than carrying the fax as audio and hoping, it takes the fax signaling and image data and carries it as data across the IP leg, handing it back to a normal fax conversation at each end.
The consequence is that the network can be imperfect without the fax being wrong. Redundancy and error correction can be applied to the data, because it is being treated as data. The far end still believes it is on an ordinary fax call, which is the point: nothing has to change at the machine that receives.
Two IETF registrations describe how T.38 is carried in practice. RFC 3362 registers the image/t38 MIME sub-type, and RFC 4612 registers audio/t38 for the real-time case. The existence of both is a small clue to the awkwardness of the problem: fax is neither quite an image transfer nor quite an audio stream, and it has been described as both.
What still goes wrong
T.38 removes a category of failure. It does not make fax over IP unconditional.
- Both ends have to support it. If a leg of the path falls back to passing audio, you are back to the original problem for that leg.
- Gateways vary. Implementations differ in how they handle re-invites, timing and error correction, and two conformant devices can still interoperate poorly.
- The far end is still a fax machine. Busy, out of paper, and answered by a human are all outcomes no protocol addresses.
- Long documents remain the stress case. More pages means more opportunity for a transient problem to interrupt a session.
What to ask, and of whom
If you are running fax over your own IP telephony, the questions belong to your carrier and your equipment: is T.38 supported end to end, what happens when it is not negotiated, and what does the fallback behavior look like.
If you are using a fax service, most of that moves out of your hands, which is much of the appeal. The service holds the relationship with the fax network and deals with negotiation, fallback and retry. The questions that remain yours are about evidence rather than protocol: what the service reports when a transmission fails, whether that report distinguishes a busy destination from a network problem, and whether you can get at it programmatically.
That distinction is not pedantic. A failure you can classify is a failure you can act on: a busy number wants a retry, a wrong number wants a person, and a persistent protocol failure wants somebody to call the carrier.
Where this sits relative to the alternative
T.38 is not the only way fax crosses an IP network. The other approach passes the call through as ordinary voice audio using a codec, usually G.711, and hopes the network is good enough. There are circumstances where that is a reasonable choice and circumstances where it is wishful, and the difference is worth understanding before you inherit someone's configuration. We compare them in T.38 versus G.711 for fax over IP.
A note on what "supports T.38" means
The phrase appears on a great many datasheets and covers a wide range of realities. A device may support T.38 and still negotiate it only under conditions you do not have. A carrier may support it on some routes and not others. A path may involve several hops, and it is the weakest one that decides the outcome.
This is why testing beats reading. Send real documents, of realistic length, to the destinations you actually deal with, at the times of day you actually send. A protocol conformance claim is a statement about a device; what you need is a statement about a path.
Where to go next
For the mechanics underneath all of this, see how electronic fax works. For what a service does with it, the feature overview is the short version. If you are weighing an IP telephony migration against moving fax to a service entirely, tell us what you are working with.
The migration trap
The most common way organizations discover all of this is by migrating telephony first and finding out about fax afterwards. Analog lines are retired as part of a voice project, fax is assumed to come along, and the failures start arriving in ones and twos: a partner who says they never received something, a transmission that used to work and now does not, a machine that has begun producing pages of noise.
The failures are hard to attribute because they are intermittent and because fax was working the week before. If you are planning a voice migration, treat fax as its own workstream with its own testing, or decide deliberately to move it off the line estate entirely.
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.
- RFC 4612, Real-Time Facsimile (T.38) audio/t38 MIME Sub-type Registration.