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. _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
