I'm going to let you in on a secret ... most of the T.38 Fax Over IP (FoIP) service you can buy today is fundamentally broken. As crazy as it sounds, it’s missing the one feature that makes sure the other side receives an exact copy of your image — a feature known as Error Correction Mode (ECM). Each day, millions of fax pages are sent via T.38 circuits that don’t have ECM enabled, and everyone just kind of hopes the fax pages make it to the other side intact. Sounds crazy? We agree!!
What is ECM and why is it important?
Fax is a page-by-page transmission method, usually done over standard telephone lines. The image data from each page is converted into an audio representation of the page, the audio is sent to the other side, and when both parties are ready, they move on to the next page. Now, the clever people who invented the fax protocol realized that phone lines are imperfect, and that every once in awhile there will be a pop, crackle, hum or hiss that distorts that audio signal, leading to loss of fax page image data. That's where ECM comes in - at the end of each page the sender and the receiver compare notes, check for any missing or distorted page image data, and then selectively re-transmit only that data. Again they compare notes, and if there's still missing data they repeat the process, only moving to the next page when the current page is 100% correct.
When ECM is not available, however, the end-of-page procedure is quite different, and error checking and error correction ability is limited.
When a non-ECM call reaches the end of a page, the receiving fax machine is still aware of any missing or corrupt page image data, but it's not able to request the missing data be re-sent. Instead, it can only tell the sender there was a problem with the page, and recommend that the two 'retrain' the session parameters so that the next page is more likely to get through under these adverse conditions. The receiver can send two types of retrain signal — retrain positive (RTP) which means the last page was damaged but acceptable; and retrain negative (RTN) which means the last page was too damaged to be used. The sender must decide what to do when RTN or RTP are received, but as you might expect most will move to the next page when receiving RTP, and re-send the previous page from the beginning when receiving RTN. Not all senders are capable of re sending the previous page, however, so responses to RTN can be unpredictable.
Merriam Webster defines facsimile as an exact copy, and that's precisely what you expect when you send a fax — i.e.: that your receiver will receive a bit-by-bit identical copy of the image you're sending. That's kind of the whole point of fax, and it's impossible without ECM.
Hold on, ... if it's so important, why do most carriers turn it off?
How can it be that a feature so fundamental to successful fax transmissions finds itself available, but disabled in most setups? I mean, some pretty clever people must be consistently making some fairly bad decisions, right? We've spent quite a bit of time researching this, and as far as we can tell there's a combination of three factors, that when combined, explain this puzzling situation:
- Early conventional wisdom and industry best practice suggested turning it off at the first sign of trouble
- ECM is computationally intensive and requires precious resources in costly switching equipment
- Most carriers are voice-centric, with limited fax expertise
As in the case of an aircraft investigation, no single factor on its own would have been a problem, but when combined they lead to disaster. Let's look at each of these reasons, briefly.
The first factor is the one most commonly repeated in online discussions and in countless examples of product documentation, but it's also the easiest one to discredit. ECM is too aggressive, it is claimed, and on a really noisy line the re transmission of missing page data not only slows the fax down, but in some cases will even cause the fax to fail unnecessarily. In reality, ECM page data re transmission is very efficient and rarely extends the per-page call duration more than a couple of seconds, and if you ever do have such a noisy line that ECM's tenacity causes the fax to hang up, well guess what - it's more important than ever to have had ECM on that call! Sure, without ECM your fax might make it to the other side without the sender having to hang up and redial, but it will most likely be so distorted that it's not legible. There's nothing worse than a fax that the sender thinks went through fine that cannot be read by the receiver!
It's impossible to argue with the second factor. When ECM is enabled, the T.38 gateway (carrier's session border controller or media gateway) must compute the checksum of each ECM packet, and compare it with the expected value. It's not complicated math, but it does require additional processing power. If you combine this resource intensiveness with the prevailing view that it's better to leave ECM off when doing T.38, well it's easy to see why most carriers have turned it off.
And then we have the third contributing factor, which is the final nail in the coffin for ECM. A fax industry veteran would cringe at the idea of globally disabling ECM and would not be swayed by the first two factors, but today's networks are being designed and implemented by voice, not fax experts.
But, ... my carrier insists that my T.38 has error correction enabled!
We often hear from frustrated prospects whose carriers insist that their T.38 implementations have error correction enabled, and yet there's no ECM error correction available on any T.38 fax calls to/from this carrier. This common misunderstanding arises because there are actually two types of error correction in the context of T.38:
- Error Correction Mode (ECM), a feature of the T.30 fax protocol
- Error correction of the T.38 UDPTL stream itself
We've been speaking at length about ECM, so the first type of error correction requires no further explanation. It's usually disabled and it's unlikely to be the error correction the carrier is talking about anyway.
The T.38 protocol itself has a form of error correction that has nothing to do with any T.30 fax features, but is part of the T.38 stream's own error checking. T.38 error correction comes in two forms — redundancy, where UDPTL packets are sent multiple times ; and Forward Error Correction (FEC) which uses a much more powerful, but less commonly deployed algorithm. T.38 error correction is very important, but must not be mistaken for ECM error correction.
In Conclusion
