Re: [hylafax-users] COMREC Recieved DCN

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2004.12.15 12:53 Stephen Carville wrote:

> Dec 15 11:26:10.50: [23299]: RECV training at v.17 14400 bit/s
> Dec 15 11:26:10.50: [23299]: <-- [11:AT+FRM=145\r]
> Dec 15 11:26:12.26: [23299]: --> [7:CONNECT]
> Dec 15 11:26:13.82: [23299]: RECV: TCF 2784 bytes, 0% non-zero, 2775
> zero-run
> Dec 15 11:26:13.82: [23299]: --> [10:NO CARRIER]

Okay, so this indicates that the lines are "clean".  At least for the 
1.5 seconds that constituted this TCF signal.

> Dec 15 11:26:13.82: [23299]: DELAY 75 ms
> Dec 15 11:26:13.90: [23299]: TRAINING succeeded
> Dec 15 11:26:13.90: [23299]: <-- [9:AT+FTH=3\r]
> Dec 15 11:26:14.91: [23299]: --> [7:CONNECT]
> Dec 15 11:26:15.35: [23299]: --> [2:OK]
> Dec 15 11:26:15.35: [23299]: <-- [11:AT+FRM=146\r]
> Dec 15 11:26:16.13: [23299]: --> [7:CONNECT]
> Dec 15 11:26:16.13: [23299]: RECV: begin page
> Dec 15 11:26:33.57: [23299]: RECV: 1088 total lines, 10 bad lines, 10
> consecutive bad lines
> Dec 15 11:26:33.57: [23299]: RECV: REJECT page quality, 10-line run
> (max 5)
> Dec 15 11:26:33.57: [23299]: RECV: end page

Your logging is not set high enough ("SessionTracing: 0xFFF" would do 
it) to know where that 10-line run is, so that I could speculate on why 
it is there and how it could be fixed.

> Dec 15 11:26:44.94: [23299]: RECV: begin page
> Dec 15 11:26:57.65: [23299]: RECV: 1093 total lines, 19 bad lines, 19
> consecutive bad lines
> Dec 15 11:26:57.65: [23299]: RECV: REJECT page quality, 19-line run
> (max 5)
> Dec 15 11:26:57.65: [23299]: RECV: end page

See, here it is again, but this time a 19-line run.

> Dec 15 11:26:59.30: [23299]: <-- [9:AT+FTH=3\r]
> Dec 15 11:27:00.40: [23299]: --> [7:CONNECT]
> Dec 15 11:27:00.92: [23299]: --> [2:OK]
> Dec 15 11:27:00.92: [23299]: RECV send RTN (retrain negative)
> Dec 15 11:27:00.92: [23299]: <-- [9:AT+FRH=3\r]
> Dec 15 11:27:01.34: [23299]: --> [7:CONNECT]
> Dec 15 11:27:02.54: [23299]: --> [2:OK]
> Dec 15 11:27:02.54: [23299]: RECV recv DCN

What happened here was that there was a discrepancy between how HylaFAX 
interprets the RTN signal and how the sender interprets it.

HylaFAX thinks that RTN means "page was unacceptable, please retrain 
and resend".  The sender thinks that RTN means "that page doesn't look 
very good, please retrain before you send me the next one".  The 
difference being that HylaFAX discards the rejected pages while the 
sender thinks that they're not being discarded.

If the sender supports ECM then upgrading to 4.2.0 would get you ECM 
support, and it may work around this problem altogether.  Of course, 
I'd love to see the problem resolved, whatever it is, but I'll need 
more detailed logs to be able to tell you what's going on and to 
propose a fix.

As for the discrepancy between HylaFAX's interpretation of RTN and that 
of this sender (many of them are like this)... well, I've previously 
looked into what coding changes would need to take place to make that 
happen, and it's not as easy as I had hoped it would be.  See the 
Bugzilla report on the "SaveUnconfirmedPages" config option (Bug 420) 
if you care to know more about that.

Thanks.

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@xxxxxxxxx*