HylaFAX The world's
most advanced open source fax server
|
|
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
This is a response to my earlier query
I run a TPC.INT cell and was getting way too many failed attempts at
transmitting a page. I use a ZyXEL modem, so I asked ZyXEL for help.
Here is a detailed answer. I've cut out some introductory stuff. My
original posting was available on the Hylafax mailing list about two
weeks ago.
This reply seems to say that Hylafax is the cause of some of the more
subtle protocol problems. Any comments?
For those who want to see my original Hylafax log files and error
reports, look at:
http://www.spacenetindia.com/faxerrors.txt
http://www.spacenetindia.com/fax/
Thanks,
Shuvam
------- Forwarded Message
[...]
because I don't find your friend's original eMail anymore, please forward
this reply concerning his Fax problem between Omni 288s with Hylafax.
My friend, Harald Pollack, is a fax developer here in Vienna and he knows
the ITU T.30, T.31 and T.32 specs. nearly by hard. His own fax software
runs under OS/2 and was reference fax for ZyXEL R&D when we did the Fax
PTT approval against ITU T.30 specs two years ago.
Harald knows the Fax protocols in a very similiar way as I know the ISDN
protocols...
electronic greetings from Vienna, Austria
Manfred Recla
**********************************************************
ZyXEL European File Distribution - Coordination Center
E-Mail: support@zyxel.co.at
FTP: ftp://ftp.zyxel.co.at/public/
WWW: http://www.zyxel.co.at
**********************************************************
- -----Original Message-----
From: Harald Pollack <Harald.Pollack@omv.co.at>
To: Manfred Recla <mr@rithus.co.at>
Date: Monday, March 30, 1998 11:21
Subject: Re: Fw: Problems with outgoing faxes from a ZyXEL Omni
> I'll try to put all this in an easy-to-understand mail for you.
Yes, was 'easy' enough :-)
>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' ? :-)
>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 am handling about two to three hundred
>outgoing faxes a day from this server, to all sorts of local machines
>in Bombay city. HylaFax documentation and the HylaFax user community
>acknowledges the U1496E as a very good fax modem. It supports more recent
>ZyXEL modems like the Omni too.
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 :-)
>(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 !
>The problem:
... is definitvely the faxsoftware !
>-----------
>I am getting an enormous number of reports of failed faxes, all due to
>a few repeated reasons. For instance, in one 24-hour period, I have sent
>out a total of 183 pages of faxed data, and in the process rejected
>424 faxes to various destinations due to various errors.
Not so good. As a rule of thumb: appr. 40 % of outgoing faxes from a
(public faxserver) will fail...
>Here is the
>summary of the error messages with a count against each:
>
> 1 Error: COMREC error in transmit Phase B/got DCN
OK, may occure ...
> 1 Error: Document was encoded with 2DMR, but client does not support this
>data format
Faxsoftware MUST DO a 'fallback' to 1-D Huffman !!!!
> 4 Error: Failure to train at 2400 bps or +FMINSP value
A sign for bad telco line ...
> 2 Error: RSPREC error/got DCN
OK, may occure ...
> 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 ...
>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 ...
>274 Error: Unspecified Transmit Phase B error
No 'normal' fault :-) Yield of well sent faxes can only be 'increased'
by using Class 1 protocol ...
>If we ignore the less frequent errors, most of the frequent errors are
>while transmitting the second page after the first page has gone.
As I said. This fault is 99.9% depending on behaviour of fax software!
>I enclose a sample log file of the dialog between HylaFax and my modem
>below, for some of these errors. If you want the full log of all the
>errors,
Thank you very much, the logs show all (the misbehaviour of faxsoftware
:-)
I have tried to send to one of the stations (the other two where
continuously BUSY) and all went correct!
>Most of these errors are of the following pattern: my faxmodem sends out
>the first page, and gives the "MPS" command. The remote fax machine
>returns "ERROR". My fax software retransmits the same page, and tries
>another "MPS". The remote fax machine gives me another "ERROR". This
>repeats for a few times, and then my fax software aborts this
>transmission.
Yes, know situation (and maybe a misbehaviour of Hylafax) ... I will
comment it in detail ...
>At the remote end, the recipient gets multiple perfect
>reproductions of the first page, but nothing more.
Yes! But do NOT say 'perfect'! It only LOOKS perfect, but there was an
error in transmission, the fax receiver had recognized!
>Sometimes they are reported as "Unspecified Transmit Phase B error.", with
slightly
>different behaviour.
Class 2 (and 2.0) Hangup results are NOT very clear and often very
confusing :-)
> We also have a large sample size, and we can
>clearly see that this is a general problem, not limited to one or two
>recipient fax machines.
Time to look for a 'perfect' fax software :-)
>... and we have always recommended ZyXEL modems,
>believing them to be technically superior to almost anything in the
>market.
A very good (the best) decision at all. But how about the (vital)
faxsoftware ?
>1. a few logs of fax sessions where the exact errors are
>shown. The full set of 424 such logs is available on the
>Web at the location specified above.
more below ...
>2. a message from the global coordinator of TPC.INT, where
>he mentions that these end-of-page errors is quite
>common with ZyXEL modems, and less common with
>Multitech.
Maybe Multitech is not in accordance to fax standard (like the used
faxsoftware) ?
>We really hope you can help us. We sincerely want to work with you to
>fix these problems and get back our faith in ZyXEL hardware. Ketan has a
>lot of faith in your ability to help with extraordinary problems, and we
>depend on you for a solution.
Simply: use another faxsoftware :-)
>Error: No response to MPS repeated 3 times
>Mar 25 22:19:38.20: [ 3664]: SESSION BEGIN 00003898 91222855861
>Mar 25 22:19:38.20: [ 3664]: SEND FAX: JOB 1580 DEST +91222855861 COMMID
>00003898
>Mar 25 22:19:38.20: [ 3664]: DELAY 2600 ms
>Mar 25 22:19:40.81: [ 3664]: <-- [36:AT&B1&N0&S0S18=4S38.3=1E0V1Q0S0=0H0\r]
Senseless initialisation. use ATZ and ATE0 only!
>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 ...
>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 ...
>Mar 25 22:20:08.82: [ 3664]: USE 1-D MR
But local equipment has decided to use 1-D Huffman ...
>Mar 25 22:20:43.03: [ 3664]: SEND send MPS (more pages, same document)
>Mar 25 22:20:56.93: [ 3664]: --> [2:OK]
>Mar 25 22:20:56.94: [ 3664]: SEND recv MCF (message confirmation)
OK, page was accepted ...
>Mar 25 22:21:19.63: [ 3664]: SEND send EOP (no more pages or documents)
>Mar 25 22:21:25.54: [ 3664]: --> [7:+FHS:52]
>Mar 25 22:21:25.55: [ 3664]: REMOTE HANGUP: No response to MPS repeated 3 time
s
>(code 52)
Kind of 'normal' fault when using faxmodems (each and every brand).
Points to some faults in T.30 timeout specification either at local or
remote site. Some of this 'normal' situations can be fitted by using
Fax Class 1 ...
>Error: Unable to transmit page (giving up after 3 attempts)
>Mar 25 03:06:17.06: [24328]: SESSION BEGIN 00003413 91223879388
>Mar 25 03:06:20.92: [24328]: DIAL 3879388
>Mar 25 03:06:20.92: [24328]: <-- [12:ATDT3879388\r]
>Mar 25 03:06:46.16: [24328]: --> [4:+FCO]
>Mar 25 03:06:46.28: [24328]: --> [118:+FNF:00 00 0E 00 00 00 96 0F 01 03 00 10
>05 02 95 C8 08 01 49 02 53 41 4D 2D 53 41 4D 20 54 52 41 56 45 4C 53 20 03 ]
>Mar 25 03:06:46.28: [24328]: REMOTE NSF "00 00 0E 00 00 00 96 0F 01 03 00 10 0
5
>02 95 C8 08 01 49 02 53 41 4D 2D 53 41 4D 20 54 52 41 56 45 4C 53 20 03"
>Mar 25 03:06:46.28: [24328]: --> [26:+FCI: 022 3879388 ]
>Mar 25 03:06:46.28: [24328]: REMOTE CSI "022 3879388"
>Mar 25 03:06:46.28: [24328]: --> [20:+FIS:1,3,0,2,1,0,0,4]
>Mar 25 03:06:46.28: [24328]: --> [2:OK]
>Mar 25 03:06:46.28: [24328]: <-- [23:AT+FIS=1,3,0,2,0,0,0,4\r]
>Mar 25 03:06:46.40: [24328]: --> [2:OK]
>Mar 25 03:06:46.40: [24328]: <-- [7:AT+FDT\r]
>Mar 25 03:06:53.05: [24328]: --> [20:+FCS:1,3,0,2,0,0,0,3]
>Mar 25 03:06:53.59: [24328]: --> [7:CONNECT]
>Mar 25 03:06:53.59: [24328]: SEND begin page
>Mar 25 03:07:18.72: [24328]: SENT 29056 bytes of data
>Mar 25 03:07:18.72: [24328]: SEND 1D RTC
>Mar 25 03:07:18.72: [24328]: SEND end page
>Mar 25 03:07:18.72: [24328]: SEND send MPS (more pages, same document)
>Mar 25 03:07:32.10: [24328]: --> [5:ERROR]
>Mar 25 03:07:32.10: [24328]: SEND recv RTN (retrain negative)
>Mar 25 03:07:32.10: [24328]: <-- [7:AT+FDT\r]
>Mar 25 03:07:38.77: [24328]: --> [20:+FCS:1,3,0,2,0,0,0,3]
>Mar 25 03:07:39.30: [24328]: --> [7:CONNECT]
>Mar 25 03:07:39.30: [24328]: SEND begin page
>Mar 25 03:08:04.31: [24328]: SENT 29056 bytes of data
>Mar 25 03:08:04.31: [24328]: SEND 1D RTC
>Mar 25 03:08:04.31: [24328]: SEND end page
>Mar 25 03:08:04.31: [24328]: SEND send MPS (more pages, same document)
>Mar 25 03:08:17.82: [24328]: --> [5:ERROR]
>Mar 25 03:08:17.82: [24328]: SEND recv RTN (retrain negative)
>Mar 25 03:08:17.82: [24328]: <-- [7:AT+FDT\r]
>Mar 25 03:08:30.96: [24328]: --> [20:+FCS:1,2,0,2,0,0,0,3]
>Mar 25 03:08:31.50: [24328]: --> [7:CONNECT]
>Mar 25 03:08:31.50: [24328]: SEND begin page
>Mar 25 03:08:59.86: [24328]: SENT 29056 bytes of data
>Mar 25 03:08:59.86: [24328]: SEND 1D RTC
>Mar 25 03:08:59.87: [24328]: SEND end page
>Mar 25 03:08:59.87: [24328]: SEND send MPS (more pages, same document)
>Mar 25 03:09:16.24: [24328]: --> [5:ERROR]
>Mar 25 03:09:16.24: [24328]: SEND recv RTN (retrain negative)
>Mar 25 03:09:16.24: [24328]: <-- [7:AT+FKS\r]
>Mar 25 03:09:17.69: [24328]: --> [7:+FHS:02]
>Mar 25 03:09:17.69: [24328]: REMOTE HANGUP: Call aborted, from +FK or <CAN>
>(code 2)
I have also tried this station:
09:48:47.81 {01 200} Action: Phase A 2.0 Call set up 4.97s
09:48:47.81 {01 200} Send: ATD0W0091223879388<CR>
09:49:27.38 {01 200} Receive: <CR><LF>
09:49:27.38 {01 200} Receive: +FCO<CR><LF> 0.03s
09:49:27.38 {01 200} Receive: <CR><LF> 0.06s
09:49:27.44 {01 200} Receive: +FNF:00 00 0E 00 00 00 96 0F 01 03 00 10
05 02 95 C8 08 01 49 02 53 41 4D 2D 53 41 4D 20 54 52 41 56 45 4C 53 20
03 <CR><LF> 0.06s
09:49:27.44 {01 200} Receive: NSF, Panasonic 4800 station ID "SAM-SAM
TRAVELS " 0.09s
09:49:27.44 {01 200} Receive: <CR><LF> 0.12s
09:49:27.44 {01 200} Receive: +FCI: 022 3879388 <CR><LF>
0.19s
09:49:27.47 {01 200} Receive: <CR><LF> 0.22s
09:49:27.47 {01 200} Receive: <CR><LF> 0.25s
09:49:27.47 {01 200} Receive: <CR><LF> 0.31s
09:49:27.47 {01 200} Receive: +FIS:1,3,0,2,1,0,0,4<CR><LF> 0.34s
09:49:27.47 {01 200} Receive: <CR><LF> 0.38s
09:49:27.47 {01 200} Receive: OK<CR><LF> 0.44s
09:49:27.47 {01 200} Action: Phase B 2.0 Pre-message procedure 0.53s
09:49:27.47 {01 200} Send: AT+FDT<CR>
09:49:41.47 {01 200} Receive: <CR><LF>
09:49:41.47 {01 200} Receive: +FCS:1,2,0,2,1,0,0,3<CR><LF>
09:49:42.03 {01 200} Receive: <CR><LF> 0.03s
09:49:42.03 {01 200} Receive: CONNECT<CR><LF> 0.07s
Transmission speed of 9600 bps was not accepted, so modem did fallback
to 7200 bps ...
09:49:42.06 {01 200} Action: Phase C 2.0 Message transmission 1.07s
09:49:42.06 {01 200} Action: Parameter: Fine 7200 V.29/V.17 2-D mod.
Read 10 ms/line (pad=0) 1.13s
... all data was sent ...
09:49:58.75 {01 200} Info: 199 bytes faxdata [timeout 48 sec]
09:49:58.75 {01 200} Send: <DLE>, 0.16s
09:49:58.75 {01 200} Debug: 12650 bytes sent (74 DLE inserted)
0.19s
09:50:13.66 {01 200} Receive: <CR><LF>
09:50:13.66 {01 200} Receive: ERROR<CR><LF> 0.03s
09:50:13.66 {01 200} Action: Phase D 2.0 Post-message procedure
0.15s
09:50:13.66 {01 200} Send: AT+FPS?<CR> 0.19s
09:50:13.69 {01 200} Receive: <CR><LF> 0.19s
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).
09:50:13.69 {01 200} Action: Phase B 2.0 Pre-message procedure 0.41s
09:50:13.69 {01 200} Send: AT+FDT<CR>
09:50:28.00 {01 200} Receive: <CR><LF>
09:50:28.00 {01 200} Receive: +FCS:1,3,0,2,1,0,0,3<CR><LF>
09:50:28.53 {01 200} Receive: <CR><LF>
09:50:28.56 {01 200} Receive: CONNECT<CR><LF> 0.04s
And this decision was ACCEPTED from remote receiver! training has
passed and modem had done a FALLFORWARD to 9600 bps!!!
Forgive me, but I MUST SAY: the best modem on world :-)
>Error: Unable to transmit page (giving up after 3 attempts)
>Mar 25 03:15:04.41: [24385]: SESSION BEGIN 00003416 91223879388
Same as above. In my opinion, the modem was OK, only fax software has
failed ...
>Error: Unspecified Transmit Phase B error
>Mar 25 00:02:18.27: [22884]: SESSION BEGIN 00003314 91228581006
>Mar 25 00:02:22.13: [22884]: DIAL 8581006
>Mar 25 00:02:22.13: [22884]: <-- [12:ATDT8581006\r]
>Mar 25 00:03:46.75: [22884]: --> [7:+FHS:20]
>Mar 25 00:03:46.75: [22884]: REMOTE HANGUP: Unspecified Transmit Phase B error
>(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.
Now look at my call to this station:
09:12:34.72 {01 200} Action: Phase A 2.0 Call set up 0.03s
09:12:34.72 {01 200} Send: ATD0W0091228581006<CR>
09:13:12.63 {01 200} Receive: <CR><LF>
09:13:12.63 {01 200} Receive: +FCO<CR><LF> 0.03s
09:13:12.66 {01 200} Receive: <CR><LF> 0.03s
09:13:12.69 {01 200} Receive: +FNF:86 FA 00 10 14 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 41 B5 80 41 75 56 <CR><LF>
0.03s
09:13:12.69 {01 200} Receive: NSF, no known fax equipment 0.09s
09:13:12.69 {01 200} Receive: <CR><LF> 0.16s
09:13:12.72 {01 200} Receive: +FCI: <CR><LF>
0.16s
09:13:12.72 {01 200} Receive: <CR><LF> 0.19s
09:13:12.72 {01 200} Receive: <CR><LF> 0.25s
09:13:12.72 {01 200} Receive: <CR><LF> 0.31s
09:13:12.72 {01 200} Receive: +FIS:1,3,0,2,1,1,0,4<CR><LF> 0.34s
09:13:12.72 {01 200} Receive: <CR><LF> 0.41s
09:13:12.72 {01 200} Receive: OK<CR><LF> 0.44s
09:13:12.72 {01 200} Action: Phase B 2.0 Pre-message procedure 0.53s
09:13:12.72 {01 200} Send: AT+FDT<CR>
09:13:19.19 {01 200} Receive: <CR><LF>
09:13:19.19 {01 200} Receive: +FCS:1,3,0,2,1,0,0,3<CR><LF>
09:13:19.72 {01 200} Receive: <CR><LF> 0.03s
09:13:19.72 {01 200} Receive: CONNECT<CR><LF> 0.06s
All went correctly ...
09:13:19.75 {01 200} Action: Phase C 2.0 Message transmission 1.06s
09:13:19.75 {01 200} Action: Parameter: Fine 9600 V.29/V.17 2-D mod.
Read 10 ms/line (pad=0) 1.13s
Transmission of faxdata of first page...
09:13:36.38 {01 200} Info: 199 bytes faxdata [timeout 44 sec]
09:13:36.38 {01 200} Send: <DLE>, 0.15s
... MPS ...
09:13:36.38 {01 200} Debug: 12641 bytes sent (75 DLE inserted)
0.22s
09:13:36.38 {01 200} Wait for: end-of-page response 0.28s
09:13:51.00 {01 200} Receive: <CR><LF>
09:13:51.00 {01 200} Receive: OK<CR><LF> 0.03s
09:13:51.00 {01 200} Action: Phase D 2.0 Post-message procedure
0.13s
Nothing to do here ...
09:13:51.00 {01 200} Action: Phase B 2.0 Pre-message procedure 0.25s
09:13:51.00 {01 200} Send: AT+FDT<CR>
09:13:57.19 {01 200} Receive: <CR><LF>
09:13:57.19 {01 200} Receive: +FCS:1,3,0,2,1,0,0,3<CR><LF>
09:13:57.72 {01 200} Receive: <CR><LF> 0.03s
09:13:57.72 {01 200} Receive: CONNECT<CR><LF> 0.06s
... so let's start transmission of second page ...
09:13:57.75 {01 200} Action: Phase C 2.0 Message transmission 1.03s
09:13:57.75 {01 200} Action: Parameter: Fine 9600 V.29/V.17 2-D mod.
Read 10 ms/line (pad=0) 1.10s
09:14:14.41 {01 200} Info: 247 bytes faxdata [timeout 44 sec]
09:14:14.41 {01 200} Send: <DLE>. 0.15s
EOP
09:14:14.41 {01 200} Debug: 12683 bytes sent (74 DLE inserted)
0.19s
09:14:14.41 {01 200} Wait for: end-of-page response 0.28s
09:14:29.85 {01 200} Receive: <CR><LF>
09:14:29.85 {01 200} Receive: +FHS:00<CR><LF> 0.03s
What else ? :-)
09:14:29.85 {01 200} Action: Phase D 2.0 Post-message procedure
0.12s
Nothing to do here ...
09:14:29.85 {01 200} Action: Phase E 2.0 Call release 0.25s
09:14:29.85 {01 200} Send: AT+FDT<CR> 0.31s
09:14:29.85 {01 200} Receive: <CR><LF> 0.34s
09:14:29.85 {01 200} Receive: OK<CR><LF> 0.40s
No problems (if faxsoftware is in accordance to standards :-)
>Error: Unspecified Transmit Phase B error
>Mar 25 00:10:02.12: [22948]: SESSION BEGIN 00003318 91228581006
>Mar 25 00:10:05.98: [22948]: DIAL 8581006
>Mar 25 00:10:05.98: [22948]: <-- [12:ATDT8581006\r]
>Mar 25 00:11:24.38: [22948]: --> [7:+FHS:20]
>Mar 25 00:11:24.38: [22948]: REMOTE HANGUP: Unspecified Transmit Phase B error
>(code 20)
See above. Looks also like failure to train. Maybe the 'BUSY' tone from
remote was not recognized ...
>== message from TPC.INT coordinator =======================================
>| 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 they
>| SM> receive about 8-12 | copies of the same fax sent to them.
Fax software MUST NOT retransmit any page after RTN ...
>| SM> I have gone through the reports that you have helpfully included. It
>| SM> appears that each transmission has attempted to send the same page ove
r
>| SM> and over, and each time, the remote fax machine has reported ERROR
Correct :-)
>| SM> after the full first page has been transmitted. This has resulted in a
>| SM> retransmission, and so the first page has been transmitted again and
>| SM> again. This has probably resulted in the first page being transmitted
>| SM> many times, but without it being treated as a success at the
>transmitting
>| SM> end.
Do not mix up received pages, which LOOKS correct with serious failures
in T.4 faxdata makeup!
If faxmachine responses with RTN ... well, than a failure was evident!
regardles how the pages LOOKs to a human!
>| SM> We don't know why this happens.
Oh! But I know well :-) in 99.9% of cases, it is a BAD makeup of
faxdata (from faxsoftware or even the software which has converted the
raw data)!
Other reason might be a fault in transmission of faxdata from DTE to
DCE via seriell communication line to modem.
Try to use a multitasking and MULTITHREADED operating system!
>| I'm afraid this is a very common mode of failure between faxmodems and fax
>| machines (EOP errors). I see it quite often with ZyXel modems, less often
>| with Multitech.
See above ...
>|
>| If you have the energy, pursue this on the HylaFAX mailing list, with the
>appropriate logfiles,
I will try Hylafax and look what's happened there ...
Herzliche Gruesse
Dr. Harald Pollack
------- End of Forwarded Message