Re: [hylafax-users] High page count faxes failing

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Neil Doody wrote:

> > Can I see the log?
> >
> > Lee.
> >    
>
>
> Log is attached.
>  

The sender is broken.

> Jun 27 17:26:05.38: [66268]: Primary channel rate now 4800 bit/s

SuperG3 isn't doing this call any good at all.  Usually the V.34 
retrains are handled by the two modems involved - retraining is pretty 
much outside of HylaFAX's control here.  Generally one would assume that 
the retrains occur due to the V.34 DSP detecting some problems with the 
current rate and so it moves to slow it down.  But, if you ask me, I 
don't see any reason for the retrains to be occurring in the first 
place.  The data is coming through okay.

So it is possible that the retrains are occurring as a result of the 
modem firmware itself... or it could be done at the request of the 
sender's DSP, too.  Whichever one is doing it - well - it shouldn't be 
doing it.

> Jun 27 17:34:35.35: [66268]: RECV received 156 frames of block 1 of 
> page 35
> Jun 27 17:34:35.35: [66268]: <-- data [35]
> Jun 27 17:34:35.35: [66268]: <-- data [2]
> Jun 27 17:34:35.35: [66268]: RECV send PPR (partial page request)
> Jun 27 17:34:35.93: [66268]: RECV recv EOR (end of retransmission)
> Jun 27 17:34:35.93: [66268]: RECV recv EOP (no more pages or documents)
> Jun 27 17:34:36.17: [66268]: RECV: 39718 bytes of data, 346 total lines
> Jun 27 17:34:36.17: [66268]: <-- data [3]
> Jun 27 17:34:36.17: [66268]: <-- data [2]
> Jun 27 17:34:36.17: [66268]: RECV send ERR (confirm end of retransmission)


According to spec the sender transmitted EOR incorrectly here.  It 
normally should not transmit EOR until after the 4th PPR signal for that 
block.  It gets away with it, of course, but it shouldn't do it, and I 
suspect that if it didn't do it you'd have noticed no problem.  It's 
possible that the sender realizes that it's at 4800 bps already and 
can't go any slower... and so instead of requesting another retrain 
(which it can't do) it essentially aborts the fax with EOR.

Technically EOR is not supposed to abort.  That's DCN's job.  However, 
almost all fax machines use EOR improperly this way.  Technically after 
an EOR/ERR exchange the sender should move on to the next block/page.

So I would suggest trying the same thing with a vastly different V.34 
fax machine model/brand on the other end.  If it goes okay then blame 
the sender.  If it doesn't go okay then blame your modem.  If it is the 
sender's fax machine they should probably just turn off V.34 support... 
as it's causing them more trouble than doing good.

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*