[asterisk-users] Zap channel faxing in or out fails but phone calls work.

Lee Howard faxguy at howardsilvan.com
Wed Jul 19 11:45:48 MST 2006


Maxim Vexler wrote:

> Check the paragraph on ECM at http://www.voip-info.org/wiki-Asterisk+fax


Everything that you read on a wiki must be considered potentially bogus 
or otherwise misinformed.

Let me rewrite that paragraph for you...

------------------------------------------------
ECM - error correction mode

Good fax machines with proper memory and programming are able to use 
Error Correction Mode (ECM) for error-free image transmission. When ECM 
is used, a fax page is transmitted as a series of blocks, each block 
consisting of a series of HDLC data frames. After receiving the data for 
a complete block, a receiving fax machine notifies the transmitting fax 
machine of any frames with errors. The transmitting fax machine then may 
retransmit the specified frames. This process may be repeated until all 
frames are received without errors, and then the procedure may continue 
on to the next block. If, for some reason, the receiving fax machine is 
unable to receive an error-free block, the fax sender may abort and 
disconnect, thus leaving the receiver with a partial or truncated image.
------------------------------------------------

The sentence that begins, "On networks that have a packet loss rate..." 
is simply nonsense, first-off, and what truth it is actually hinting at 
is as relevant to non-ECM faxing as it is to ECM faxing.

The intent of that sentence is probably directed towards the situation 
where you'd have a fax machine plugged into an ATA that is communicating 
to your LAN-hosted PBX that has PSTN connections.  So let me talk about 
that situation...

In order to experience packet-loss or some other kind of jitter on a LAN 
you either have problems with the LAN or your LAN bandwidth is seriously 
stretched.  VoIP packets running on a LAN are *far* more reliable than 
VoIP packets running over the internet.  So if you truly are 
experiencing 2% packet loss on a LAN between the ATA and the PBX, then 
there are network issues that need to be resolved.  In truth, most of 
the issues involved with using a fax machine on an ATA are not going to 
be network-related... but instead they're going to deal with issues in 
the ATA and in the PBX themselves when handling audio like fax that 
reliably cannot be corrupted (jitter buffers, echo cancellation, proper 
function, etc.).

The typical "packet loss" issues that Asterisk users see with fax are 
not network related, but rather deal with issues in the zaptel hardware 
or driver.  This has nothing to do with whether or not ECM is being 
used.  These issues generally cause premature carrier loss detection to 
occur by the fax receiver (meaning that the missing audio became silence 
somewhere along the audio path).  Fax protocol uses carrier loss as a 
way to indicate end-of-signal or end-of-message.  If carrier loss is 
detected prematurely then the connectivity between endpoints is put at 
risk and recovery largly will depend on the receiver's tolerance for 
that situation.

In fact, in these kinds of situations using ECM on a well-tolerant 
receiver may actually prove to be the only way that reliable fax 
reception can occur.  Whether or not that is the case depends upon the 
timings of the "packet loss" the effect of that packet loss on the 
receiver, and the data format used for the image.  By disabling ECM you 
limit data format types to MH and MR - which are both image format types 
that are generally rather tolerant of data corruption.  So if the 
"packet loss" translates into image data corruption and not premature 
carrier loss and if the amount of data corruption is negligible to the 
human eye, then it may appear that disabling ECM will help.

The chances that enabling ECM on an ATA-connected receiver will cause 
fax failures are pretty slim, in my expectation... and if it actually 
did, then I would suspect more fault lies on the ECM implementation on 
the receiver than in the nature of the ECM protocol itself.

Lee.




More information about the asterisk-users mailing list