Hi All, I found a workaround for the problem. There's a page of phone code features from Bell here: http://www.bell.ca/support/PrsCSrvPns_STSHelp_Guide.page
The feature *49 = deactivate long distance call notification I did this on the lines, and now CID is coming in on all calls. Yipee! Thanks for everyone's help! Steven On Thu, Aug 21, 2008 at 11:56 AM, Mike Ashton <[EMAIL PROTECTED]>wrote: > 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]> <[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] >
