[help] UK CID Intermittent, out of ideas!

Hello,

I’m trying to get CID to work reliably in the UK. I’m using the TDM400P connected to a BT residential line. I know this problem has been mentioned a couple of times in various posts and mailing lists but I’ve not found a solution. Hence bringing it up again, hope you don’t mind.

If the CID works properly, this is the CLI output:

[quote] == Starting post polarity CID detection on channel 3
– Starting simple switch on ‘Zap/3-1’
[Jan 25 12:12:02] NOTICE[2912]: chan_zap.c:6214 ss_thread: CallerID number: 0**********, name: (null), flags=4
– Executing [s@zap_incoming:1] Answer(“Zap/3-1”, “”) in new stack
– dialplan continues…[/quote]

If the CID fails, I see this:

[quote] == Starting post polarity CID detection on channel 3
– Starting simple switch on ‘Zap/3-1’
[Jan 25 12:09:52] NOTICE[2908]: chan_zap.c:6171 ss_thread: Got event 2 (Ring/Answered)…
[Jan 25 12:09:55] WARNING[2908]: chan_zap.c:6234 ss_thread: CID timed out waiting for ring. Exiting simple switch
– Hungup ‘Zap/3-1’
– Starting simple switch on ‘Zap/3-1’
– Executing [s@zap_incoming:1] Answer(“Zap/3-1”, “”) in new stack
– dialplan continues…[/quote]

Searching the Internet for the phrase “CID timed out waiting for ring” pointed me to this recent patch to Zaptel. This seems to be my exact issue so I checked out the latest Zaptel 1.4 branch from the SVN. Activating the patch by setting fwringdetect=1, I now get:

CID success is the same as before:

[quote] == Starting post polarity CID detection on channel 3
– Starting simple switch on ‘Zap/3-1’
[Jan 25 12:31:20] NOTICE[2411]: chan_zap.c:6214 ss_thread: CallerID number: 0**********, name: (null), flags=4
– Executing [s@zap_incoming:1] Answer(“Zap/3-1”, “”) in new stack
– dialplan continues…[/quote]

The CID still fails, however, despite using the fwringdetect patch. This is the output:

[quote] == Starting post polarity CID detection on channel 3
– Starting simple switch on ‘Zap/3-1’
[Jan 25 12:14:55] NOTICE[2398]: chan_zap.c:6171 ss_thread: Got event 2 (Ring/Answered)…
– Executing [s@zap_incoming:1] Answer(“Zap/3-1”, “”) in new stack
– dialplan continues…[/quote]

Clearly I don’t get the “CID timed out…” error any more, but at the same time I still don’t get CID.

Here’s my Zapata.conf:

[quote][channels]
usecallerid = yes
cidsignalling = v23
cidstart = polarity
sendcalleridafter=2
hidecallerid=no
callwaiting=no
threewaycalling=yes
transfer=yes
echocancel=yes
echotraining=yes
immediate=no

; Channels 1 and 2 are FXS ports (only 1 connected as of 2008-01-12)
;
context=zap_outgoing
signalling=fxo_ks
callerid=“Cromnet-3” <503>
channel => 1

; Channels 3 and 4 are FXO ports (only 1 conntected as of 2008-01-12)
;
context=zap_incoming
signalling=fxs_ks
callerid=asreceived
channel => 3[/quote]

I’m using Asterisk 1.4.15 on Debian 4.0 “Etch”. My Zaptel is the latest 1.4 branch, version “SVN-branch-1.4-r3733”. Note I was also seeing intermittent CID using Zaptel release 1.4.7.

Has anyone had a similar experience, or at the very least has CID reliably working in the UK?

Thanks in advance. Giles.

Hi

One to try is to up the RX gain. it has worked for others

Ian

Hi

I’m experiencing exactly the same problem with the TDM400 on a UK multi-line. Unfortunately changing the rxgain hasn’t worked at all for me.

Does anyone know of a solution to this problem?

Thanks

I have the same problem on Trixbox 2.8 where our aux line times out on CID. The phone rings and rings at callers end but doesnt at our end.

Will the patch sort this problem out.

If so does anyone know where to get this patch and how to implement it?

Thanks in advance

Depending on the implementation of the aux line, it may be incapable of the line reversals needed for caller-id.

Aux lines are often implemented as an RF signal on the main line.

It works intermittently though - sorry my ignorance but could this still be the cause?

Thanks for your speedy response by the way.

You probably are getting line reversals. You need to enable low level tracing (sorry I don’t know the details) to see what hardware events are being reported…

Thanks for your help. A bit beyond me at the moment. Googled for low level tracing and asterisk but cant see anything related.

I hate to be a pain but can anyone point me in the right direction?

Thanks so far - appreciate your help.

My thoughts are that this patch is still the way to go.

Could anyone explain how I go about patching?

My, look at that, this is one of my questions. And, bad me, I never posted an update. Sorry!

I finally got good CID performance by applying a patch that forces Asterisk to wait for the CID to be complete before continuing. It is detailed in this post.

Unfortunately that patch is for an older version of chan_zap.c. I’ve never got the patch itself to work, every time I use this fiddle I end up manually searching the code for the place where it should go and copying the code in. For the record, the fix works fine in chan_dahdi.c from the 1.6.1 tree, I think the code is somewhere after line 7000. If you’re using a Trixbox then I can’t help you, I only use raw Asterisk.

Giles.

Unfortunately, that is never going to go into the official code unless the original author submits it properly with the appropriate licence agreement, or someone does a clean room re-implementation and submits that.