Re: flexfax: New problems with 3com/USR Voice Faxmodem

[David Woolley <david@djwhome.demon.co.uk>]

> Jan 02 23:01:43.09: [ 5807]: <-- data [2]
> Jan 02 23:02:00.24: [ 5807]: --> [5:ERROR]
> Jan 02 23:02:00.24: [ 5807]: SEND recv RTN (retrain negative)

I think RTN is guesswork here as it doesn't seem to have received a
very informative error status.  However real RTNs should be generated if
the receiver thinks that the transmission was of too poor quality for
an acceptable image.  The intention was that this should be used when the
telephone line properties had changed during the transmission and therefore
the modems needed to train their equalisers for the new properties.

However, a systematic coding error might be interpreted the same way by a
receiver that didn't actually monitor the analogue quality of the signal.

There is a known bug in the tag line processing in Hylafax that causes 
systematic errors which are sufficient to make some receivers issue RTN.
There is a patch for this, certainly at www.elgro.demon.co.uk and probably
at the new hylafax site.

Coding errors may also be introduced by overruns at the transmitting end,
due to inadequate flow control.

In a real retrain, the system should find a speed that produces acceptable
quality.  Hylafax doesn't force this by default, although the modem shouldn't
train faster than the line will tolerate.  If the problem is not the line
quality, the modem will always retrain to the same speed.  People have
reported that another patch, which causes the speed to be backed off
explicitly, does improve matters.