Re: [hylafax-users] Eicon Diva Server ignores RingsBeforeAnswer in config file

["Dan Bonelli" <mccroskey42@xxxxxxxxx>]

Lee,

Thanks for the quick reply!  I checked in /var/log/messages, and sure enough there were the requisite number of RING messages.  I'd been operating under the assumption that the rings were set by the auto-answer.  Caveat ignoramus.

>> Where are you counting rings?  You have to look at your
>> /var/log/messages and count RING messages there.  You should also see
>> the Caller*ID information there.

The rings I was attempting to count were audible rings that I expected to hear when I dialed it with my cellphone, not the entries in the log files.  /var/log/messages is saying that there are two rings, but I hear dead silence for a second or two, then the fax squeal, when I call.  When the log says 'RING' twice, I'm assuming that there should be an annoying ringing sound made somewhere, right?  My (admittedly uninformed) theory is that the lack of an audible ring is what's causing the remote machine to hang up, because the remote machine comes back with a report that says our line is busy, even though I can see them connect in the log files.  

>> The Diva Server (or an intermediate PBX or telco switch) would need to
>> produce the audible ring, if it is needed/wanted.

The Diva in question is hooked straight into the wall sans PBX, so I'm
talking straight to the telco switch.  This would be set up down in the
Diva driver settings, and not in Hylafax, right?

>> it certainly is a possibility.  One would think that if the Xerox MFPs
>> are listening for ringback that they'd also be listening for CED.

Pardon the telco ignorance, but what is CED?  I'm guessing it's whatever mechanism the machine uses to determine if it's connected in lieu of listening for rings. 

As to the caller ID issue (which I should have pointed out doesn't always occur in tandem with the handshake dropping problem), I checked out some of the instances where the caller ID's didn't show, and they look like so:

Dec 10 04:56:11 pri-faxserver FaxGetty[31684]: STATE CHANGE: RUNNING -> LISTENING
Dec 10 04:56:11 pri-faxserver FaxGetty[31684]: --> [4:RING]
Dec 10 04:56:11 pri-faxserver FaxGetty[31684]: --> [5:CID: ]                        <------ incoming caller ID?
Dec 10 04:56:11 pri-faxserver FaxGetty[31684]: --> [12:DAD: <snip>]
Dec 10 04:56:11 pri-faxserver FaxGetty[31684]: --> [4:RING]
Dec 10 04:56:11 pri-faxserver FaxGetty[31684]: ANSWER: Call ID 1 "<snip>"
Dec 10 04:56:11 pri-faxserver FaxGetty[31684]: ANSWER: Call ID 2 ""

The log looks the same as all the other inbound faxes, the only difference being that CID has something there.  Aside from the client just not sending the CID info (
e.g. blocked ID), is there any other Hylafax or modem-related reason that would account for it not showing up all the time?  If not, I'm stuck calling 60 extremely irritable doctors and their even more cantankerous nursing staff and asking them to fax something to my cellphone to see what, if any, caller ID comes up.  I fear, however, that that's my only other debugging option.  Good times!

Thanks again for your help!

Dan Bonelli
Global Information Technologies

On Dec 11, 2007 5:13 PM, Lee Howard <faxguy@xxxxxxxxxxxxxxxx > wrote:

Dan Bonelli wrote:
> I've been having a weird recurring problem with my Eicon Diva Server
> board (24 channel T-1).  I'm running hylafax-4.3.3-1fc5 on Fedora Core
> 5.  I have set the RingsBeforeAnswer parameter to two rings per
> Eicon's website, but for some reason Hylafax isn't passing that along
> to the fax board.

> RingsBeforeAnswer:      2
> <------------------ Correct, yes?

Yes.

> QualifyCID:             etc/cid         # CID access control list file

This is obsolete.  You can just delete it, it's doing nothing for you.
QualifyCID was obsoleted by DynamicConfig's RejectCall.

> Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: <-- [7:ATS0=0\r]
> Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: -->
> [6:ATS0=0]                   <--------------------- This is rings
> before answer=0, yes?

No.  ATS0 indicates *auto-answer*, and we don't want the modem to
auto-answer.  Instead, HylaFAX answers with ATA based on the number of
received RING messages coming from the modem.

> When I dial the fax server with a regular phone, it picks up and
> starts squealing without any rings beforehand.

Where are you counting rings?  You have to look at your
/var/log/messages and count RING messages there.  You should also see
the Caller*ID information there.

> Some of the calls come in sans caller ID, and a good percentage
> (around 10%) are hanging up before the handshake, turning up in the
> logs as either a 'Ring detected without successful handshake' or a 'No
> loop current' (numbers removed to protect the innocent):
>
> Dec 11 13:44:48.75: [14908]: SESSION BEGIN 000032286 <snip>
> Dec 11 13:44:48.75: [14908]: HylaFAX (tm) Version 4.3.3
> Dec 11 13:44: 48.75: [14908]: CallID: "<snip>" "<snip>"
> Dec 11 13:44:48.75: [14908]: <-- [4:ATA\r]
> Dec 11 13:45:26.03: [14908]: --> [8:+FHNG: 3]
> Dec 11 13:45:26.04: [14908]: REMOTE HANGUP: No loop current (code 3)
> Dec 11 13:45:26.04: [14908]: ANSWER: Ring detected without successful
> handshake
> Dec 11 13:45:26.04: [14908]: SESSION END

You'll need to look at Diva Server debugging tools/utilities to get at
the root of the problem here.  Most likely this is something for which
you're going to have to turn to Eicon.

> I don't know if getting the modem to wait for a ring will help with
> the failed calls, but it's pretty much the only weird thing I've seen
> that could account for that large a percentage of failed handshakes.
> Most (but, of course, not all) the affected sites have a similar range
> of Xerox MFP's, so my pet theory is that their unit is a little
> finicky about the remote machine being quick on the draw.  This is, of
> course, a wild ass guess, and as I'm at a loss as to how to proceed in
> convincing Hylafax that, yes, I really do want 2 rings. Any help or
> insights would be greatly appreciated.

It's unlikely that a lack of audible rings is causing the problem, but
it certainly is a possibility.  One would think that if the Xerox MFPs
are listening for ringback that they'd also be listening for CED.

The Diva Server (or an intermediate PBX or telco switch) would need to
produce the audible ring, if it is needed/wanted.

Thanks,

Lee.