Re: [hylafax-users] different problems to same destination

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Martin wrote:

> Feb 10 08:32:45.33: [ 8576]: SESSION BEGIN 000020204 1905679xxxx
> Feb 10 08:32:45.33: [ 8576]: HylaFAX (tm) Version 4.2.0
> Feb 10 08:32:45.33: [ 8576]: SEND FAX: JOB 20095 DEST 905-679-xxxx 
> COMMID 000020204 DEVICE '/dev/ttyS5'
> Feb 10 08:32:45.34: [ 8576]: <-- [14:AT+FCLASS=1.0\r]
> Feb 10 08:32:45.45: [ 8576]: --> [2:OK]
> Feb 10 08:32:45.45: [ 8576]: <-- [14:AT+F34=14,1,2\r]
> Feb 10 08:32:45.56: [ 8576]: --> [2:OK]
> Feb 10 08:32:45.56: [ 8576]: DIAL 1905679xxxx
> Feb 10 08:32:45.56: [ 8576]: <-- [16:ATDT1905679xxxx\r]
> Feb 10 08:33:02.80: [ 8576]: --> [7:CONNECT]
> Feb 10 08:33:04.05: [ 8576]: --> [2:OK]
> Feb 10 08:33:04.05: [ 8576]: REMOTE NSF "86 00 8C 00 00 C0 00"
> Feb 10 08:33:04.05: [ 8576]: NSF remote fax equipment: Samsung
....
> Feb 10 08:33:05.13: [ 8576]: SEND training at v.17 14400 bit/s
....
Feb 10 08:33:11.89: [ 8576]: SEND training at v.17 12000 bit/s
....
> Feb 10 08:33:18.66: [ 8576]: SEND training at v.17 9600 bit/s
....
> Feb 10 08:33:25.43: [ 8576]: SEND training at v.29 9600 bit/s
....
> Feb 10 08:33:31.25: [ 8576]: TRAINING succeeded

This kind of thing (where training with all baud rates of V.17 from 
14400 through 9600 fail and then V.29 9600 succeeds) is indicative of a 
modulator incompatibility between your modem and the receiver 
(Samsung).  If the Samsung modulator isn't broken completely, then it's 
something that a firmware fix could fix.  (It's probably a waste of 
time for HylaFAX to even bother with V.17 9600 ever, but nonetheless we 
still attempt it in training.)

> Feb 10 08:43:35.30: [ 8576]: SEND recv MCF (message confirmation)
> Feb 10 08:43:35.30: [ 8576]: <-- [9:AT+FRS=7\r]
> Feb 10 08:43:35.45: [ 8576]: --> [2:OK]
> Feb 10 08:43:35.47: [ 8576]: SEND send frame number 0
....
> Feb 10 08:43:35.78: [ 8576]: SEND send frame number 255
> Feb 10 08:43:35.78: [ 8576]: DELAY 200 ms
> Feb 10 08:43:35.98: [ 8576]: <-- [10:AT+FTM=96\r]
> Feb 10 08:43:35.99: [ 8576]: --> [7:CONNECT]
> Feb 10 08:43:35.99: [ 8576]: DELAY 400 ms
> Feb 10 08:44:33.07: [ 8576]: --> [2:OK]
> Feb 10 08:44:33.07: [ 8576]: <-- [9:AT+FTS=9\r]
> Feb 10 08:44:33.15: [ 8576]: --> [2:OK]
> Feb 10 08:44:33.15: [ 8576]: <-- [9:AT+FTH=3\r]
> Feb 10 08:44:34.11: [ 8576]: --> [7:CONNECT]
> Feb 10 08:44:34.61: [ 8576]: --> [2:OK]
> Feb 10 08:44:34.61: [ 8576]: SEND send PPS (partial page signal)
> Feb 10 08:44:34.61: [ 8576]: SEND send NULL (more blocks, same page)
> Feb 10 08:44:34.61: [ 8576]: <-- [9:AT+FRH=3\r]
> Feb 10 08:44:34.77: [ 8576]: --> [7:CONNECT]
> Feb 10 08:44:35.92: [ 8576]: --> [2:OK]
> Feb 10 08:44:35.92: [ 8576]: SEND recv DCN (disconnect)

Up to this point you sent 4 pages completely fine, without any 
problem.  So all that this kind of behavior from the receiver tells us 
is what the log tells us, and that is that for some reason the receiver 
chose to disconnect rather than confirming the image data block or 
requesting it to be retransmitted.  A receiver could do this for 
several reasons.  If it is an error on the sending end, it is 
indicative that some data that was transmitted was not valid fax image 
data per the negotiated session parameters (i.e. faxq created some 
bogus TIFF data at that point in the image) - so the data was 
transmitted and received just fine, but the data itself was not usable 
by the receiver.  If it is an error on the receiver, then it is 
probably an indication of a bug in the receiver's firmware.

The other error that you posted looks like a very similar situation, 
except instead of DCN the receiver just didn't respond.  Same reasoning 
applies as if you had gotten DCN.

I will say this, though... you're sending some *large* amounts of data 
on a single page.  One page had over 192 KB of data on it.  With MMR 
compression that comes to a rather large set of data - lots of gray 
perhaps, dithering perhaps.  Unless you're doing this knowingly, then 
it's probably bad fax image preparation.  You may be able to avoid 
problems by reducing the image size.  Perhaps sending with normal 
resolution (rather than fine) would help that.

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*