[Asterisk-Users] spandsp and app_rxfax (alternative topic:t38modem)

[Lee Howard]

On 2005.01.07 09:42 Jeff wrote:

> It is my speculation that the 'cutoff' problem was related to some
> type of
> 'line noise' and that others successfully using the spandsp code
> _might_ be
> using T1/E1 rather than analog lines (1FL) but when I started testing
> using
> an old Fax machine plugged into a station port with a six foot RJ11 on
> either end, I realized that this setup really shouldn't be introducing
> much
> noise (if any) so I am lost. It happens approximately half way through
> EVERY
> fax I attempt regardless of sending machine (I tried Dialogic and some
> modems) or port (FXO or FXS) so I just gave up on it.

Since spandsp doesn't use ECM, what I'm about to say doesn't apply to 
spandsp.  If you receive truncated (versus corrupted) fax images from 
spandsp, then I'm not sure what the problem would be.  What I'm about 
to say only applies to ECM-enabled fax sessions such as usually will 
happen with most modern fax machines and modern HylaFAX.

Truncated fax images usually only occur in an ECM-enabled fax session 
when the total image is larger than 64KB.  With images larger than 64KB 
it is required that the image data be broken up into 64KB "blocks" and 
each block is transmitted separately.  In the fax protocol this 
essentially works out to the same thing as sending a multipage fax 
except that the in-between-blocks signals indicate a multiple-block 
scenario rather than a multiple-page one.

The timing sensitivities between pages and between blocks are crucial.  
A 20 ms lag at this point will most certainly terminate the fax 
session.  Most "pauses" between signal exchanges during faxing are 75 
ms +/- 20 ms.  This means that most senders will wait pause for what it 
believes to be exactly 75 ms, with the buffer to compensate for any 
lags incurred by the telco or other timing issues.  Consequently, if 
Asterisk (or the VoIP configuration) introduces a 20 ms lag at this 
point, then the timing tolerances will be exceeded, and a fax machine 
following the specifications will terminate the fax session after a few 
attempts to recover from this.

So, you end up with a page of image data missing one or more blocks, 
and this produces a "truncated" (not corrupted) fax image.  Now, 
depending on other factors the very end of that image data could, in 
theory, also look corrupted.  But, most ECM sessions are going to use 
MMR compression, meaning that any data corruption (only possible in 
that last block received) would also likely truncate the image at that 
point (since any data after the point of corruption becomes 
meaningless).

As far as I've been able to determine, there's nothing that can be done 
about this working with analog fax equipment behind Asterisk.  In order 
for things to work correctly here, either Asterisk needs to support 
T.38 (FoIP specification), or Asterisk needs to produce pseudo-modem 
interfaces for fax packages like HylaFAX.  I think the spandsp author 
is working on both of these over time.

Lee.