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] Route incommin faxes to manual machine
precioso arabche wrote:
I attached some of the error logs hopefully indicative of the errors
(zip file).
Im using debian sarge + hylafax 4.2.1 + Multimodem 5634 ZBA in class 1
mode. default configuration.
c000003042: looks like a non-fax caller or the caller hung up after the
answer occurred... if it was a fax machine calling and if it is
reproducible, then the modem manufacturer will need to address this
c000003072: this actually isn't so much a failure as it is a difference
in opinion as to what the RTN signal means. The sender delivered a page
of unacceptable quality, and HylaFAX sent an RTN signal in hopes of
getting the sender to retransmit. The sender, however, hung up
instead. This is (unfortunately) not uncommon... and not so much an
indication of error.
c000003092: this looks like a sender abort (meaning the sender
intentionally aborted the fax transmission). If this is reproducible,
then please find out what the sender is doing to trigger it, and let us
know.
c000003093: same thing as c000003092
c000003127: same thing as c000003092, c000003093
c000003171: this "error" is fixed in 4.2.2 and later versions (by
better-handling +FCERROR conditions)
c000003187: this looks like a sender abort (a different kind), again, if
it's reproducible, then please find out what the sender is doing to
trigger it and let us know
c000003197: same as c000003171, fixed in 4.2.2
c000003260: same as c000003072
c000003271: again, fixed in 4.2.2
c000003274: I'm not sure about this one... at 4800 bps there was
probably some interference
c000003321: again, fixed in 4.2.2
c000003321: again, fixed in 4.2.2 (all of these +FCERROR ones are the
same thing)
c000003325: again, 4.2.2
c000003326: 4.2.2
c000003333: it looks like another sender abort
c000003352: 4.2.2
c000003025: 4.2.2
c000003026: sender abort
c000003027: I'm not sure about this one, it would appear that the sender
signalled V.29 but sent something else, but my guess is that the sender
just needs to power-cycle their fax machine. I'd have to see more of
this to say.
c000003033: this looks like c000003042... a non-fax call or a caller
that disconnected just after the answer
In conclusion... you really should upgrade to 4.2.3 to get the various
benefits found in the 4.2.2 release... should ease all of the +FCERROR
mess... but the only logs that prove to be "concerning" at all are
c000003027 and c000003274.
I would strongly suggest that you not do as you were wanting... to
redirect these calls to your fax machine. Upgrade, and that will solve
half of the problem. After that, you need to actually communicate with
the sender to conclude that the call was, indeed, an error worth fussing
over. Then I think that you'll find that you will have VERY few true
errors.
But i keep the manual fax machine on the same line, it is setup to
answer after 4 rings, while hylafax picks up after 1 ring. is there
any way to tell hylafax not to pick up for certain numbers / senders?
Yes, see 'man callid' (or 'man cid'), but again, I don't recommend that
you do this.
is this setup (manual & hylafax on the same line) erroneous ? it
seemed to work ok so far..
I have customers that use a fax machine on the same line as HylaFAX.
The fax machine is used for sending and is set to never answer. It
seems to work fine for them there.
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*