HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Neil Doody wrote:

Can I see the log?


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.


____________________ 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*

Project hosted by iFAX Solutions