Re: [hylafax-users] Route incommin faxes to manual machine

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

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*