Re: flexfax: This is a response to my earlier query

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

> Maybe, but Omni is much more in accordance to fax standard. But I know
> - - from my experiences - that faxmodems which are just a little step
> beside the standard, will cowork better with absolute mis-standardized
> faxequipment/faxsoftware :-)

I don't think we are talking the same standards here. The T. standards
are what goes to the line, not what happens between a Class 2 modem
and the computer.

> 
> >(HylaFax identifies one problem with
> >ZyXEL firmware: the "atdtnnnnnnn@" format of dial command does not work
> >with any ZyXEL modem. The "@" at the end of the dial string is supposed
> >to distinguish between "NO ANSWER" and "NO CARRIER".
> 
> Only 'NO CARRIER' is the response of interrest !

As far as I know this is fully configurable.   I'm not convinced it is part of
the faxmodem standards.


> >   1 Error: Document was encoded with 2DMR, but client does not support this
> >data format
> 
> Faxsoftware MUST DO a 'fallback' to 1-D Huffman !!!!

I believe that Hylafax starts low and only tries to optimise if a 
previous contact has established that the remote modem has 2D capability.
If the remote modem is really multiple modems with different capabilities,
you should lock down the characteristics with & or purge the info file.
I believe that it will retry, with corrected paramter, if the modem does
change spec downwards.  (What happens if you make the info directory
read only - does it break or does it always start from first principles?)

---
I missed one about Class 1, but Class 2 is your choice.  Hylafax will
do Class 1.

> >Mar 25 22:19:40.81: [ 3664]: <-- [36:AT&B1&N0&S0S18=4S38.3=1E0V1Q0S0=0H0\r]
> 
> Senseless initialisation. use ATZ and ATE0 only!

User configuration, not intrinsic to the sofware.  Personally I would start
with AT&F, to make sure the modem was in a known state.  The ATZ ATE0 
suggestion is based on preconfiguring the modem and only using it for
fax purposes.  The above string is probably trying to get into into a
sensible state when the NVRAM contents are unknown, and the modem
might be used for data or even voice as well.

> 
> >Mar 25 22:19:41.95: [ 3664]: <-- [24:AT+FLI="SpaceNET India"\r]
> 
> Not in accordance to ITU-T.30 !!! Only '0' - '9', '+' and ' ' (blank)
> !!! Faxsoftware should know this ...

This is documented with the note that most fax machines do not impose this
restriction.  You are violating it at your own choice.  Not a Hylafax
problem, but a user one.

> 
> >Mar 25 22:20:08.82: [ 3664]: USE 1-D MR
> 
> But local equipment has decided to use 1-D Huffman ...

Seems a reasonable fall back.

> remote site. Some of this 'normal' situations can be fitted by using
> Fax Class 1 ...

User choice with Hylafax.

It's possible that the Hylafax response to retrains is wrong, but a lot
of the things quoted here seem to be configuration options, i.e. the problem
is that you are not using a modem for which an ideal configuration has
been produced; what I am saying is that the criticism is directed at
Hylafax as configured, although it is written as though it is directed
at Hylafax as though it were not configurable.  A lot of the others are
due to external factors (retrains are partly due to line quality).

It's probably worth pointing out that a simple fax machine can't retransmit
on an error because it has already ejected the source document, so 
one needs more than common practice before one can say that retransmitting
is wrong.

I don't see why a bad fax coding would cause a retrain, but the fax
coding is not done by Hylafax anyway, but by your RIP.  A badly coded
received fax would be valid reason for retransmitting.  Corrupt fax data
would most likely be caused by bad flow control, or underrunning the 
modem by not giving enough processor and memory resources to Hylafax.

(I can't afford the source standards from ITU-T and IEE to check the
details of the complaints.)