HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Hello esteemed hylafax gurus,

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. Here's the relevant config.ttyds<nn> (identical for all channels):

CountryCode:            44
AreaCode:               1628
FAXNumber:              3842XX
LongDistancePrefix:     0
InternationalPrefix:    00
DialStringRules:        "etc/dialrules"
ServerTracing:          0xfff
SessionTracing:         0xfff
RecvFileMode:           0600
LogFileMode:            0600
DeviceMode:             0600
RingsBeforeAnswer:      2                                      <------------------ Correct, yes?
SpeakerVolume:          off
#GettyArgs:             "-h %l dx_%s"
GettyArgs:              "-b -r -s %s %l"
LocalIdentifier:        "HylaFax -Diva Server"
TagLineFont:            etc/lutRS18.pcf
TagLineFormat:          "From %%l|%c|Page %%P of %%T"
MaxRecvPages:           1000
#
#

ModemType:              Class2
ModemRate:              57600   # Diva Server supports V.34-fax
ModemFlowControl:       rtscts
ModemNoFlowCmd:         AT&K0
ModemSoftFlowCmd:       AT&K4
ModemHardFlowCmd:       AT&K3

Class2APQueryCmd:       none
Class2SPLCmd:           none
Class2TBCCmd:           none
Class2ECMType:          2.0     # follows Class 2.0 spec, not Class 2
Class2UseHex:           true
Class2PHCTOCmd:         none

ModemResetCmds:         AT#CID=14
# Put the Destination Address in CIDNumber. We can the reject calls on the basis
# Of where we are sending them, instead of the Caller ID
CIDNumber:              "DAD: "
CIDName:                "CID: "
QualifyCID:             etc/cid         # CID access control list file

Now, in the /var/log/messages file, I get the following after each call when the modem resets:

Dec 10 17:37:20 pri-faxserver FaxGetty[31684]: <-- [5:ATH0\r]
Dec 10 17:37:20 pri-faxserver FaxGetty[31684]: --> [2:OK]
Dec 10 17:37:20 pri-faxserver FaxGetty[31684]: MODEM set DTR OFF
Dec 10 17:37:21 pri-faxserver FaxGetty[31684]: MODEM set DTR OFF
Dec 10 17:37:21 pri-faxserver FaxGetty[31684]: DELAY 75 ms
Dec 10 17:37:21 pri-faxserver FaxGetty[31684]: MODEM set DTR ON
Dec 10 17:37:21 pri-faxserver FaxGetty[31684]: DELAY 2600 ms
Dec 10 17:37:25 pri-faxserver FaxGetty[31684]: MODEM set baud rate: 57600 baud, input flow RTS/CTS, output flow RTS/CTS
Dec 10 17:37:25 pri-faxserver FaxGetty[31684]: DELAY 10 ms
Dec 10 17:37:25 pri-faxserver FaxGetty[31684]: MODEM flush i/o
Dec 10 17:37:25 pri-faxserver FaxGetty[31684]: <-- [4:ATZ\r]
Dec 10 17:37:25 pri-faxserver FaxGetty[31684]: --> [3:ATZ]
Dec 10 17:37:25 pri-faxserver FaxGetty[31684]: --> [2:OK]
Dec 10 17:37:25 pri-faxserver FaxGetty[31684]: DELAY 3000 ms
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: MODEM flush i/o
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: <-- [10:AT#CID=14\r]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [9:AT#CID=14]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [2:OK]
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?
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [2:OK]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: <-- [5:ATE0\r]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [4:ATE0]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [2:OK]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: <-- [5:ATV1\r]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [2:OK]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: <-- [5:ATQ0\r]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [2:OK]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: <-- [7:ATS8=2\r]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [2:OK]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: <-- [8:ATS7=60\r]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [2:OK]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: <-- [6:AT&K3\r]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [2:OK]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: <-- [12:AT+FCLASS=?\r]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [9:0,1, 1.0,2]
Dec 10 17:37:28 pri-faxserver FaxGetty[31684]: --> [2:OK]


When I dial the fax server with a regular phone, it picks up and starts squealing without any rings beforehand.  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


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.

Thanks,
Dan Bonelli
Global Information Technologies




Project hosted by iFAX Solutions