Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] hylafax-4.1_1 with, mutltiple modems -and- cid/logging (Important)
-- 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.*