If you run fax over an IP network, or you are being sold something that does, you will meet these two names. They are not competing standards in the way the pairing suggests. One was written for fax and the other was written for voice, and the choice between them is really a choice about whether to translate fax or to carry it as sound and hope.
The short answer
T.38 is the protocol designed for the job. G.711 is a voice codec that is sometimes used to pass a fax call through unchanged. Where both are available, T.38 is the more robust choice for fax. Where a path is short, clean and under one operator's control, G.711 pass-through can work well and is simpler to arrange.
What G.711 actually is
G.711 is the ITU-T Recommendation for pulse code modulation of voice frequencies. It is old, it is ubiquitous, and it is deliberately simple: it digitizes audio without clever compression, which is exactly why it is the one people reach for when a call has to survive intact.
Using it for fax is called pass-through. The fax machines behave as though they are on a normal call, their tones are digitized and carried like any other audio, and nothing in the middle knows a fax is happening. Nothing has to be configured to understand fax, because nothing does.
Its weakness follows directly. Because the network is carrying sound rather than data, everything that degrades sound degrades the fax. Lost packets are lost signal. Jitter shifts the timing the machines rely on. And because nothing in the path knows what is being carried, nothing can apply error correction that understands the content.
What T.38 does differently
T.38 sets out procedures for real-time Group 3 facsimile communication over IP networks. Instead of carrying audio, the gateway at each end participates: it terminates the fax conversation, extracts the signaling and image data, carries that across the IP leg as data, and reconstructs a fax conversation at the far side.
Because the IP leg is carrying data, it can be protected as data. Redundancy can be added, errors can be corrected, and a lost packet need not be a lost page. The fax machines at either end are unaware of any of it.
Where each one is used
- T.38 where the path crosses a network you do not control, where documents are long, where the far end is arbitrary, and where a failed transmission has a cost.
- G.711 pass-through where the path is short and well-managed, where the volumes are small, or where a device in the chain does not implement T.38 and adding one is not worth it.
In practice many deployments end up with both, because negotiation falls back. A call may attempt T.38 and settle for pass-through when one end declines, and the result is a system that mostly works and occasionally does not, for reasons that are invisible without looking at call detail.
How to tell which you have
You usually cannot tell from the outcome, because both succeed most of the time. Three things give it away.
- The failure pattern. Pass-through failures cluster on long documents and busy periods, because both increase exposure to network conditions. T.38 failures cluster on particular destinations, because they are more often about interoperability.
- Call detail from the carrier or gateway, which will name the negotiated media.
- Codec configuration. If compressed codecs are permitted on the path, fax was never going to be reliable regardless of which of these two is in play.
How to choose
If you are keeping fax in your own infrastructure, prefer T.38 end to end, confirm it is negotiated rather than merely supported, and test with realistic document lengths against real destinations rather than a friendly test number.
If you are moving fax to a service, this choice stops being yours, which is a large part of the reason people move. The service maintains the relationship with the fax network and handles negotiation and fallback. What is worth asking is not which protocol it uses but what it tells you when a transmission fails, and whether that report distinguishes a busy destination from a network fault. That distinction is the one that determines whether a failure can be handled automatically or needs a person.
What neither of them fixes
It is worth being clear about the boundary of this choice, because it is easy to spend a long time on it and still have the same problems.
Neither protocol makes a busy machine answer. Neither tells you that a number is wrong. Neither improves a document that was poor before it was sent, and neither makes a fax searchable at the far end. The transport question is worth getting right because getting it wrong produces failures that are maddening to diagnose, but it is a question about reliability, not about capability.
Where to go next
For the wider transport picture, see what fax over IP is. For what happens on the call itself, how electronic fax works. For what a service takes off your hands, the feature overview, or tell us what you are working with.
If you inherited the configuration
A great many fax problems are inherited rather than chosen. Somebody configured a gateway years ago, it worked, and nobody has looked since. Before changing anything, find out what is actually negotiated on a real call to a real destination, and find out whether the current arrangement is a decision or an accident. Both are common, and they call for different responses: a decision deserves a conversation, an accident deserves a fix.
Sources
- ITU-T Recommendation T.38. Procedures for real-time Group 3 facsimile communication over IP networks, in force at edition 11/15.
- ITU-T Recommendation G.711. Pulse code modulation of voice frequencies.
- RFC 4612, Real-Time Facsimile (T.38) audio/t38 MIME Sub-type Registration.