Just a simple thought for testing purposes.
Using the TDM410, what about putting a line splitter on each line and
either putting a callerID box or phone with callerid on each split. This
way when the call comes in, you can easily check when no ID is passed by
asterisk, you can pop over and see if it appeared on the phone/callerid box.
If it did appear, you know that it was transmitted and that the asterisk
box did wait long enough to have it transmitted between the 1st & 2nd
ring cycle. If it was not on the phone it will narrow it down to either
not transmitted or not a long enough wait on the answer cycle. You can
then lengthen out the answer cycle to see if that corrects it.
By doing this simple test and using a local line and a remote line to
simulate the long distance characteristics you should be able to quickly
narrow down the culprit.
Mike
Steven McCann wrote:
Hi Guys,
Thanks for your help so far. There's definetly some good ideas here to try
out... I will see what I can do to try them out and get a better idea of
what is going on when someone is calling in.
I'm quite sure that we're getting call ID as I can see it came on most calls
when a fax machine was hooked up to the line... It will be interesting to
see when it's coming when it's a local vs long-distance call.
The CID comes up for most local numbers, and it does for a few long-distance
calls also.. I will see if I can find the variable thing happening there...
Thanks,
Steven
On Wed, Aug 20, 2008 at 5:25 PM, Syd Carter <[EMAIL PROTECTED]> wrote:
I encounter the same problem with my WCFXO card. You can monitor the pots
line using zmonitor. You will be able to save the audio (including FSK
tones) to a file for analysis. I gave up trying to solve this, the caller
id is being sent yet for long distance calls it doesn't get interpreted
correctly. I believe you will need to recode callerid.c to solve this. I
just resorted to using a spa3000 that I had lying around to do the caller id
decoding. Used distintive ring detection in zapata.conf to branch execution
to the spa3k context when the call was long distance.
Jim Van Meggelen wrote:
You need to get a butt set and monitor the line to determine whether you
are
even getting caller id. It will be in a 300 baud FSK signal (if you've
ever
heard a modem trying to handshake you'll immediately recognize the sound).
CallerID is delivered between the first and second ring cycle (usually).
The
key here is ring cycle, not rings. Do you ever get long distance calls on
that line where there are two rings, then a pause, then two rings ... etc?
That'll screw up asterisk because it'll listen for clid after the first
ring, not realizing that the first ring cycle has not net .completed (a
ring
cycle is 6 seconds, regardless of how many rings).
Anyway, this probably sounds all whacked out. Bottom line: if you can
borrow
or buy a butt set (get one on ebay and when you're done just put it back
up
and sell it to the next guy), you'll be able to figure out what those
lines
are doing, and thus report the trouble correctly to Bell. The key with a
butt set is that it can listen on the line without interfering, which
means
you can hear what Bell is sending, and what your system is doing.
Jim
--
Mike Ashton
Quality Track Intl
Ph: 647-722-2092 x 301
Cell: 416-527-4995
Fax: 416-352-6043
QTI CONFIDENTIAL AND PROPRIETARY INFORMATION
The contents of this material are confidential and proprietary to Quality Track
International, Inc.
and may not be reproduced, disclosed, distributed or used without the express
permission of an authorized representative of QTI.
Use for any purpose or in any manner other than that expressly authorized is
prohibited.
If you have received this communication in error, please immediately delete it
and all copies, and promptly notify the sender.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
