Fax nowadays comes in various colors and flavors and one need to be aware of that. In case everything is analogue (or ISDN), the internal fax engine based on spandsp is fine and everything works out great. You can turn on and off ECM according to your mood.
In case you get your transmissions via SIP things change a bit. Theoretically, T.38 helps, but I have never seen a Telco or ISP (in Europe) actually supporting it, despite they advertise it. When you increase the CLI verbosity you get warnings about the other side refusing to negotiate the T.38 protocol. You can still do facsimiles without T.38.
Let me first describe some technical things, before I describe the parameters that most of the time work for me and I deem to be important. Line switching and packet switching have entirely different ways to deal with transmission problems. Line switching implies very fast reactions (essentially speed of light) with possibly distorted signals. Packet switching implies repeated sending of packages in case the other side gets junk, but SIP/RTP is mostly used and nothing gets checked before Asterisk sees the data. T.38 has ways to repeat elements, but that’s pointless when you get everything wrapped up in parcels. Furthermore, dropped packets might contain vital information which can easily leads to a sudden death of the transmission attempt.
Assuming that the internet connection is good enough, one should turn off all types of error connection, especially ECM and try to run everything at a rate of 14400. Slower speeds mean a larger transmission time and time is your enemy here. By the same token, I prefer normal resolution whenever possible. The jitter buffer should be of a fixed size, typically maybe holding sound for about 100ms. If a transmission starts and a dynamic buffer gets adjusted a short delay could make the other side say bye-bye. The codec should be lossless, either G.711 of G.722. G.722 is better, but that can typically not be negotiated. E.g. GSM leads to hair loss and painful feet, so don’t do it. Lossy codecs change the frequency patterns in such a way that the resulting signal can no longer be decoded.
The basic idea is to keep everything floating without any interruptions. Then you depend only on the quality of the internet connection and what the other sides wants to get enforced. This largely excludes spandsp based solutions as they are typically too strict. It seems that some ATA devices do not strictly enforce the protocol and focus on printing whatever arrives. This might lead to one or the other visual defect, but that’s better than nothing in this case.