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*




Project hosted by iFAX Solutions