flexfax: Re: (Fwd) Fw: Problems with outgoing faxes from a ZyXEL Omni

[Shuvam Misra <shuvam@spacenetindia.com>]

Dear Ketan, Manfred and Harald,

Many thanks for taking so much time and effort to try to find the source
of my fax problems.

I'd like to discuss some of the points raised. And I'm posting this to
the Hylafax mailing list hoping to get some of the fax experts there to
respond to the Hylafax related points you've raised.

| >I am a computer professional. I've been using ZyXEL modems from 1995,
| >starting with the U1496E. I have had very good results with this modem
| >for data connects over noisy phone lines. I am an experienced Unix
| >systems programmer and occasional kernel hacker.
| 
| And where are the 'fax experiences' ? :-)

Next to nothing, I'm afraid. I'm much more of a software person than a
hardware or datacomm person.

| >I am using a Pentium machine running Linux 2.0.33, Hylafax 4.0pl2, and an
| >Omni O288S with firmware 1.19.
| 
| Omni should be OK, but Hylafax ....

I've gone through your mail, and I can see your strong reservations
about Hylafax. I make no claim that Hylafax is the world's best fax
software. :) However, I believe that faxing is a technically challenging
function, and any fax software will be less than perfect.

That said, I must add that I find it hard to believe that Hylafax will
be less competent than any other good fax software. It has two major
plusses to its credit:

1.	It is very widely used. It is probably the most popular fax
	software on Unix.

2.	It is written by Sam Leffler.

I presume Sam Leffler needs no introduction to the Unix world. He was a
member of the core CSRG that created BSD Unix. He is one of the best
engineers that the software community has today, I feel. His track
record for good engineering makes it unlikely that there will be any
slipshod work either in the software that prepares TIFF G3 data out of
the input file, or in the fax transmission software itself. Sam has
written perhaps the definitive TIFF library available on the Internet,
and this library handles the TIFF file creation for Hylafax.

In this context, it is unlikely that Sam Leffler would not know about
not retransmitting the same page after a negative RTN, as you've pointed
out. If Hylafax retransmits the same page, and it conflicts with the fax
protocol, I guess Sam had some reasons for it. I'm hoping to hear from
Sam or others on the Hylafax mailing list about this.

My point is not "Sam is the new God I follow" but that the designers of
Hylafax must have their reasons, which I hope to discover now, thanks
to your inputs.

The last point I'd like to add is that we Unix users running Linux and
operating on shoestring budgets, don't have a choice. Hylafax is the
most comprehensive fax software that's freely redistributable in source
for the Unix platform, and mgetty+sendfax is the only other well-known
alternative. I haven't tried mgettty+sendfax, but I could, I guess.
Maybe this too could be something others on the Hylafax mailing list
could advise me on. Do you think there are problems in the fax protocol
implementation of Hylafax, and is mgetty+sendfax better?

| >(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 !

This is not true. There seems to be a big advantage to be gained by
being able to differentiate between NO ANSWER and NO CARRIER. If ZyXEL
could have returned the correct response to distinguish between them,
the fax software could have figured out whether there's a fax machine at
the other end (NO CARRIER after handshake attempt) or just an ordinary
phone (NO ANSWER). I got this info from the Hylafax documentation. Check
http://www.vix.com/hylafax/

| >I am getting an enormous number of reports of failed faxes, all due to
| >a few repeated reasons....
| 
| Not so good. As a rule of thumb: appr. 40 % of outgoing faxes from a
| (public faxserver) will fail...

This figure was very useful. I didn't know that the typical observed
figures for failed attempts is so high even in your parts of the world
in spite of your better phone networks. My figure is more like 60% to
70%, I think.

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

Hylafax does. It disconnects the line, reconverts the data, and retries
the call.

| >   4 Error: Failure to train at 2400 bps or +FMINSP value
| A sign for bad telco line ...

Very possible that my line is noisy. This is usual in India, and
specially in my exchange.

| >  29 Error: No response to MPS repeated 3 times
| 
| This is 'system immanent' to all faxmodems, I believe :-) We have to
| live whit this, regardles which brand of faxmodem, there ALWAYS exist
| (remote) certain fax equipment, which will not fit our site ...

Can you give me some more details on this? What causes this?

| >113 Error: Unable to transmit page (giving up after 3 attempts)
| 
| Not so clear this report. What in detail was the reason ? Could be
| simply BUSY at remote site ...

These details are available in the big log file that I've left on the
Website, at http://www.spacenetindia.com/faxerrors.txt. It's a huge
file, about 1.5MB, so if you have the patience, you'll get the full
modem dialog for a few hundred failed fax transmission attempts.

| >274 Error: Unspecified Transmit Phase B error
| 
| No 'normal' fault :-) Yield of well sent faxes can only be 'increased'
| by using Class 1 protocol ...

This is interesting. Is it easier to get good fax transmission using
Class 1 protocol? I thought Class 1 was too timing-sensitive and
therefore more error-prone when driven from multitasking operating
systems?

| >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 ...

Yes, I know. But the fax software allows this if the modem allows it.

| >Mar 25 22:20:08.82: [ 3664]: REMOTE best format 2-D MR
| 
| I assume, that THIS is the reason for a lot of problems! faxdata makeup
| for 2-D mod. mod. Read is obviously 'out of spec' from ITU-T.4 and
| normaly fax machines reject such transmissions (with bad T.4 data) by
| sending RTN ...

How do you know that the data being generated at the transmitting end is
out of spec with the ITU standards? Is there any way I can find out?

| 09:50:13.69 {01 200} Receive:  2,96E,5,1,0<CR><LF> 0.22s
| 09:50:13.69 {01 200} Receive:  OK<CR><LF> 0.25s
| 
| The above (first) value of '2' means RTN ! Faxmodem can NOT decide,
| what to do, so fax software starts to send NEXT page (faxsoftware
| should NEVER RETRANSMIT a page).

This is interesting. When this error occurs, you feel that the fax
software should proceed with the next page as if there was no error at
all? Will some expert users of Hylafax please comment?

| >Mar 25 00:03:46.75: [22884]: REMOTE HANGUP: Unspecified Transmit Phase B err
| >(code 20)
| 
| Modem has cancelled the call after 144 seconds. This is a quite large
| time! All points to a failed training. Maybe the telco line was VERY
| VERY BAD.

This too is possible.

| >|   SM> | I've been trying to send out faxes to Mumbai using "tpc.int" but
| >|   SM> never got | through to it! However, the recepients complain that the
| >|   SM> receive about 8-12 | copies of the same fax sent to them.
| 
| Fax software MUST NOT retransmit any page after RTN ...

This is what I found particularly interesting. If the standard is very
clear on this, will someone who knows Hylafax comment on these protocol
issues?

Thanks once again. You have been very very patient and thorough and
you've taken a lot of trouble with my query. I'll see if Hylafax is
really the source of the problem as you state it is.

Warm regards,
Shuvam