Re: [hylafax-users] [Fwd: facsimile not received]

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2003.12.09 06:56 Steven Kurylo wrote:
> Below is the log of a fax that didn't work.  However the other end 
> says the fax did go through; they repeated it several times.  Its 
> hylafax 4.1.7 with a USR modem in class 1.  I have a multitech modem 
> on the way, will that fix these kinds of errors?   Thanks.
>
> An attempt to receive facsimile on ttyS0 failed because:
>
>    COMREC received DCN
>
>    ---- Transcript of session follows ----
>
> Dec 08 15:00:27.20: [10358]: SESSION BEGIN 00002601 XXXXXXXX
> Dec 08 15:00:27.20: [10358]: HylaFAX (tm) Version 4.1.7
> Dec 08 15:00:27.20: [10358]: <-- [4:ATA\r]
> Dec 08 15:00:32.75: [10358]: --> [7:CONNECT]
> Dec 08 15:00:32.75: [10358]: ANSWER: FAX CONNECTION  DEVICE 
> '/dev/ttyS0'
> Dec 08 15:00:32.75: [10358]: RECV FAX: begin
> Dec 08 15:00:32.78: [10358]: --> [7:CONNECT]
> Dec 08 15:00:34.73: [10358]: --> [2:OK]
> Dec 08 15:00:34.73: [10358]: <-- [9:AT+FRH=3\r]
> Dec 08 15:00:37.83: [10358]: --> [0:]
> Dec 08 15:00:37.83: [10358]: MODEM <Empty line>
> Dec 08 15:00:37.84: [10358]: --> [2:OK]
> Dec 08 15:00:37.84: [10358]: DELAY 1500 ms
> Dec 08 15:00:39.34: [10358]: <-- [9:AT+FTH=3\r]
> Dec 08 15:00:39.38: [10358]: --> [7:CONNECT]
> Dec 08 15:00:39.41: [10358]: --> [7:CONNECT]
> Dec 08 15:00:41.46: [10358]: --> [2:OK]
> Dec 08 15:00:41.46: [10358]: <-- [9:AT+FRH=3\r]
> Dec 08 15:00:42.29: [10358]: --> [7:CONNECT]
> Dec 08 15:00:43.74: [10358]: --> [2:OK]
> Dec 08 15:00:43.74: [10358]: REMOTE TSI "XXXXXXXX"
> Dec 08 15:00:43.74: [10358]: <-- [9:AT+FRH=3\r]
> Dec 08 15:00:43.76: [10358]: --> [7:CONNECT]
> Dec 08 15:00:44.11: [10358]: --> [2:OK]
> Dec 08 15:00:44.11: [10358]: REMOTE wants 9600 bit/s
> Dec 08 15:00:44.11: [10358]: REMOTE wants page width 1728 pixels in 
> 215 mm
> Dec 08 15:00:44.11: [10358]: REMOTE wants unlimited page length
> Dec 08 15:00:44.11: [10358]: REMOTE wants 3.85 line/mm
> Dec 08 15:00:44.11: [10358]: REMOTE wants 2-D MR
> Dec 08 15:00:44.11: [10358]: RECV training at v.29 9600 bit/s
> Dec 08 15:00:44.11: [10358]: <-- [10:AT+FRM=96\r]
> Dec 08 15:00:44.46: [10358]: --> [7:CONNECT]
> Dec 08 15:00:46.03: [10358]: RECV: TCF 1892 bytes, 4% non-zero, 1806 
> zero-run
> Dec 08 15:00:46.03: [10358]: --> [10:NO CARRIER]
> Dec 08 15:00:46.03: [10358]: DELAY 75 ms
> Dec 08 15:00:46.11: [10358]: TRAINING succeeded
> Dec 08 15:00:46.11: [10358]: <-- [9:AT+FTH=3\r]
> Dec 08 15:00:46.31: [10358]: --> [7:CONNECT]
> Dec 08 15:00:47.48: [10358]: --> [2:OK]
> Dec 08 15:00:47.48: [10358]: <-- [10:AT+FRM=96\r]
> Dec 08 15:00:48.35: [10358]: --> [7:CONNECT]
> Dec 08 15:00:48.35: [10358]: RECV: begin page
> Dec 08 15:01:22.61: [10358]: RECV: 1096 total lines, 6 bad lines, 6 
> consecutive bad lines
> Dec 08 15:01:22.61: [10358]: RECV: REJECT page quality, 6-line run 
> (max 5)
> Dec 08 15:01:22.61: [10358]: RECV: end page

The copy quality checking mechanism is rejecting the page due to 6 
consecutive rows of corrupt image data.  Those are probably just RTC, 
and it may be slightly messed up and so the decoder is counting the 
EOLs that make up RTC as scanline EOLs instead, and thus coming up with 
6 lines of corrupt image data.  If you turn SessionTracing up to 0xFFF 
I could tell you more.  If it is what I think it is, then HylaFAX CVS 
HEAD will not have this problem.  Otherwise you can just turn your 
MaxConsecutiveBadLines up to 6 (from 5).

> Dec 08 15:01:22.72: [10358]: --> [10:NO CARRIER]
> Dec 08 15:01:22.72: [10358]: <-- [9:AT+FRH=3\r]
> Dec 08 15:01:23.08: [10358]: --> [7:CONNECT]
> Dec 08 15:01:23.86: [10358]: --> [2:OK]
> Dec 08 15:01:23.86: [10358]: RECV recv EOP (no more pages or 
> documents)
> Dec 08 15:01:23.86: [10358]: <-- [9:AT+FRS=7\r]
> Dec 08 15:01:23.97: [10358]: --> [2:OK]
> Dec 08 15:01:23.97: [10358]: <-- [9:AT+FTH=3\r]
> Dec 08 15:01:24.17: [10358]: --> [7:CONNECT]
> Dec 08 15:01:25.34: [10358]: --> [2:OK]
> Dec 08 15:01:25.34: [10358]: RECV send RTN (retrain negative)

Without the logging at 0xFFF I can only trust that HylaFAX sent the RTN 
frame as it says it did.  But, assuming that is true (and it probably 
is)...

> Dec 08 15:01:25.34: [10358]: <-- [9:AT+FRH=3\r]
> Dec 08 15:01:25.93: [10358]: --> [7:CONNECT]
> Dec 08 15:01:26.69: [10358]: --> [2:OK]
> Dec 08 15:01:26.69: [10358]: RECV recv DCN

... this means that the sender interpreted our RTN signal (which means 
that we reject the last page sent and want the sender to retransmit) as 
MCF or they are simply ignoring it.  The "fault" here lies with the 
sender failing to follow T.30 fax protocol.  However, most fax machines 
will still print out the rejected page in this scenario anyway, and so 
the developer/manufacturer of the sending fax machine could be fooled 
into thinking that it does work "correctly" if they didn't actually pay 
close enough attention.

A change has been made to HylaFAX CVS HEAD called 
SaveUnconfirmedPages.  It will cause HylaFAX to save this page (even 
though we rejected it) rather than deleting it.

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxxxxx*