Re: flexfax: Large number of errors with Hylafax and ZyXEL

[Robert Colquhoun <rjc@trump.net.au>]

Hi David,

Sorry for the delay in replying.

At 08:23 7/04/98 +0100, David Woolley wrote:
>V.21 should be very resillient; if you are getting errors in the V.21
>phase, I think your chances of getting anything at all at V.29 are 
>negligible.

Yes - thats why i wanted Shuvam to get his phone line checked by his telco
to make sure that wasn't the problem.

>If you've got a copy of T.30, not just one of the text only CDs from when
>they had an experiment with free electronic publication, could you 
>check what if any requirements are placed on the sending side on getting
>RTN.  The details are in the tables or diagrams.  All I can really clean
>from the bits on the CD are that the algorithm for deciding when a retrain
>is needed is not specified, and one of the things that can qualify the
>sender's behaviour (but not necessarily in this context) is its ability
>to retransmit.

I am finding this document a little hard to follow, but if the sender is
asked for a retrain is does state in the case of line noise the sender
should drop the speed of the connection. I guess from the receivers point
of view it is hard to tell between line noise and an incorrectly formatted
document.  If the document is incorrectly formatted it wouldn't matter how
much you reduced the connection speed it would still  come through
incorrectly and the receiver would repeatedly ask for another retrain.

This could be a problem in ghostscript or perhaps in the receivers
interpretation of 2D data.

In either case the sensible thing to do is to drop back to 1D encoding and
try to transmit that.  Then if the problem is line noise you can the cycle
down in speed to get a good connection.

Hylafax doesnt do this at the moment, when asked for a retrain it goes back
into phase b and comes out quite often with the same session parameters ie
no reduced speed.  This suggests a badly encoded document rather than a bad
line.

I am now looking around for some routines, or library functions that could
help 'transcode' a 2D document held in memory back to 1D on the run.  If
this is actually possible of course.

Otherwise hylafax would have to hang up the call on getting a RTN (or a RTP
in fact) and set the Destination Info to 1D only(even though the receiver
says it will accept 2D) and try to make the call again later

PS I am not very good at document formats, if someone would like to help me
with this i would _appreciate_ it.

- Robert