CID ? Sometimes!

[gosz]

I have a TDM400P and the cid always worked just using the standard settings. I then rebuilt my box using the correct uk settings e.g. genzaptelconf ?c uk and setting options wctdm opermode=UK in modprobe.conf.

Now although some things have improved I sometimes get cid and sometimes I dont. If a caller calls twice in a row the first call often does not have cid info but the second call has?

Anyone got any ideas or is my asterisk just being weird ?

[gtcleaves]

is asterisk perhaps answering the incoming call too quickly, before CID info is sent? do you have 'immediate=yes' in zapata.conf? if so, change it to 'no'.

[gosz]

I've tried both and the same problem

[baconbuttie]

your Asterisk isn't being weird ... i've seen this on a couple of TDM cards (including mine). someone from this forum sent me a patch they had developed, but i haven't had a chance to try it yet as my Asterisk box has a Sangoma installed right now, which is 100% reliable on CID.

when the CID fials, do you get a pause on the console when the pause comes in ?

PM me and i'll send you a copy of the patch to try.

[09xIwZdDnc]

There's actually more than one problem here the main two are: -

1) (this is maybe what you are seeing with two calls) If a call comes in too soon after a previous call (in or out) on the same line then part of asterisk does not accept it as a new call and part of it does. The part which doesn't is the call init via polarity change and hence caller ID. The part which does woth if the plain old fallback system of: See a ring voltage - start a call. This is all to do with the polarity timing built into chan_zap and I have not really got to the bottom of this. It currently runs at about 5% CID failure in a medium loaded line. I intend to look into this one but it's gonna take a lot of digging.

2) This one I know more about. Some UK BT lines seem to be able to trigger a false ring on the tdm400p at exactly 380ms after the CID starts. This results in * giving up on the CID and going into a fallback state where it just gets on with the call. You can test for this easily: -

1. Add debug=1 to your wctdm in modprobe.conf then restart zaptel & asterisk
2. Do 'tail -f /var/log/message'
3. Call the line from another phone (just let it ring twice, no need to answer).

Below is an example of the problematic situation, note that the call appears
to start with a ring, which is incorrect:

Code: Select all

Jul 29 16:27:43 39net-server2 kernel: RING on 1/3!
Jul 29 16:27:43 39net-server2 kernel: 531681538 Polarity reversed (-1 -> 1)
Jul 29 16:27:43 39net-server2 kernel: NO RING on 1/3!
Jul 29 16:27:45 39net-server2 kernel: RING on 1/3!
Jul 29 16:27:46 39net-server2 kernel: NO RING on 1/3!
Jul 29 16:27:48 39net-server2 kernel: RING on 1/3!
Jul 29 16:27:49 39net-server2 kernel: 531687251 Polarity reversed (1 -> -1)
Jul 29 16:27:49 39net-server2 kernel: NO RING on 1/3!

And here is an example of how it should look, note that the call correctly
starts with polarity reversal:

Code: Select all

Jul 29 14:00:44 39net-server2 kernel: 522861081 Polarity reversed (-1 -> 1)
Jul 29 14:00:46 39net-server2 kernel: RING on 1/3!
Jul 29 14:00:47 39net-server2 kernel: NO RING on 1/3!
Jul 29 14:00:49 39net-server2 kernel: RING on 1/3!
Jul 29 14:00:50 39net-server2 kernel: NO RING on 1/3!
Jul 29 14:00:52 39net-server2 kernel: RING on 1/3!
Jul 29 14:00:53 39net-server2 kernel: NO RING on 1/3!
Jul 29 14:00:55 39net-server2 kernel: RING on 1/3!
Jul 29 14:00:56 39net-server2 kernel: 522872955 Polarity reversed (1 -> -1)

My fix for this was to patch chan_zap.c to ignore rings before CID is complete (about a 1 sec proccess) however, this may be a problem to you if you use a bin asterisk distrib like a@home/trix box. I have pasted the diff below in case it is of use.

It's a good idea to have the * console output in another window when you test this since there's a couple of tell-tail messages there which show the other end of the problem.

Hope this helps.

Code: Select all

--- chan_zap_orig.c   2006-07-11 17:50:15.000000000 +0100
+++ chan_zap.c   2006-07-11 18:21:32.000000000 +0100
@@ -5874,9 +5874,15 @@
                  }
                  if (i & ZT_IOMUX_SIGEVENT) {
                     res = zt_get_event(p->subs[index].zfd);
+                     /* Ignore ring before end of cid 'slot' (955ms = 7640 @ 8K samples/sec) */
+                     if (res == 2 && samples < 7640)
+                        ast_log(LOG_NOTICE, "Ignoring event %d (%s) due to waiting for CID, samples=%d\n", res, event2str(res), samples);
+                     else
+                     {
                     ast_log(LOG_NOTICE, "Got event %d (%s)...\n", res, event2str(res));
                     res = 0;
                     break;
+                     }
                  } else if (i & ZT_IOMUX_READ) {
                     res = read(p->subs[index].zfd, buf, sizeof(buf));
                     if (res < 0) {
@@ -5909,7 +5915,7 @@
               }

               /* Finished with Caller*ID, now wait for a ring to make sure there really is a call coming */
-               res = 2000;
+               res = 4000;
               for (;;) {
                  struct ast_frame *f;
                  res = ast_waitfor(chan, res);


[angler]

This patch seems to work great!

[mjgolli]

Is the patch specifically to help with UK caller id, or is it non-specific?

Angler: what issues have you been having with caller id? I would like to know if they are similar to mine, so I can tell if this patch would help me.

Thanks!
Mike

[angler]

That patch is UK specific. Had the exact issue as described above.

[timsmith]

Hi

Ive got a very similar problem to that described above. On my BT line, Caller ID is intermittent and sometimes a "ghost" second call arrives after the first has finished.

Im using Asterisk 1.4.22, Zaptel 1.4.11 and an OpenVox A400 card?

Can this patch be used with the DAHDI code in any way as I dont have a chan_zap.c and I cant find equivalent code in chan_dahdi.c

Thanks

Tim

PS - forgot to mention that I did get the RING before the POLARITY change.