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 Error rates



On 2004.07.29 12:40 Stephen Carville wrote:
On Thu July 29 2004 11:53 am, Lee Howard wrote:
> On 2004.07.29 11:01 Stephen Carville wrote:

> > Jul 29 07:00:30.66: [25453]: RECV send RTN (retrain negative)
> > Jul 29 07:00:30.66: [25453]: <-- [9:AT+FRH=3\r]
> > Jul 29 07:00:31.86: [25453]: --> [7:CONNECT]
> > Jul 29 07:00:31.99: [25453]: --> [2:OK]
> > Jul 29 07:00:31.99: [25453]: RECV recv DCN
>
> Did the sender call back and retransmit that page and the following
> ones?

Not as far as I can tell. Should this be an automated response?

Yes, it should. Each fax machine may work differently, but the sender certainly did not get a page-received confirmation, so (worst-case scenario of intelligent behavior) they may have seen some error on the fax machine indicating that they needed to re-send the fax. Normally an intelligent fax machine will do this on its own.


If
it
requires the sender to actually read the fax report and retransmit the
page
it may be hopeless with some of our customers.

That may be the case, and if it is, then you may have no recourse except to phone the sender and tell them to retransmit.


Note that if the sender's machine supports ECM, then you will be much better-served in these kinds of scenarios by using ECM yourself (i.e. Class 1 in HylaFAX 4.2.0). The whole design of ECM protocol is more resiliant than without it. Senders seem to tolerate a PPR (resend some portions of the page, only available in ECM) signal much more readily than an RTN (retrain and resend all of the page, only available in non-ECM) signal.

Clients really disreagard the specifications? Who'da thunk it...

Normally we can work around most fax machines misbehaviors in Class 1 (Class 2 is up to the modem manufacturer). However, when acting as the receiver and we have received a corrupted page and the sender is awaiting a response to it's post-page signal, we have limited choices: MCF (confirm receipt), RTN (reject page, request retrain and retransmit), DCN (disconnect), or hang up. Confirming bad pages (doing MCF) would be the worst mistake we could do. Hanging up or disconnecting would probably get the idea across, but at least sending RTN will permit a spec-following intelligent sender to cope.


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*




Project hosted by iFAX Solutions