![]() |
-- Annotated below -- ----- Original Message ----- Sent: Thursday, November 07, 2002 12:08 AM Subject: Re: [hylafax-users] hylafax-4.1_1 with, mutltiple modems -and- cid/logging (Important) > > is available within four(4) recent log entries at: > > https://64.81.211.10/issues/hylafax/cid2.txt > > > > To detail your logs... > > Nov 6 12:44:50 imani FaxGetty[118]: STATE CHANGE: RUNNING -> LISTENING > Nov 6 12:44:50 imani FaxGetty[118]: MODEM input buffering enabled > Nov 6 12:44:51 imani FaxGetty[118]: --> [4:RING] > Nov 6 12:45:14 imani last message repeated 4 times > Nov 6 12:45:14 imani FaxGetty[118]: STATE CHANGE: LISTENING -> > ANSWERING > Nov 6 12:45:14 imani FaxGetty[118]: MODEM input buffering enabled > Nov 6 12:45:15 imani FaxGetty[118]: ANSWER: CID REJECTED > > This log clearly shows that the caller-id was not delivered to the > modem or the modem did not report it. I need to look further into this to know for sure if cid-data coming over the wire, or, if something is wrong locally. Only way i know of is to swap the lines my hardware cid-reader is on. This may take some time to confirm but, i will get it done armed with the information you've provided. >However, the first ring at 12:44:51 being only one second after FaxGetty began listening may > indicate that it started listening *after* the RINGs had already > started. > The ring count shown above appears to be correct. Hence it seems faxgetty is listening correctly We have the rings before answer set as shown (below). imani# grep -i 'RingsBeforeAnswer:' /var/spool/hylafax/etc/config.cuaa1 RingsBeforeAnswer: 5 imani# grep -i 'RingsBeforeAnswer:' /var/spool/hylafax/etc/config.cuaa2 RingsBeforeAnswer: 5 imani# grep -i 'RingsBeforeAnswer:' /var/spool/hylafax/etc/config.cuaa3 RingsBeforeAnswer: 10 <-- Voice line; ring count rarely gets to 10. > Note that we receive 5 RINGs between 12:44:51 and 12:45:14 - 23 > seconds. Meaning that each RING is normally less than 5 seconds > apart. However, this log... > > Nov 6 17:14:53 imani FaxGetty[118]: STATE CHANGE: RUNNING -> LISTENING > Nov 6 17:14:53 imani FaxGetty[118]: MODEM input buffering enabled > Nov 6 17:14:53 imani FaxGetty[118]: --> [4:RING] > Nov 6 17:14:54 imani FaxGetty[118]: --> [11:DATE = 1106] > Nov 6 17:14:54 imani FaxGetty[118]: --> [11:TIME = 1715] > Nov 6 17:14:54 imani FaxGetty[118]: --> [8:NMBR = O] > Nov 6 17:14:54 imani FaxGetty[118]: --> [8:NAME = O] > Nov 6 17:14:59 imani FaxGetty[118]: MODEM TIMEOUT: reading line from > modem > Nov 6 17:14:59 imani FaxGetty[118]: <-- [5:ATH0\r] > Nov 6 17:14:59 imani FaxGetty[118]: --> [2:OK] > > seems to indicate that the RING following the caller-id data can arrive > over 6 seconds after the preceding RING. This is a problem. HylaFAX > only waits 6 seconds after a RING to hear another RING before it > reinitializes itself. > If the log is fairly accurate it took eleven(11) seconds before the subsequent [ring] after the cid-data was passed, or, could this very well be some sluggishness within the machine or code where by its not time stamping the log entries accuratly? > If your telco sends any RINGs more than 6 seconds apart, faxgetty will > be unable to answer the call, will reset itself, and if it initializes > quickly enough, it may then pick up on the same call, but later RINGs, > long after the caller-id data was already sent and the long RING delays > have stopped. > This morning I have timed the intervals 'between rings', resulted in four(4) seconds. This was done/tesed with my multiple but, separate Verizon lines. That doesn't speak for other telco's calling Verizon subscribers. This once again points out a possible problem within the above log entry that shows an eleven(11) second lag between the logged cid-data -- that comes in on the second ring, and, the subsequent third ring (took 11 seconds). As stated above... there's a 4-second interval between rings. Where would I look for the missing 6 seconds? > I can send you a patch to resolve the problem above. Can you make use > of a patch or do you need it RPM-ized? > > Lee. > I'd like that (patch) very much if you feel this case warrants the patch. Would you be kind enough to place the patch 'inline' -- I don't do attachments. Please don't be offended. Be advised I've already applied the following: --- faxd/faxGettyApp.h.orig Sun Apr 22 21:51:49 2001 +++ faxd/faxGettyApp.h Sun Apr 22 21:53:18 2001 Applying that patch did help (post install) with getting the cid data. Strangeness prior to that. Not sure if you needed that info. Better safe than sorry. - I'm not able to understand code/program languages as yet. Please describe what your patch does. I can deal with how it works at a later date. Lastly, I believe I should look into this further by swapping the line I have my hardware cid-reader on in order to confirm that there is or is not cid-data coming over the wire or if we have a modem/chipset issue. Given cuaa1, cuaa2 are Aopen/ISA and cuaa3 is a USR, it 'appears' they both use the same chipset. That's another area I know nothing of, and, I'm not sure what (if any) inconsistentcies may be surrounding these modems/chipsets. ____________________ 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@hylafax.org < /dev/null *To learn about commercial HylaFAX(tm) support, mail sales@hylafax.org.*