Fax over the internet works fine right up until it doesn't, and then it fails in confusing ways. The call connects, the machines squeal at each other, and the page never arrives. Here is the order I would check things in, starting with the causes that show up most often.
First, know which kind of fax you are sending
There are two ways to carry fax over SIP. Passthrough sends the fax tones as ordinary audio, usually over G.711. T.38 sends the fax data itself, so it survives packet loss much better. Most problems come from being stuck halfway: one side tries T.38, the other doesn't answer it, and the call falls back to audio that is already damaged.
What the symptoms usually mean
| Symptom | Likely cause |
|---|---|
| Call connects, no fax handshake | Wrong codec, or the provider is not offering T.38 |
| Fax starts then drops after a page or two | Packet loss, jitter or too high a speed |
| Garbled lines or missing parts of a page | Compression codec, echo canceller or jitter buffer |
| Works one direction only | NAT, firewall or SIP ALG on the router |
| Works for short faxes, fails for long ones | Marginal network quality |
Work through these in order
1. Does your provider support T.38?
Ask them directly, and ask whether it must be switched on for your account. Plenty of SIP trunks advertise it but only enable it on request. If they do not support it, passthrough over G.711 may still work, but expect lower reliability.
2. Use G.711 for fax, nothing else
Compressed codecs like G.729 and Opus are built for voice. They can wreck fax tones. Make sure the fax path allows G.711 (ulaw or alaw) and that nothing is transcoding it.
3. Turn off voice processing on fax calls
Echo cancellation, silence suppression and noise reduction help speech and harm fax. Disable them on fax lines and ATAs if you can.
4. Check jitter and packet loss
Fax is far less forgiving than voice. Use 20 ms packets, a fixed (not adaptive) jitter buffer on the fax path, and QoS so voice and fax traffic get priority. A quick test: run a ping or MTR to your provider during the day and look for loss.
5. Lower the speed
If fax drops partway through, cap the maximum rate (for example from 14400 to 9600 or 7200). Slower is much more tolerant of a poor line. Also try turning ECM on or off, because some machines handle it better than others.
6. Look for NAT and SIP ALG problems
Many routers have a feature called SIP ALG that rewrites SIP packets and often breaks them. Turn it off, and confirm your RTP and UDPTL port ranges are open and forwarded.
7. Check the PBX and ATA settings
On the PBX, T.38 must be enabled on the trunk or endpoint, and you need a working fax module installed. On Asterisk that means the fax resource and the T.38 options for your channel driver (the exact names depend on your version, so check its documentation). If you use an analog fax machine through an ATA, set the ATA to T.38 with fallback to G.711, and put it in its fax mode.
8. Read the SIP trace
If it still fails, capture the call. You are looking for a re-INVITE during the call that offers T.38 (a media line for image, udptl, t38) and a positive answer from the other side. If you see the offer and a rejection, the far side does not support it. If you never see an offer, your PBX is not switching.
A simple test routine
- Send a one-page fax to a number you control and check the result.
- Send a five-page fax and see if it survives.
- Repeat at a busy time of day.
- Change one setting at a time and write down what you changed.
When to stop tuning
If everything is correct and it still fails to certain numbers, the problem may be the other party's fax machine or carrier. Try a different outbound trunk for those numbers, or ask them to try a different machine.
For the basics, read how fax to email works on Asterisk and how to choose a SIP trunk. Telvora PBX has a built-in fax server with a log for each fax, see fax to email PBX.
