asterisk users - Oct 2004 - Brazillian Caller ID: almost there...

Hello,

Talking with Soren Sratje about Caller ID in Brazil, we compare ours
DTMF tones captured by ztmonitor. wcfxo correctly recognize the "DTMF
CLIP" and asterisk shot the AST_STATE_PRERING correctly.
But the DTMF tones are not reconized. In the chan_zap.c, the code:

if (f->frametype == AST_FRAME_DTMF) {
(...)

Does not occurs because the frametype is always reconized as voice
(AST_FRAME_VOICE).

I use 4 Digium X100P.
Like noted by Soren (http://www.ad2.com.br/DTMF.jpg), the main diference
between the 2 samples is the time elapsed after the "burst" sign and
the
first DTMF digit. In my sample, its occurs more quickly...

I inspect the asterisk code for days, but nothing found...

Thanks all

Alexandre de Arruda Paes

alexandre::aldeia digital wrote:
> Hello,
>
> Talking with Soren Sratje about Caller ID in Brazil, we compare ours
> DTMF tones captured by ztmonitor. wcfxo correctly recognize the "DTMF
> CLIP" and asterisk shot the AST_STATE_PRERING correctly.
> But the DTMF tones are not reconized. In the chan_zap.c, the code:
>
> if (f->frametype == AST_FRAME_DTMF) {
> (...)
>
> Does not occurs because the frametype is always reconized as voice
> (AST_FRAME_VOICE).
>
> I use 4 Digium X100P.
> Like noted by Soren (http://www.ad2.com.br/DTMF.jpg), the main
> diference between the 2 samples is the time elapsed after the
"burst"
> sign and the first DTMF digit. In my sample, its occurs more
> quickly...
>
Maybe to elaborate on this, the modifications made to wcfxo.c (attached
below) is now quite simple since DTMF CID detection for the TDM400P was put
in Asterisk and will trigger the CID detection whenever a "loud noise"
is
detected. False positives will occur from time to time but I found this
justifiable opposed to not having CID detection on my home system (Denmark).

If the first DTMF digit is not detected due to lack of time switching to the
CID detection code, the second and subsequent digits should be detected
since the code is already there waiting and still within the timeout period
waiting for RING.

A more likely cause is the overlaying "hum" that could trigger
Asterisk to
detect the signal differently from DTMF.

Regards
Soren Rathje


--- wcfxo.c.org 2004-09-25 17:13:13.000000000 +0200
+++ wcfxo.c 2004-09-25 17:17:47.000000000 +0200
@@ -125,6 +125,7 @@
 #ifdef JAPAN
  int ohdebounce;
 #endif
+ int readcid;
  int allread;
  int regoffset;   /* How far off our registers are from what we expect */
  int alt;
@@ -327,6 +328,14 @@
   }
   /* Look for pegging to indicate ringing */
   sample = (short)(le32_to_cpu(readchunk[(x << 1) + (1 - wc->alt)])
>> 16);
+  if (!wc->readcid && !wc->ringdebounce) {
+   if ((sample > 32000) | (sample < -32000)) {
+    wc->readcid = 1;
+    if (debug)
+     printk("CID\n");
+    zt_qevent_lock(&wc->chan, ZT_EVENT_POLARITY);
+   }
+  }
   if ((sample > 32000) && (wc->peg != 1)) {
    if ((wc->pegtimer < PEGTIME) && (wc->pegtimer >
MINPEGTIME))
     wc->pegcount++;
@@ -606,6 +615,7 @@
   reg = reg | 0x08;
   wcfxo_setreg(wc, 0x5, reg);
   wc->offhook = 0;
+  wc->readcid = 0;
   /* Don't accept a ring for another 1000 ms */
   wc->ringdebounce = 1000;
 #ifdef JAPAN