[Home]

Summary:ASTERISK-17588: Caller ID on TDM410P *UK* PSTN
Reporter:Daniel Flounders (danfloun)Labels:
Date Opened:2011-03-21 14:18:34Date Closed:2011-04-01 14:13:36
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:1.6.2.17 Frequency of
Occurrence
Related
Issues:
is related toASTERISK-24825 Caller ID not recognized using Centrex/Distinctive dialing
Environment:Attachments:
Description:On an incoming call, Asterisk answers the channel before waiting for the caller id retrieve to complete.
This bug occurred on ZAP also and is referenced in more detail on the following links. Patches were created to work around the bug but never officially implemented.

Ref: http://forums.digium.com/viewtopic.php?t=8477
Ref: http://fonality.com/trixbox/forums/trixbox-forums/help/uk-caller-id-issues-dahdi



****** ADDITIONAL INFORMATION ******

Have tried all possible combinations and the problem exists on various distributions I have tried.

/etc/asterisk/chan_dahdi.conf

CODE: SELECT ALL
; DAHDI Telephony Configuration file

; GENERAL -->

[trunkgroups]

[channels]
language=en
context=inbound
usecallerid=yes
cidsignalling=v23
cidstart=polarity
hidecallerid=no
waitfordialtone=yes
callwaiting=no
usecallingpres=yes
sendcalleridafter = 2
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no
callerid = asreceived
useincomingcalleridondahditransfer = yes
answeronpolarityswitch=yes
hanguponpolarityswitch=yes
busydetect=yes
busycount=3
progzone=uk
tonezone=4

;TRUNKS -->

;FXO1
context = pstn-inbound
group = 1                                                                            
signalling = fxs_ks
channel = 1

;FXO2
context = gsm-outbound
group = 2
signalling = fxs_ks
channel = 2

;TEMPLATES -->

[fxs-phones](!)
usecallerid = yes
hidecallerid = no
threewaycalling = yes
transfer = yes
echocancel = yes
echotraining = yes
context = local
signalling = fxo_ks

;PHONES -->

[FXS4](fxs-phones)
callerid = "Ding-Dong-The-PBX-Is-Dead" <(i.e.9999999999>
dahdichan = 4

/etc/dahdi/system.conf

# Dahdi Configuration File
# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)

fxsks=1
echocanceller=mg2,1
fxsks=2
echocanceller=mg2,2
# channel 3, WCTDM/0/2, no module.
fxoks=4
echocanceller=mg2,4

# Global data

loadzone        = uk
defaultzone     = uk

/etc/asterisk/extensions.conf

; extensions.conf - the Asterisk dial plan

; GENERAL -->

[general]
static=yes
writeprotect=no
autofallthrough=yes
clearglobalvars=no
;
;extenpatternmatchnew=no
;priorityjumping=yes
;userscontext=default


; GLOBALS -->

[globals]
ignorepat => 9

; DIALPLAN -->

[default]

[local]
exten => 100,1,Dial(DAHDI/4)

exten => 200,1,Dial(SIP/TEST-SIP)

exten => 1234,1,VoiceMailMain()

[pstn-inbound]
exten => s,1,Dial(DAHDI/4&SIP/TEST-SIP,10)
       same => n,Hangup()

[incoming]
exten => s,1,Dial(DAHDI/4&SIP/TEST-SIP,10)
       same => n,Hangup()

/var/log/messages
Mar 20 15:47:01 localhost kernel: wctdm24xxp 0000:00:0a.0: FW RING on 1/1!
Mar 20 15:47:02 localhost kernel: wctdm24xxp 0000:00:0a.0: 348398 Polarity reversed (-1 -> 1)
Mar 20 15:47:02 localhost kernel: wctdm24xxp 0000:00:0a.0: FW NO RING on 1/1!
Mar 20 15:47:02 localhost kernel: wctdm24xxp 0000:00:0a.0: FW RING on 1/1!
Mar 20 15:47:02 localhost kernel: wctdm24xxp 0000:00:0a.0: FW NO RING on 1/1!
Mar 20 15:47:04 localhost kernel: wctdm24xxp 0000:00:0a.0: FW RING on 1/1!
Mar 20 15:47:05 localhost kernel: wctdm24xxp 0000:00:0a.0: FW NO RING on 1/1!
Mar 20 15:47:05 localhost kernel: wctdm24xxp 0000:00:0a.0: FW RING on 1/1!
Mar 20 15:47:05 localhost kernel: wctdm24xxp 0000:00:0a.0: FW NO RING on 1/1!
Mar 20 15:47:07 localhost kernel: wctdm24xxp 0000:00:0a.0: FW RING on 1/1!
Mar 20 15:47:08 localhost kernel: wctdm24xxp 0000:00:0a.0: FW NO RING on 1/1!
Mar 20 15:47:08 localhost kernel: wctdm24xxp 0000:00:0a.0: FW RING on 1/1!
Mar 20 15:47:08 localhost kernel: wctdm24xxp 0000:00:0a.0: 354983 Polarity reversed (1 -> -1)
Mar 20 15:47:08 localhost kernel: wctdm24xxp 0000:00:0a.0: FW NO RING on 1/1!
Comments:By: iasgoscouk (iasgoscouk) 2011-03-21 14:30:01

I am in the UK, and have TDM410P, single FXO, and have no problems with callerid.    I did have.

Will check through your settings and compare with mine.



By: Daniel Flounders (danfloun) 2011-03-21 14:33:52

@iasgoscouk
Okay thanks, this is driving me mad.
I have researched to the end of the internet and have no other information to offer.

NOTE: I'm running -
CentOS 5.5 Final
DAHDI Version: 2.4.0

By: iasgoscouk (iasgoscouk) 2011-03-21 14:36:31

@danfloun
thanks = was just in the middle of updating the note - and you replied before I'd had chance to save.

Are you using BT as PSTN provider, or are you with another 'LLU' provider

thanks
Ian

By: Daniel Flounders (danfloun) 2011-03-21 14:42:04

oops!

Analog PSTN Lines *BT*

Furthermore;
Although not directly related, I'll refer to the following bug report; 0014163 in which user 'Jedi98' states

"if you have a patch for UK CID that has this comment in it "/* Ignore ring before end of cid 'slot' (955ms = 7640 @ 8K samples/sec) */", then it's probably the one I wrote back in mid 2006 and have used ever since."

By: iasgoscouk (iasgoscouk) 2011-03-21 14:47:40

ok ! am running with no patches at all = been runing asterisk for years, from 1.4 to 1.6, now 1.8 and also with SVN releases.

I was running with 1.6 on the TDM card - and had no problems then

Will go through your configs are compare = might not be this evening.  in the middle of some php/perl updates on my website - but will def tomorrow.

Is there any reason why you cannot run on 1.8 ?



By: iasgoscouk (iasgoscouk) 2011-03-22 02:04:21

@donfloun
There is a couple of differences in the  chan_dahdi.conf, but wasn't until this morning did I rememeber the issues I had when moved to dahdi 2.4

My server is built with Fedora (14 currently), and had issues with modprobe with moved to 2.4 from an earlier version.

Can you check for the server startup for modprobe, i.e. /etc/modprobe.d/  and make sure that there is only files ending in '.conf' - earlier versions of dahdi didn't end with .conf, and left both versions is place.  I removed the files not containing the '.conf'; I found that if there was a dahdi and a dahdi.conf, it caused bridging problems and hence callerid issues with incoming calls.

Also, I have the following options set in /etc/modprobe.d/dahdi.conf:

# You should place any module parameters for your DAHDI modules here
# Example:
#
# options wctdm24xxp latency=6
options wctdm24xxp opermode=UK fwringdetect=1



Also, i would confirm whether asterisk actually sees the callerid; try putting a NoOP on the callerid in your dialplan and check the console output to see that asterisk is definately not seeing callerid, or whether it's not getting from asterisk to you phone/extension.  I have a DECT cordless multi-set running of a Handytone ATA box;  I had another analog converter which failed/didn't support callerid

Hope this might help, so far.

Ian

By: Daniel Flounders (danfloun) 2011-03-22 07:00:39

Hi,

I don't think you received my email. It could be my mail server, thats been playing up also.
To address your queries in order;

--

It was a clean install I was running with no patches but updated fully for 1.6.2.17.2.
Because of this Dahdi 2.4 was the only version I ever had on my system, therefore only the following files are in /etc/modprobe.d/ directory;

-rw-r--r-- 1 root root  810 Apr 10  2010 blacklist
-rw-r--r-- 1 root root  833 Oct 11 12:31 blacklist-compat
-rw-r--r-- 1 root root   83 Jan  6 02:18 blacklist-firewire
-rw-r--r-- 1 root root  329 Nov 23 21:49 dahdi.blacklist.conf
-rw-r--r-- 1 root root  149 Mar 19 23:48 dahdi.conf
-rw-r--r-- 1 root root 6111 Oct 11 12:31 modprobe.conf.dist

--

Unfortunately I had set this already in my dahdi.conf;

options wctdm24xxp opermode=UK fwringdetect=1 battthresh=4 debug=1

--

I tried NoOp for CALLERID(num) on my dialplan and it's empty on every call.


 == Starting post polarity CID detection on channel 1
   -- Starting simple switch on 'DAHDI/1-1'
[Mar 22 11:47:45] NOTICE[3846]: chan_dahdi.c:1777 my_distinctive_ring: Got event 18 (Ring Begin)...
   -- Detected ring pattern: 0,0,0
   -- Checking 0,0,0
   -- Ring pattern check range: 10
   -- Ring pattern matched in range: -10 to 10
   -- Ring pattern check range: 10
   -- Ring pattern matched in range: -10 to 10
   -- Ring pattern check range: 10
   -- Ring pattern matched in range: -10 to 10
   -- Distinctive Ring matched context pstn-inbound
   -- Executing [s@avo-pstn-inbound:1] NoOp("DAHDI/1-1", "Caller ID is:") in new stack
   -- Executing [s@avo-pstn-inbound:2] Dial("DAHDI/1-1", "DAHDI/4") in new stack
   -- Called 4
   -- DAHDI/4-1 is ringing
   -- DAHDI/4-1 is ringing
   -- DAHDI/4-1 is ringing
   -- DAHDI/4-1 is ringing
   -- DAHDI/4-1 is ringing

I tried setting the NoOp in various places of the dialplan i.e. before answer, after answer, etc. Not sure whether it makes any difference but I still got an empty callerid.

--

This morning I upgraded to 1.8.3.2 - Still the same.
I am at a loss.

By: iasgoscouk (iasgoscouk) 2011-03-22 07:04:01

@donfloun - ok - am just about to pop out, but when I get back will run a call through and log on console and match the output.

The only think which seems different to me now is the distinctive ring checking. Will check back in about an hour.

thanks

Update:    my console log matches exactly =

== Starting post polarity CID detection on channel 1
   -- Starting simple switch on 'DAHDI/1-1'
   -- Detected ring pattern: 0,0,0
   -- Checking 0,0,0
   -- Ring pattern check range: 10
   -- Ring pattern matched in range: -10 to 10
   -- Ring pattern check range: 10
   -- Ring pattern matched in range: -10 to 10
   -- Ring pattern check range: 10
   -- Ring pattern matched in range: -10 to 10
   -- Distinctive Ring matched context BTInbound
   -- Executing [s@BTInbound:1] AGI("DAHDI/1-1", "/var/scripts/asterisk/ext_call_in_status.pl,BT,0xxxxxxx,") in new stack
   -- Launched AGI Script /var/scripts/asterisk/ext_call_in_status.pl
   -- <DAHDI/1-1>AGI Script /var/scripts/asterisk/ext_call_in_status.pl completed, returning 0
   -- Executing [s@BTInbound:2] NoOp("DAHDI/1-1", "0xxxxxxx") in new stack


but i am using callerid(number), removed my actually incoming no



By: iasgoscouk (iasgoscouk) 2011-03-22 08:11:06

Updated my note above, and realised you would prb not get an email notify.

Can you confirm that callerid(number) produces no callerid too

By: Daniel Flounders (danfloun) 2011-03-22 10:14:27

Hi,

I called home to try it in exceitement lol;
Doesn't work with ${CALLERID(number)} either

The distinctive ring logging didn't appear on 1.6, only when I upgraded to 1.8 today.

By: iasgoscouk (iasgoscouk) 2011-03-22 11:21:48

Cannot offer any help into debugging asterisk more;  I had similar problems when I first started using the TDM card, and callerid starting working for me once the modprobe issue was resolved;  it took a lot of self help, scouring google etc, and hoped that I might be able to help.

Have to ask, sorry, a very basic question :  i have an 'emergency phone' plugged into a doubler from the BT ADSL filter; the other socket goes to the card.  Are you sure what placing a phone before or in place of the card, that callerid shows on a phone ( sorry for asking maybe a condescending question).

There are the different settings against my chan_dahdi.conf

sendcalleridafter = 0
immediate = yes
rxgain=4.0
txgain=3.5

the following lines are don't have:
waitfordialtone=yes
useincomingcalleridondahditransfer = yes
answeronpolarityswitch=yes
tonezone=4



Ian



By: Daniel Flounders (danfloun) 2011-03-22 11:42:32

Ian,

Not condescending don't worry, these things can get overlooked.
Yes I have a phone in parallel at present and caller ID works fine.

I have done a lot of research into this, long before I posted a bug because I accept that there are so many other possibilities 'other than bugs'.

'sendcalleridafter' - I read online that there was a bug in setting it to '0', but again, like the internet throughout you don't no whether these things have been fixed. I also read that this was only for outgoing calls.

'immediate' - My understanding is that with this set to yes, asterisk answers the call immediately which is not what we want (i think). Either way it makes no difference however I set it.

I've tried increasing gain levels, though the line is clear with no noticeable echo. I will try that again.

I will also try removing the lines you 'don't' have. Though I think I only enabled them because I was having trouble with caller id.

I'll have another play.
Thanks for you help ian.

By: iasgoscouk (iasgoscouk) 2011-03-22 11:57:00

It was a long hard struggle for me to get callerid to work - i understand your frustration.

One little piece of advice though ;   even though it shouldn't be the case,  a dahdi restart did not always fully unload and restarted everything cleanly, and always performed a full shutdown and cold startup.

If you can get to see if you can email me, would save the issues log, until we/you find the solution or issue, and updating the issue for digium/asterisk, rather than using the issues log as a chat.

Ian

By: Daniel Flounders (danfloun) 2011-03-22 20:05:45

Ian,

It's now 12.55am and I'm knackered. But, the good news I've have caller id working.
Not sure how reliably yet, but it appears to be passing some mobile phone ids happily.
Will check it further tomorrow.

Unfortunately I can't tell you what the fix was.
I did a clean install of 1.8 today with dahdi 2.4 and used the confs in my initial report.
Using those confs, everything just worked.

I also noticed that the option 'immediately=yes/no' had no affect on my system at all, so I have set it to 'no' as that is what I think it should be.

My output from /var/log/messages on an incoming call is now like this;


Mar 23 01:02:27 localhost kernel: wctdm24xxp 0000:00:0a.0: 11333131 Polarity reversed (-1 -> 1)
Mar 23 01:02:29 localhost kernel: wctdm24xxp 0000:00:0a.0: FW RING on 1/1!
Mar 23 01:02:29 localhost kernel: wctdm24xxp 0000:00:0a.0: FW NO RING on 1/1!
Mar 23 01:02:29 localhost kernel: wctdm24xxp 0000:00:0a.0: FW RING on 1/1!

It starts with polarity reversal as it should.
It's a shame I can't give an answer as to why, but that's life.
Thanks for taking time to help me out on this issue, maybe now I can start setting the system up properly.

Cheers
Danny