HylaFAX The world's most advanced open source fax server

[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.*




Project hosted by iFAX Solutions