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: -
- Add debug=1 to your wctdm in modprobe.conf then restart zaptel & asterisk
- Do 'tail -f /var/log/message'
- 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);