I have a CallerID issue with two UK customer installs that I would appreciate feedback from anyone that has experienced the same issue. One customer is a BT auxiliary line customer with one number and two lines, the other has a BT line and a couple of Vonage lines. In both cases the lines are connected to an OpenVox A400P card, and the servers are Elastix builds based on Dahdi 2.1.0.4-24 and Asterisk 1.4.25.1-4 (although I have also tried older Dahdi/Asterisk versions).
The issue is that CallerID is unreliable, sometimes it works but sometimes it doesn’t. I tried the usual things like tuning the lines and increasing the RX gain but this didn’t make any difference. Having searched the net it appears that the polarity reversal sometimes causes the card to report a ‘phantom’ ring, which stops the read of the CallerID (as reported here issues.asterisk.org/view.php?id=9264). I tried using the ‘fwringdetect’ module parameter to fix the issue (i.e. modprobe wctdm opermode=UK fwringdetect=1) but it didn’t make any difference. When CID detection fails the log shows the following:
[Jul 18 11:42:04] DEBUG[14087] chan_dahdi.c: Monitor doohicky got event Polarity Reversal on channel 9
[Jul 18 11:42:04] VERBOSE[14087] logger.c: == Starting post polarity CID detection on channel 9
[Jul 18 11:42:04] VERBOSE[14273] logger.c: -- Starting simple switch on 'DAHDI/9-1'
[Jul 18 11:42:05] NOTICE[14273] chan_dahdi.c: Got event 2 (Ring/Answered)...
[Jul 18 11:42:06] DEBUG[14273] chan_dahdi.c: Exception on 19, channel 9
[Jul 18 11:42:06] DEBUG[14273] chan_dahdi.c: Got event Ring Begin(18) on channel 9 (index 0)
[Jul 18 11:42:07] WARNING[14273] chan_dahdi.c: CID timed out waiting for ring. Exiting simple switch
[Jul 18 11:42:07] DEBUG[14273] channel.c: Hanging up channel 'DAHDI/9-1'
[Jul 18 11:42:07] DEBUG[14273] chan_dahdi.c: dahdi_hangup(DAHDI/9-1)
[Jul 18 11:42:07] VERBOSE[14273] logger.c: -- Hungup 'DAHDI/9-1'
[Jul 18 11:42:09] DEBUG[14087] chan_dahdi.c: Monitor doohicky got event Ring Begin on channel 9
[Jul 18 11:42:10] DEBUG[14087] chan_dahdi.c: Monitor doohicky got event Ring/Answered on channel 9
[Jul 18 11:42:10] VERBOSE[14275] logger.c: -- Starting simple switch on 'DAHDI/9-1'
After which the call continues as normal but without CID. After more googling I found a patch (here forums.digium.com/viewtopic.php?p=27484) that forces Asterisk to ignore rings before CID is complete. The patch is for an old version of chan_zap.c and the relevant code has changed since. I implemented the changes in chan_dahdi.c and recompiled Asterisk, after which CID started working reliably:
[Aug 8 00:00:55] DEBUG[13027] chan_dahdi.c: Monitor doohicky got event Ring Begin on channel 9
[Aug 8 00:00:55] DEBUG[13027] chan_dahdi.c: Monitor doohicky got event Polarity Reversal on channel 9
[Aug 8 00:00:55] VERBOSE[13027] logger.c: == Starting post polarity CID detection on channel 9
[Aug 8 00:00:55] VERBOSE[13131] logger.c: -- Starting simple switch on 'DAHDI/9-1'
[Aug 8 00:00:55] NOTICE[13131] chan_dahdi.c: Ignoring event 2 (Ring/Answered) due to waiting for CID,samples=3040
[Aug 8 00:00:56] NOTICE[13131] chan_dahdi.c: CallerID number: 01904XXXXXX, name: (null), flags=4
[Aug 8 00:00:57] DEBUG[13131] chan_dahdi.c: Exception on 19, channel 9
[Aug 8 00:00:57] DEBUG[13131] chan_dahdi.c: Got event Ring Begin(18) on channel 9 (index 0)
[Aug 8 00:00:58] DEBUG[13131] chan_dahdi.c: Exception on 19, channel 9
[Aug 8 00:00:58] DEBUG[13131] chan_dahdi.c: Got event Ring/Answered(2) on channel 9 (index 0)
[Aug 8 00:00:58] DEBUG[13131] devicestate.c: Notification of state change to be queued on device/channel DAHDI/9
[Aug 8 00:00:58] DEBUG[13131] chan_dahdi.c: Ring detected
[Aug 8 00:00:58] VERBOSE[13131] logger.c: -- Executing [s@from-pstn:1] Set("DAHDI/9-1", "__FROM_DID=s") in new stack
[Aug 8 00:00:58] VERBOSE[13131] logger.c: -- Executing [s@from-pstn:2] Gosub("DAHDI/9-1", "app-blacklist-check|s|1") in new stack
[Aug 8 00:00:58] VERBOSE[13131] logger.c: -- Executing [s@app-blacklist-check:1] LookupBlacklist("DAHDI/9-1", "") in new stack
[Aug 8 00:00:58] VERBOSE[13131] logger.c: -- Executing [s@app-blacklist-check:2] GotoIf("DAHDI/9-1", "0?blacklisted") in new stack
[Aug 8 00:00:58] VERBOSE[13131] logger.c: -- Executing [s@app-blacklist-check:3] Return("DAHDI/9-1", "") in new stack
[Aug 8 00:00:58] VERBOSE[13131] logger.c: -- Executing [s@from-pstn:3] ExecIf("DAHDI/9-1", "1 |Set|CALLERID(name)=01904XXXXXX") in new stack
CID does appear to be working reliably now (I haven’t missed one yet), but I would still like to understand if there are any other UK customers that have experienced UK CallerID issues with Dahdi? In the past the majority of servers I have built have been based on Trixbox/Zaptel. It could just be a coincidence, but it seems strange that after switching from Trixbox/Zaptel to Elastix/Dahdi I’ve had two customers in a row with CID detection issues (compared with zero before).
Thanks,
Richard