Having read through the Caller ID code, it appears that this is indeed what is 
happening.  The Caller ID code doesn't contain any logic to trigger a timeout 
if no Caller ID data stream is found, or if a stream starts and does not 
terminate.

The attached patch causes the Caller ID to timeout after processing around 15
seconds of data. I assume that this should be quite long enough, but I am no
Caller ID expert!

I've tested this patch with BT's automated line test (dial 17070, options 3,
1, 2). It appears to work fine:

  == Starting post polarity CID detection on channel 3
    -- Starting simple switch on 'Zap/3-1'
Nov 22 13:16:03 NOTICE[7862]: chan_zap.c:5257 ss_thread: Got event 17 (Polarity 
Reversal)...
Nov 22 13:16:13 ERROR[7862]: callerid.c:257 callerid_feed: Caller ID processed 
120160 samples, giving up.
Nov 22 13:16:13 WARNING[7862]: chan_zap.c:5272 ss_thread: CallerID feed failed: 
Success
Nov 22 13:16:13 WARNING[7862]: chan_zap.c:5284 ss_thread: CallerID returned 
with error on channel 'Zap/3-1'
Nov 22 13:16:15 WARNING[7862]: chan_zap.c:5293 ss_thread: CID timed out waiting 
for ring. Exiting simple switch
    -- Hungup 'Zap/3-1'

Mark, how do I go about getting this included in CVS?

Thanks,

Will


On Sun, Nov 21, 2004 at 10:34:27PM +0000, William R Sowerbutts wrote:
>Hmmmm.
>
>Is it possible that the line is detecting a polarity event, decided that the
>line is ringing and started listening for a non-existant V23 data stream, and
>then the line has not in fact rung?
>
>This would mark the line as busy (and unable to handle an outgoing call) but 
>when a call did in fact come in the line would then ring correctly.
>
>I believe BT's automated testing equipment can produce these line conditions.
>
>Will


_________________________________________________________________________
William R Sowerbutts                                  [EMAIL PROTECTED]
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> [EMAIL PROTECTED]@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  

--- asterisk/callerid.c.orig    2004-11-22 13:01:33.000000000 +0000
+++ asterisk/callerid.c 2004-11-22 13:01:59.000000000 +0000
@@ -43,6 +43,7 @@
        int flags;
        int sawflag;
        int len;
+       int eaten;
 };
 
 
@@ -132,6 +133,7 @@
                cid->fskd.cont = 0;                     /* Digital PLL reset */
                cid->fskd.x0 = 0.0;
                cid->fskd.state = 0;
+               cid->eaten = 0;
                memset(cid->name, 0, sizeof(cid->name));
                memset(cid->number, 0, sizeof(cid->number));
                cid->flags = CID_UNKNOWN_NAME | CID_UNKNOWN_NUMBER;
@@ -249,6 +251,12 @@
                ast_log(LOG_WARNING, "Out of memory\n");
                return -1;
        }
+       cid->eaten += len;
+       if(cid->eaten > (8000 * 15)){ 
+         /* we've eaten over 15 seconds of data */
+         ast_log(LOG_ERROR, "Caller ID processed %d samples, giving up.\n", 
cid->eaten);
+         return -1;      
+       }
        memset(buf, 0, 2 * len + cid->oldlen);
        memcpy(buf, cid->oldstuff, cid->oldlen);
        mylen += cid->oldlen/2;
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to