[Home]

Summary:DAHLIN-00004: [patch] DTMF CID without polarity reversal implementation in wctdm for Denmark, Brazil, etc
Reporter:fleed (fleed)Labels:
Date Opened:2007-02-18 19:02:11.000-0600Date Closed:2009-12-22 15:42:02.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 9096.nopolaritypatch
( 1) 9096.nopolaritypatch-dahdi-linux-2.1.0.3
( 2) 9096.nopolaritypatch-dahdi-linux-2.1.0.3-v2
( 3) 9096.nopolaritypatch-dahdi-linux-trunk-r6690
( 4) 9096.nopolaritypatch-zaptel.diff
( 5) 9096-1.6.2-branch.diff
( 6) 9096-chan_dahdi-trunk.diff
( 7) chan_dahid_sample_config.patch
( 8) cidtimeoutfix-asterisk-1.4.23
( 9) wctdm_v3_nopolarity.diff
(10) wctdm_v3_trunk_nopolarity.diff
(11) wctdm24xxp_nopolarity.diff
Description:Caller id signaling in Denmark, Brazil and other places is done through DTMF tones before the first ring, without polarity reversal to indicate the start of incoming data. Currently wctdm can only detect dtmf callerid if there is a polarity reversal before the dtmf digits, so it's not working in some countries.

This uses the idea reported in bug id 9 for wcfxo, but implements it in wctdm. It fakes a polarity reversal so that the code already in chan_zap can take that and pass it through the dtmf bit.

To use, patch and build the zaptel part, load the module with option dtmf=1. Then use the following in zapata.conf:
callerid=asreceived
usecallerid=yes
cidsignalling=dtmf
hidecallerid=no
cidstart=polarity

Works fine in Brazil, on a Telemar line.


****** ADDITIONAL INFORMATION ******

Pretty good information and most of the dtmf callerid code is in:
http://bugs.digium.com/view.php?id=9

Comments:By: Serge Vecher (serge-v) 2007-02-19 12:14:27.000-0600

can you please get a disclaimer on file? See bottom of http://bugs.digium.com/main_page.php.
By: fleed (fleed) 2007-02-20 04:44:20.000-0600

Disclaimer faxed in just now.
By: Tzafrir Cohen (tzafrir) 2007-03-01 15:12:32.000-0600

My usual comment about permissions to module parameters: the values of those parameters are not secret. There's really no reason to make them readable to root alone. For instance, a web interface that provides unformation about the system may find that information (under /sys/module/wctdm/parameters ) useful.
By: Tzafrir Cohen (tzafrir) 2007-03-01 19:46:30.000-0600

I didn't like the big macro inside the function, so I tried converting it into an inline function.

Thi is only tested to build on current svn 1.2 (likewise the original patch): 2252.

The patch fails to aply on trunk.
By: fleed (fleed) 2007-03-02 08:07:19.000-0600

about module params: I just used the same permission as the ones already in use.

I've uploaded a new patch against trunk as of today 2007/03/02. The macro is converted to a function and it contains a few changes in relation to the original patch to make detection more consistent.
By: fleed (fleed) 2007-03-02 08:28:55.000-0600

New diffs:
wctdm_v2_trunk_nopolarity.diff: Patch against trunk, handle detection if using #define AUDIO_RINGCHECK
wctdm_v3_nopolarity.diff: Patch against zaptel-1.2.13. Better detection, and also handle detection if using AUDIO_RINGCHECK.

Please delete previous diffs and leave these two.
By: Tzafrir Cohen (tzafrir) 2007-03-02 08:52:34.000-0600

Another matter of style (sorry, still nothing relevant to the actual contents):

in the inline function, instead of:

if (condition) {
 do something
}

make it:

if (!condition)
 return;
do something

Removes unnecessary nesting.
By: fleed (fleed) 2007-03-02 12:24:14.000-0600

Uploaded new diff with changes suggested by tzafrir plus a few extra comments. I've only made the changes to trunk since they're only coding style changes. BTW: wctdm_v2_trunk_nopolarity.diff can be deleted now.
By: Tzafrir Cohen (tzafrir) 2007-03-02 12:40:56.000-0600

One other comment, again, regardless of the basic functionality:

what happens if the user set dtmf=0 (through the sysfs interface) when .fxo.readcid had a value of 1, and later on sets it back to 1?

Is there a possible scenario in which readcid will remain constantly at the value of 1?
By: fleed (fleed) 2007-03-03 05:13:38.000-0600

I can't see it getting stuck with readcid=1 if the dtmf parameter is changed through sysfs. It will get reset to 0 either after a complete ring, or after a bit of time has passed since the last time it has been set.
By: Claudio Siebel (csiebel) 2007-03-04 15:45:02.000-0600

Hi, I am testing the changes you made to wctdm, I am living in Uruguay and my country has the same Denmark, Netherlands signalling receiveing the CID.
I apply the patch and it works well but betwen each call i receive in the console the message:
Mar  4 16:34:56 WARNING[2196]: chan_zap.c:5989 ss_thread: DTMFCID timed out waiting for ring. Exiting simple switch

After that in the first call I receive i miss the caller ID.
In the Asterisk log when i receive the call the message is:
Mar  4 16:43:04 DEBUG[2231] chan_zap.c: Receiving DTMF cid on channel Zap/1-1
Mar  4 16:43:04 DEBUG[2231] chan_zap.c: Exception on 14, channel 1
Mar  4 16:43:04 DEBUG[2231] chan_zap.c: Got event Ring Begin(18) on channel 1 (index 0)
Mar  4 16:43:05 DEBUG[2231] chan_zap.c: Exception on 14, channel 1
Mar  4 16:43:05 DEBUG[2231] chan_zap.c: Got event Ring/Answered(2) on channel 1 (index 0)
Mar  4 16:43:05 DEBUG[2231] chan_zap.c: Setting IDLE polarity due to ring. Old polarity was 1
Mar  4 16:43:05 DEBUG[2231] chan_zap.c: CID got string ''
Mar  4 16:43:05 DEBUG[2231] callerid.c: No cid detected
Mar  4 16:43:05 DEBUG[2231] chan_zap.c: CID is '', flags 8
Mar  4 16:43:07 DEBUG[2231] chan_zap.c: Exception on 14, channel 1
Mar  4 16:43:07 DEBUG[2231] chan_zap.c: Got event Polarity Reversal(17) on channel 1 (index 0)
Mar  4 16:43:07 DEBUG[2231] chan_zap.c: Ignore switch to REVERSED Polarity on channel 1, state 4
Mar  4 16:43:07 DEBUG[2231] chan_zap.c: Ignoring Polarity switch to IDLE on channel 1, state 4
Mar  4 16:43:07 DEBUG[2231] chan_zap.c: Polarity Reversal event occured - DEBUG 2: channel 1, state 4, pol= 0, aonp= 0, honp= 0, pdelay= 600, tv= 507715278
Mar  4 16:43:07 DEBUG[2231] chan_zap.c: Exception on 14, channel 1
Mar  4 16:43:07 DEBUG[2231] chan_zap.c: Got event Polarity Reversal(17) on channel 1 (index 0)
Mar  4 16:43:07 DEBUG[2231] chan_zap.c: Ignore switch to REVERSED Polarity on channel 1, state 4
Mar  4 16:43:07 DEBUG[2231] chan_zap.c: Ignoring Polarity switch to IDLE on channel 1, state 4
Mar  4 16:43:07 DEBUG[2231] chan_zap.c: Polarity Reversal event occured - DEBUG 2: channel 1, state 4, pol= 0, aonp= 0, honp= 0, pdelay= 600, tv= 507716023
Mar  4 16:43:09 DEBUG[2231] chan_zap.c: Exception on 14, channel 1
Mar  4 16:43:09 DEBUG[2231] chan_zap.c: Got event Polarity Reversal(17) on channel 1 (index 0)
Mar  4 16:43:09 DEBUG[2231] chan_zap.c: Ignore switch to REVERSED Polarity on channel 1, state 4
Mar  4 16:43:09 DEBUG[2231] chan_zap.c: Ignoring Polarity switch to IDLE on channel 1, state 4
Mar  4 16:43:09 DEBUG[2231] chan_zap.c: Polarity Reversal event occured - DEBUG 2: channel 1, state 4, pol= 0, aonp= 0, honp= 0, pdelay= 600, tv= 507717948
Mar  4 16:43:09 DEBUG[2231] chan_zap.c: Exception on 14, channel 1
Mar  4 16:43:09 DEBUG[2231] chan_zap.c: Got event Polarity Reversal(17) on channel 1 (index 0)
Mar  4 16:43:09 DEBUG[2231] chan_zap.c: Ignore switch to REVERSED Polarity on channel 1, state 4
Mar  4 16:43:09 DEBUG[2231] chan_zap.c: Ignoring Polarity switch to IDLE on channel 1, state 4
Mar  4 16:43:09 DEBUG[2231] chan_zap.c: Polarity Reversal event occured - DEBUG 2: channel 1, state 4, pol= 0, aonp= 0, honp= 0, pdelay= 600, tv= 507718007
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '(null)'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '(null)'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is 's'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is 'from-pstn'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is 'Zap/1-1'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '(null)'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is 'Wait'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '20'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '2007-03-04 16:43:05'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '(null)'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '2007-03-04 16:43:13'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '8'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '0'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is 'NO ANSWER'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is 'DOCUMENTATION'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '(null)'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '1173033784.14'
Mar  4 16:43:13 DEBUG[2231] pbx.c: Function result is '(null)'
Mar  4 16:43:13 DEBUG[2231] chan_zap.c: Hangup: channel: 1 index = 0, normal = 14, callwait = -1, thirdcall = -1

Do you know what is happenig ?
Regards
csiebel
By: fleed (fleed) 2007-03-08 07:38:11.000-0600

csiebel: Do you always get the message on the console between each call? Is it when the line is onhook that you get that? Could you try running ztmonitor to see if there is noise on the line that is causing a mis-detection? What versions of asterisk and zaptel are you using? I'll see if I can duplicate the messages you're getting on the console and look at what's going on.
By: Claudio Siebel (csiebel) 2007-03-11 15:56:43

1. When I test the channel wit ztmonitor it has information, but I think it is no noise, 1 minute after the hangup and the change of polarity, I get the message "DTMF CLIP on 1" in the log.

Also the first time I load the wctdm module "modprobe debug=9 dtmf=1" and start asterisk, in the first call I receive I didn't see the CID, after the first call, when I call again and before a minute a can see th CID.
But after receive the DTMF

So I think  we are using the routine "wctdm_dtmfcheck_fakepolarity" in a situation that the data in the channel is not de CID.

Here we have a polarity reverse for the hangup detection, but always the TELCO send some data 1 minute after the hangup, and we are processing that data as a CID.

The message I sent you in the other note is the message i get in the asterisk cli.

My Zaptel version is: 1.2.15
My Asterisk version is: 1.2.16

Thank and regards.
By: Claudio Siebel (csiebel) 2007-03-11 19:47:38

sorry, i forget to tell you that the line is On Hook.

Regards
By: Claudio Siebel (csiebel) 2007-03-11 20:07:21

I add a prink inside the routine wctdm_dtmfcheck_fakepolarity under the if (sample > 16000 || < -16000)....

This is the printk I added:

wc->mod[card].fxo.cidtimer = wc->intcount;

if (debug) printk("\n \n readchunk = %u reg0shadow = %u | reg1shadow = %u ios= %u dead = %i  pos = %i  polarity = %i polaritydebounce = %i  cidtimer = %i \n \n",wc->chans[card].readchunk[x],wc->reg0shadow[x],wc->reg1shadow[x],wc->ios,wc->dead,wc->pos,wc->mod[card].fxo.polarity,wc->mod[card].fxo.polaritydebounce,wc->mod[card].fxo.cidtimer);

if (debug) printk("DTMF CLIP on %i\n",card+1);


Here is the log of the wctdm with my coments:


Mar 11 18:49:17 AsteriskDemo1 kernel: Freshmaker version: 73
Mar 11 18:49:17 AsteriskDemo1 kernel: Freshmaker passed register test
Mar 11 18:49:17 AsteriskDemo1 kernel: ProSLIC on module 0, product 3, version 15
Mar 11 18:49:17 AsteriskDemo1 kernel: VoiceDAA System: 04
Mar 11 18:49:17 AsteriskDemo1 kernel: ISO-Cap is now up, line side: 03 rev 06
Mar 11 18:49:17 AsteriskDemo1 kernel: Module 0: Installed -- AUTO FXO (FCC mode)
Mar 11 18:49:17 AsteriskDemo1 kernel: ProSLIC on module 1, product 0, version 0
Mar 11 18:49:17 AsteriskDemo1 kernel: VoiceDAA System: 04
Mar 11 18:49:17 AsteriskDemo1 kernel: ISO-Cap is now up, line side: 03 rev 06
Mar 11 18:49:17 AsteriskDemo1 kernel: Module 1: Installed -- AUTO FXO (FCC mode)
Mar 11 18:49:17 AsteriskDemo1 kernel: ProSLIC on module 2, product 0, version 0
Mar 11 18:49:17 AsteriskDemo1 kernel: VoiceDAA System: 04
Mar 11 18:49:17 AsteriskDemo1 kernel: ISO-Cap is now up, line side: 03 rev 06
Mar 11 18:49:17 AsteriskDemo1 kernel: Module 2: Installed -- AUTO FXO (FCC mode)
Mar 11 18:49:17 AsteriskDemo1 kernel: ProSLIC on module 3, product 0, version 0
Mar 11 18:49:17 AsteriskDemo1 kernel: VoiceDAA System: 04
Mar 11 18:49:17 AsteriskDemo1 kernel: ISO-Cap is now up, line side: 03 rev 06
Mar 11 18:49:17 AsteriskDemo1 kernel: Module 3: Installed -- AUTO FXO (FCC mode)
Mar 11 18:49:17 AsteriskDemo1 kernel: Found a Wildcard TDM: Wildcard TDM400P REV I (4 modules)
Mar 11 18:49:17 AsteriskDemo1 kernel: Registered tone zone 3 (Netherlands)
Mar 11 18:49:17 AsteriskDemo1 kernel: NO BATTERY on 1/2!
Mar 11 18:49:17 AsteriskDemo1 kernel: NO BATTERY on 1/3!
Mar 11 18:49:17 AsteriskDemo1 kernel: NO BATTERY on 1/4!
Mar 11 18:49:17 AsteriskDemo1 kernel: 1579867 Polarity reversed (0 -> -1)

THIS IS THE FIRST CALL FIRST RING AFTER LOADING THE MODULE, WHEN readchunk is les than 100 I Didnt see the CID.

Mar 11 18:49:39 AsteriskDemo1 kernel:
Mar 11 18:49:39 AsteriskDemo1 kernel:  
Mar 11 18:49:39 AsteriskDemo1 kernel:  readchunk = 4 reg0shadow = 1 | reg1shadow = 216 ios= 20 dead = 0  pos = 0  polarity = -1 polaritydebounce = 0  cidtimer = 22506
Mar 11 18:49:39 AsteriskDemo1 kernel:  
Mar 11 18:49:39 AsteriskDemo1 kernel: DTMF CLIP on 1
Mar 11 18:49:39 AsteriskDemo1 kernel: RING on 1/1!
Mar 11 18:49:40 AsteriskDemo1 kernel: NO RING on 1/1!
Mar 11 18:49:41 AsteriskDemo1 kernel:
Mar 11 18:49:41 AsteriskDemo1 kernel:  
Mar 11 18:49:41 AsteriskDemo1 kernel:  readchunk = 14 reg0shadow = 1 | reg1shadow = 0 ios= 20 dead = 0  pos = 0  polarity = -1 polaritydebounce = 0  cidtimer = 24294
Mar 11 18:49:41 AsteriskDemo1 kernel:  
Mar 11 18:49:41 AsteriskDemo1 kernel: DTMF CLIP on 1
Mar 11 18:49:41 AsteriskDemo1 kernel: 1604174 Polarity reversed (-1 -> 1)
Mar 11 18:49:43 AsteriskDemo1 kernel: 1606143 Polarity reversed (1 -> -1)

THIS IS THE 2ND CALL FIRST RING IN THIS CASE I SEE THE CID, AS YOU SEE readchunk is greater than 1XX.

Mar 11 18:49:55 AsteriskDemo1 kernel:
Mar 11 18:49:55 AsteriskDemo1 kernel:  
Mar 11 18:49:55 AsteriskDemo1 kernel:  readchunk = 138 reg0shadow = 8 | reg1shadow = 1 ios= 20 dead = 0  pos = 0  polarity = -1 polaritydebounce = 0  cidtimer = 38225
Mar 11 18:49:55 AsteriskDemo1 kernel:  
Mar 11 18:49:55 AsteriskDemo1 kernel: DTMF CLIP on 1
Mar 11 18:49:57 AsteriskDemo1 kernel: RING on 1/1!
Mar 11 18:49:58 AsteriskDemo1 kernel: NO RING on 1/1!
Mar 11 18:49:59 AsteriskDemo1 kernel:
Mar 11 18:49:59 AsteriskDemo1 kernel:  
Mar 11 18:49:59 AsteriskDemo1 kernel:  readchunk = 12 reg0shadow = 217 | reg1shadow = 0 ios= 20 dead = 0  pos = 0  polarity = -1 polaritydebounce = 0  cidtimer = 42427
Mar 11 18:49:59 AsteriskDemo1 kernel:  
Mar 11 18:49:59 AsteriskDemo1 kernel: DTMF CLIP on 1
Mar 11 18:49:59 AsteriskDemo1 kernel: 1622305 Polarity reversed (-1 -> 1)
Mar 11 18:50:01 AsteriskDemo1 kernel: 1624161 Polarity reversed (1 -> -1)

HERE IS THE PROBLEM AFTER 1.30 MINS I RECEIVE THIS IN THE LOG, BUT I DIDN'T CALL AND THERE IS NO RING. THE readcunk variable is ok.


Mar 11 18:51:22 AsteriskDemo1 kernel:
Mar 11 18:51:22 AsteriskDemo1 kernel:  
Mar 11 18:51:22 AsteriskDemo1 kernel:  readchunk = 128 reg0shadow = 8 | reg1shadow = 1 ios= 20 dead = 0  pos = 0  polarity = -1 polaritydebounce = 0  cidtimer = 125410
Mar 11 18:51:22 AsteriskDemo1 kernel:  
Mar 11 18:51:22 AsteriskDemo1 kernel: DTMF CLIP on 1

THIS IS THE 4TH CALL FIRST RING HERE I DIDN'T HAVE THE CID, AS YOU SEE readchunk i less than 100.

Mar 11 18:51:41 AsteriskDemo1 kernel:
Mar 11 18:51:41 AsteriskDemo1 kernel:  
Mar 11 18:51:41 AsteriskDemo1 kernel:  readchunk = 11 reg0shadow = 8 | reg1shadow = 1 ios= 20 dead = 0  pos = 0  polarity = -1 polaritydebounce = 0  cidtimer = 144655
Mar 11 18:51:41 AsteriskDemo1 kernel:  
Mar 11 18:51:41 AsteriskDemo1 kernel: DTMF CLIP on 1
Mar 11 18:51:41 AsteriskDemo1 kernel: RING on 1/1!
Mar 11 18:51:43 AsteriskDemo1 kernel: NO RING on 1/1!
Mar 11 18:51:43 AsteriskDemo1 kernel: 1726161 Polarity reversed (-1 -> 1)
Mar 11 18:51:44 AsteriskDemo1 kernel:
Mar 11 18:51:44 AsteriskDemo1 kernel:  
Mar 11 18:51:44 AsteriskDemo1 kernel:  readchunk = 7 reg0shadow = 12 | reg1shadow = 46 ios= 20 dead = 0  pos = 0  polarity = 1 polaritydebounce = 0  cidtimer = 147282
Mar 11 18:51:44 AsteriskDemo1 kernel:  
Mar 11 18:51:44 AsteriskDemo1 kernel: DTMF CLIP on 1
Mar 11 18:51:44 AsteriskDemo1 kernel: 1727169 Polarity reversed (1 -> -1)

I hope this information be helpfull.

Regards
csiebel
By: Charlie Pechiar (charlie) 2007-04-11 17:07:21

Dear csiebel and developers,

I also live in Uruguay and have the same problem with the CID detection.

As I am not an expert in patching source code I am not sure if I am doing things correctly.

After the supposed patch I get the following message on asterisk console after I hung up the call:

 -- Hungup 'Zap/1-1'
 == Starting post polarity CID detection on channel 1
 -- Starting simple switch on 'Zap/1-1'
Apr 11 18:56:21 WARNING[28385]: chan_zap.c:5961 ss_thread: DTMFCID timed out waiting for ring. Exith
 -- Hungup 'Zap/1-1'

but get no CID info what so ever.

Only once managed to get the CID info and this happened when I received a call imediately after I hang up the line. It is coherent whith the messages observed on the console.

Did you manage to solve the problem? Are you now gettin CID info correctly?

Thanks.

CH!
By: Marcelo Oliveira (mcelo) 2007-05-30 08:16:55

Can I Try this patch on another zaptel version? Like 1.2.17.1 ?
By: Hamid Hashemi (hamid) 2007-07-13 17:04:03

I did test the patch and it didn't work for me. I am in Iran and our clid is DTMF based and based on my tests with a Panasonic handset it got the clid before the first ring. I asked for the PSTN switch vendor and it is EWSD ( Siemens ) switch.
I did test the normal wctdm with asterisk and there was no CLIP and after I patched the wctdm.c with this patch and used csiebel method for debug I got this in messages but I didn't have clid on my phone :

Jul 14 01:20:36 home kernel:
Jul 14 01:20:36 home kernel:  
Jul 14 01:20:36 home kernel:  readchunk = 141 reg0shadow = 203 | reg1shadow = 232 ios= 20 dead = 0 pos = 0 polarity = -1 polaritydebounce = 0 cidtimer = 215908
Jul 14 01:20:36 home kernel:
Jul 14 01:20:36 home kernel: DTMF CLIP on 2
Jul 14 01:20:36 home kernel: RING on 1/2!
Jul 14 01:20:37 home kernel: NO RING on 1/2!
Jul 14 01:20:41 home kernel:
Jul 14 01:20:41 home kernel:  
Jul 14 01:20:41 home kernel:  readchunk = 130 reg0shadow = 203 | reg1shadow = 0 ios= 20 dead = 0 pos = 0 polarity = -1 polaritydebounce = 0 cidtimer = 220698
Jul 14 01:20:41 home kernel:
Jul 14 01:20:41 home kernel: DTMF CLIP on 2
Jul 14 01:20:41 home kernel: RING on 1/2!
Jul 14 01:20:42 home kernel: NO RING on 1/2!

any suggestion ?
By: tbsky (tbsky) 2007-08-17 11:51:05

hi:
  i am trying asterisk 1.4.9, 1.4.10, 1.4.10.1 with zaptel 1.4.4.
the patch works great in most cases. but sometimes the head of caller-id could be lost. for example, if the real caller-id is "12345678", sometimes asterisk could  only receive "2345678" or "45678". i think maybe sometimes the polarity reverse emulation is not fast enough, so the caller-id is sent before asterisk receiving.
my test machine is dual-core cpu with no users on it, so system performance should  not be an issue.
  how can i fix this? thanks a lot for any reply!!
By: sivaperumalrajamani (sivaperumal) 2007-12-04 05:18:24.000-0600

hi:
  i am trying asterisk svn , 1.4, with zaptel  svn 1.4 in india
the patch works great in most cases. but sometimes the head of caller-id could be lost. for example, if the real caller-id is "12345678", sometimes asterisk could only receive "1234567" or "123456788".
my test machine is FC7 Linux os  with no users on it, so system performance should not be an issue.


By: Thiago Santos (thix_rj_br) 2007-12-28 06:33:09.000-0600

Fleed, could you make your magic on wctdm24xxp too?

I'm also in Brazil connected on a Telefonica line and have hardware to test.

Thanks in advance.


By: Tzafrir Cohen (tzafrir) 2008-02-14 15:38:56.000-0600

I wonder if the faked polarity reversal event can't confuse anybody at a higher level, who will see two polarity reversal events to the same direction.
By: eagleclaw (eagleclaw) 2008-04-02 18:58:56

I have an asterisk box in Brazil, and 4 pots lines through Telefonica. I tried the wctdm_ve_nopolarity.diff patch, recompiled zaptel and added "options wctdm dtmf=1" to modprobe.conf. I also included all the flags on zapata.conf. I didn't have any success.

I am using asterisk 1.4.15 and zaptel 1.4.9 with a TDM 400 card. I also have a raw audio recorded on one of the channels, if I need to upload it.

Is there anything I am not seeing here?

Any comments?


By: fleed (fleed) 2008-04-11 07:13:55

thix_rj_br: I've just added a patch for the wctdm24xxp, but I don't have any hardware to test it on. Could you please try that and report back?

EagleClaw: Try setting the debug=1 parameter for the module and look at the kernel messages for something resembling DTMF CLIP...
By: eagleclaw (eagleclaw) 2008-04-11 07:54:56

Fleed;

This is what I got:

Apr 11 09:58:23 pbx kernel: DTMF CLIP on 4
Apr 11 09:58:23 pbx kernel: RING on 1/4!
Apr 11 09:58:24 pbx kernel: NO RING on 1/4!

It looks like it's not getting polarity reversed.....

By the way: Should I apply both of the patches, or just one of them? I tried to patch both and it didn't work. It gave me error on the second patch, and when I  make install, it didn't install. So I used just one of the patches (wctdm_ve_nopolarity.diff). Could this be the problem?

Thanks.


By: fleed (fleed) 2008-04-16 10:03:05

Hi EagleClaw, DTMF CLIP means it is detecting the tones that come in before the ring. Just applying wctdm_v3_nopolarity.diff is fine.

Try setting verbose in asterisk (set verbose 9) while a call is coming in to check what kind of messages you're getting. Did you setup your zapata.conf as in the bug description?
By: Thiago Santos (thix_rj_br) 2008-04-16 12:19:49

Sorry I'm late, guys...
Fleed, I'm going to test your patch this night and I'll provide some feedback soon.

So... I patched zaptel 1.4.9.1 and compiled it sucessfully, but was not able to get CID working.

Apr 17 03:20:06 kernel: DTMF CLIP on 4
Apr 17 03:20:06 kernel: RING on 1/4!
Apr 17 03:20:06 kernel: 240332088 Polarity reversed (-1 -> 1)
Apr 17 03:20:06 kernel: NO RING on 1/4!
Apr 17 03:20:06 kernel: 240332404 Polarity reversed (1 -> -1)
Apr 17 03:20:17 kernel: DTMF CLIP on 4
Apr 17 03:20:17 kernel: RING on 1/4!
Apr 17 03:20:17 kernel: NO RING on 1/4!

== Starting post polarity CID detection on channel 4
   -- Starting simple switch on 'Zap/4-1'
   -- Executing [s@default:1] Answer("Zap/4-1", "") in new stack
   -- Executing [s@default:2] NoOp("Zap/4-1", "") in new stack
   -- Executing [s@default:3] Echo("Zap/4-1", "") in new stack
 == Spawn extension (default, s, 3) exited non-zero on 'Zap/4-1'
   -- Hungup 'Zap/4-1'
 == Starting post polarity CID detection on channel 4
   -- Starting simple switch on 'Zap/4-1'
[Apr 17 03:20:19] WARNING[19317]: chan_zap.c:6117 ss_thread: DTMFCID timed out waiting for ring. Exiting simple switch
   -- Hungup 'Zap/4-1'

The NOOP is showing the CallerId information.

Fleed, what kind of information may I provide to help the debugging?


By: fleed (fleed) 2008-04-21 05:18:55

thix_rj_br:
This is what I get,
 == Starting post polarity CID detection on channel 1
[Apr 21 07:15:43] DEBUG[8968]: dsp.c:1680 ast_dsp_set_busy_pattern: dsp busy pattern set to 0,0
   -- Starting simple switch on 'Zap/1-1'
[Apr 21 07:15:43] DEBUG[12223]: chan_zap.c:6104 ss_thread: Receiving DTMF cid on channel Zap/1-1
[Apr 21 07:15:44] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit 'A'
[Apr 21 07:15:44] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '1'
[Apr 21 07:15:44] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '7'
[Apr 21 07:15:45] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '1'
[Apr 21 07:15:45] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '2'
[Apr 21 07:15:45] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '1'
[Apr 21 07:15:45] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '0'
[Apr 21 07:15:45] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '1'
[Apr 21 07:15:45] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '0'
[Apr 21 07:15:46] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '0'
[Apr 21 07:15:46] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '0'
[Apr 21 07:15:46] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit '6'
[Apr 21 07:15:46] DEBUG[12223]: chan_zap.c:4484 zt_handle_event: Ignoring Polarity switch to IDLE on channel 1, state 9
[Apr 21 07:15:46] DEBUG[12223]: chan_zap.c:4487 zt_handle_event: Polarity Reversal event occured - DEBUG 2: channel 1, state 9, pol= 0, aonp= 0, honp= 0, pdelay= 600, tv= 1887136309
[Apr 21 07:15:46] DEBUG[12223]: chan_zap.c:6122 ss_thread: CID got digit 'C'


Try setting verbose to 9 on the console and checking how long it takes between the following messages on your system:
== Starting post polarity CID detection on channel 4
and
-- Executing [s@default:1] Answer("Zap/4-1", "") in new stack

It should take a few seconds, in my case 3 seconds. It's the time it takes for the dtmf number to be sent. Just to make sure, you are subscribing to telemar's callerid feature, right?

If you want we can try debugging this privately.
By: Thiago Santos (thix_rj_br) 2008-04-28 04:30:29

Fleed, please, add my msn.

santos_thiago at hotmail dot com
By: Russell Bryant (russell) 2008-05-09 15:28:49

Fleed, the patches you originally uploaded were not marked as code.  Also, at that time, you had not signed the electronic license agreement.  I can see that you have it in place, now.  Can you please re-upload the first two files?
By: Arnold C. Estanislao (trijae) 2008-05-11 02:48:18

Hi Fleed,

I'm from Saudi Arabia and experiencing the same Caller ID Detection problem with my TDM24xxp.

I tried you patch but still didn't get any CID. Calling from any land phone to my Asterisk produces no error and no CID, while calling from a mobile phone to my Asterisk prompts my Asterisk to dial "C" causing of course a logic error in my dial plan. I would say that what I am experiencing is similar to csiebel's.

Would you think this kind of a CID problem is related to the Amphenol Cable used. CID detection though not voltage related, maybe being affected by the reduction of   signal because of the use of the Amphenol Cable from the POTS line to the TDM24xxp.

Regards,
By: Steve Murphy (murf) 2008-06-20 12:46:25

OK, I volunteered to help see what I can do to close this issue. After reading the notes I have come to these conclusions:

a. fleed-- could you re-post the wctdm_v3_*_nopolarity patches? The new system of licensing demands it, which certainly irritating, but it **is** very helpful in protecting us from legal problems.

b. these patches will need to be brought up to date against dahdi, which will hopefully be completely trivial. I can do it, if that would be helpful.

c. These patches work for fleed, in Brazil. But others:
      csiebel in Uruguay
      hamid in Iran
      trijae in Saudi Arabia
           are all getting no cid at all...
      tbsky (Country unknown), sivaperumal (India), are having partial-cid
            problems.

d. did EagleClaw in Brazil get his problems resolved?

e. did thix_rj_br get his problems resolved?

f. I noticed (with sivaperumal), that he might be benefitted by the doc/India-CID.txt file; perhaps, if he has success with these patches, we can add a note to that report.

g. for the folks who are getting partial cid, is there any way to start cid recognition earlier?
By: tbsky (tbsky) 2008-06-21 02:10:39

Dear murf:

 thanks a lot for your effort. I live in Taiwan and i can get correct CID with this patch now.
 i am using zaptel 1.4.11 and asterisk 1.4.20.1 with the patch in bug 0012658.
that patch fix the "dtmf digits swap" problem.
 and to fix the partial cid problem, i found the "fwringdetect" parameter is working well. so my wctdm start like this:

  modprobe wctdm dtmf=1 opermode=TAIWAN fwringdetect=1

  with the above effort,i can get reliable cid now.
  hope this patch can get into the official dahdi release.
By: Steve Murphy (murf) 2008-06-21 12:52:28

Perhaps I'm jumping the gun, but with fleed not responding, I went ahead
and took the one patch I could inspect, and applied those changes to the
new dahdi equivalents. Then I back-extrapolated those same changes into
the wctdm.c file.

For those of you who haven't switched over to the dahdi drivers from the
zaptel drivers, you will need to do an svn checkout of http://svn.digium.com/svn/dahdi/linux
and
http://svn.digium.com/svn/dahdi/tools

my patch applies to the stuff in the dahdi/linux dir.

Since I don't have the ability to test any of this, I need everyone
hoping to have these changes merged into the drivers to test the
patch and verify that it works both in the wctdm and 24xxp versions.

I looked at the fxo (wilcard) driver, and I didn't get a warm
and fuzzy feeling that these changes would apply there.

By: Steve Murphy (murf) 2008-06-21 12:55:44

Oh, yes, my patch is the "9096.nopolaritypatch" -- forgot to mention that.
By: eagleclaw (eagleclaw) 2008-06-21 13:35:33

Murf;

I didn't resolve the issues yet. I am flying to Brazil this weekend and will try to apply the latest patch and report the results.

Thanks.
By: Angelo Braga (prolinx) 2008-06-23 18:43:24

Hello,

I'am from Brazil and i have de digium TDM410P (wctdm24xxp). I use the asterisk version 1.2.29 with zaptel 1.2.24.

Can apply this patch with these versions that i use?

What is the procedure to adopt?
By: Angelo Braga (prolinx) 2008-07-01 13:53:42

Hello,

I'am from Brazil and i have de digium TDM410P (wctdm24xxp). I use the asterisk version 1.2.29 with zaptel 1.2.24.

Can apply this patch with these versions that i use?

What is the procedure to adopt?


Please, i can use this patch on zaptel 1.2.24?

Thanks!
Angelo
By: Nebi INAN (uruguay) 2008-07-28 23:34:16

Hi everyone

I am so sorry but I very new.
and I just dont know how to use pach files.
I am using elastix interface, any help would be great.

thanks
Nebi
By: anonymouz666 (anonymouz666) 2008-08-28 11:22:38

I have been using this patch for a long time. Started with zaptel-1.2 and the wctdm driver and now using wctdm with zaptel-1.4. Using the wctdm24xxp (TDM800 card) patched, a 'modprobe wctdm24xxp dtmf=1 debug=1' makes a kernel panic.

Anyone in here already TESTED this patch against wctdm24xxp?
I am using zaptel-1.4.10.1.
Linux 2.6.18-8.el5 #1 SMP Thu Mar 15 19:57:35 EDT 2007 i686 i686 i386 GNU/Linux
By: Phamtam (cafe) 2008-09-02 21:06:13

Hi,
I use asterisk version: 1.4.20.1 and zaptel verison: 1.4.11. Card TDM400p  modules FXO.
zaptel.conf:  
loadzone=us
defaultzone=us
I do not detect callerID,
Please help me, how to fix this bug?

Which use file path?
wctdm_v3_nopolarity.diff (2,958 bytes) 2007-03-02 08:24 [License NONE]
wctdm_v3_trunk_nopolarity.diff (3,467 bytes) 2007-03-02 12:21 [License NONE]
wctdm24xxp_nopolarity.diff [^] (3,533 bytes) 2008-04-11 07:09 [wget patch] [License OK]wget 'http://bugs.digium.com/file_download.php?file_id=18491&type=bug' -O - | patch -p0
9096.nopolaritypatch [^] (7,137 bytes) 2008-06-21 12:33 [wget patch] [License OK]
By: Tzafrir Cohen (tzafrir) 2008-09-04 02:35:55

A similar patch for xpp/fxo driver seems to work as well too.
By: Angelo Braga (prolinx) 2008-09-04 08:07:45

Anonymouz666,

Do you have the patch for the zaptel 1.2? You can send to me?

Thanks,

Angelo
By: Digium Subversion (svnbot) 2008-09-09 07:50:32

Repository: zaptel
Revision: 4519

U   branches/1.2/xpp/card_fxo.c

------------------------------------------------------------------------
r4519 | tzafrir | 2008-09-09 07:50:31 -0500 (Tue, 09 Sep 2008) | 5 lines

xpp-zaptel: FXO: Add caller-id workaround for ESTI-DTMF (for DAHLIN-4)
* Also rename the CID_STYLE_* constants to formal names.

From Xorcom Rev. 6115.

------------------------------------------------------------------------

http://svn.digium.com/view/zaptel?view=rev&revision=4519
By: Digium Subversion (svnbot) 2008-09-25 06:35:32

Repository: dahdi
Revision: 4979

U   linux/trunk/drivers/dahdi/xpp/card_fxo.c

------------------------------------------------------------------------
r4979 | tzafrir | 2008-09-25 06:35:31 -0500 (Thu, 25 Sep 2008) | 3 lines

XPP FXO: Add caller-id workaround for ESTI-DTMF (for DAHLIN-4)
* Also rename the CID_STYLE_* constants to formal names.

------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=4979
By: grecco (grecco) 2008-11-17 18:43:59.000-0600

None had success using in Brazil, AEX8000 card, tele BrasilTelecom.
Asterisk-1.4.22 and Dahid-2.0.
I can not recognize the CallerId.
How can I contribute to the tests?


By: Evandro César Arruda (ecarruda) 2008-12-16 15:47:42.000-0600

I don't have sucesss to using TDM800P on Brazil,with Telefonica Carrier.

If have anything I can do, please tell me, i like to help on this process, it's very important to us on Brazil.

Regards,
Evandro Arruda
evandro@ezvoice.com.br
By: loos (loos) 2009-01-06 19:05:33.000-0600

I make it work here... Telefonica with TDM400, asterisk-1.4.22 and zaptel-bsd-1.4.11

The problem is that DTMF Clip is being detected too late, so when the thread that read the dtmf callerid starts, the cid is already sent.

So i change this:

+ if (sample > 16000 || sample < -16000) {
+ wc->mod[card].fxo.readcid = 1;

To this (on patch):

+ if (sample > 2000 || sample < -2000) {
+ wc->mod[card].fxo.readcid = 1;

And the patch is working :)

I also change the dtmf detect timeout, but i think this is not change anything (used just for debug purposes).

Here is the log:

 == Starting post polarity CID detection on channel 1
   -- Starting simple switch on 'Zap/1-1'
 == Receiving DTMF cid on channel Zap/1-1
 == CID got digit 'A'
 == CID got digit '1'
 == CID got digit '1'
 == CID got digit '4'
 == CID got digit '9'
 == CID got digit '7'
 == CID got digit 'X'
 == CID got digit 'X'
 == CID got digit 'X'
 == CID got digit 'X'
 == CID got digit 'X'
 == CID got digit '5'
 == CID got digit 'C'
 == CID got string 'A11497XXXXX5C'
 == CID is '11497XXXXX5', flags 16
   -- Executing [s@default:1] Set("Zap/1-1", "CALLID=11497XXXXX5") in new stack
   -- Executing [s@default:2] Wait("Zap/1-1", "2") in new stack
   -- Executing [s@default:3] Answer("Zap/1-1", "") in new stack
   -- Executing [s@default:4] Playback("Zap/1-1", "invalid") in new stack
   -- <Zap/1-1> Playing 'invalid' (language 'en')
   -- Executing [s@default:5] Hangup("Zap/1-1", "") in new stack
 == Spawn extension (default, s, 5) exited non-zero on 'Zap/1-1'
   -- Hungup 'Zap/1-1'
 == Starting post polarity CID detection on channel 1
   -- Starting simple switch on 'Zap/1-1'
 == Receiving DTMF cid on channel Zap/1-1
[Jan  6 23:02:11] WARNING[3700]: chan_dahdi.c:6263 ss_thread: DTMFCID timed out waiting for ring. Exiting simple switch
   -- Hungup 'Zap/1-1'

Regards,
luiz
By: Leif Madsen (lmadsen) 2009-01-09 07:42:10.000-0600

Changing this status to Ready For Review, but murf, be sure to look at the last note as there appears to be a minor tweak required in order to make it work.
By: loos (loos) 2009-01-09 08:43:35.000-0600

i would love to hear anything from others brazilians users.

My change should be tested in other environments too, it may get some false positives due to noise on line.

I'll try too contact another person in private too see if i can help them to get it working.

luiz
By: loos (loos) 2009-01-21 12:25:32.000-0600

i've some patchs here for testing...

I've tried with some success in others environments too, but i got some noise when connected to an intelbras pbx, but this is working fine on telefonica lines.

Please give this patch a try. if you need something, just contact me.

thanks,
luiz
PS: i found that is absolutely necessary patch the chan_dahdi.c on asterisk to change the callerid timeout (as you will get the DTMF CLIP earlier). this is why i post the second patch.
loos.br at gmail dot com


By: Leif Madsen (lmadsen) 2009-01-22 15:19:39.000-0600

loos:

could you actually attach these patches to the bug here? Otherwise they will never go into Asterisk, and there isn't much point in people testing them.
By: nivio (nivio) 2009-01-22 16:26:22.000-0600

I applied patch 9096.nopolaritypatch on dahdi-linux, but I had errors:

patching file drivers/dahdi/wctdm.c
Hunk #1 succeeded at 226 (offset -2 lines).
Hunk #2 succeeded at 292 (offset -1 lines).
Hunk #3 succeeded at 385 (offset -1 lines).
Hunk #4 FAILED at 424.
Hunk ASTERISK-1 succeeded at 822 with fuzz 2.
Hunk ASTERISK-2 FAILED at 840.
Hunk ASTERISK-3 succeeded at 2530 (offset 1 line).

2 out of 7 hunks FAILED -- saving rejects to file drivers/dahdi/wctdm.c.rej

patching file drivers/dahdi/wctdm24xxp/wctdm24xxp.h
Hunk #1 FAILED at 230.

1 out of 1 hunk FAILED -- saving rejects to file drivers/dahdi/wctdm24xxp/wctdm24xxp.h.rej

patching file drivers/dahdi/wctdm24xxp/base.c
Hunk #1 succeeded at 224 (offset 12 lines).
Hunk #2 succeeded at 853 (offset 12 lines).
Hunk #3 succeeded at 900 (offset 12 lines).
Hunk #4 FAILED at 1194.
Hunk ASTERISK-1 FAILED at 1223.
Hunk ASTERISK-2 succeeded at 4140 with fuzz 2 (offset 113 lines).

2 out of 6 hunks FAILED -- saving rejects to file drivers/dahdi/wctdm24xxp/base.c.rej

Please, I need work it.
By: loos (loos) 2009-01-23 05:23:15.000-0600

blitzrage: i will :) Sorry for the noise, i'm not really aware of how this things works here (but i'm young - i'll learn ;) ). Just let me update this patches, looks like it is difficult to people apply then by hand.
By: loos (loos) 2009-01-23 05:24:43.000-0600

nivio: what version of zaptel are you using ?
By: loos (loos) 2009-01-23 05:46:11.000-0600

blitzrage:

I've found that this solution is somewhat weak. There is a variable amount of time from the detection of dtmf (dtmf clip) by zaptel and the actual dtmf decoding by asterisk.

I dont known if this will work with a high loaded asterisk, due to this 'time to answer' from asterisk.

I think this (dtmf decoding) should be done in zaptel, but i don't known zaptel and asterisk to do this and i cannot find no one to talk about this issue, so if you could point me someone or some reference that put me on the right direction, please contact me.
By: nivio (nivio) 2009-01-23 06:21:04.000-0600

loss: I am using dahdi-linux-2.1.0.3.
By: loos (loos) 2009-01-23 08:00:33.000-0600

nivio: could you please test the patch that i've uploaded ?
By: Leif Madsen (lmadsen) 2009-01-23 08:30:42.000-0600

loos: no problem, thanks for following up so quickly.

I'm going to assign this issue to sruffell to see if he can take a look at it, as he is probably more appropriate to move this issue forward than murf.

In addition based on your comments, I'm going to drop the status of this bug down to 'Confirmed', which means there are patches attached to the issue, but that they are not quite ready for final testing prior to commit (however testing is of course encouraged at all stages!)
By: Leif Madsen (lmadsen) 2009-01-23 08:32:55.000-0600

I've reassigned this to sruffell now as it seems loos, who is trying to resolve this issue, needs some guidance as to whether his approach is correct.
By: nivio (nivio) 2009-01-23 09:19:50.000-0600

loss: Thanks, the patch was applied sucessfully. I'll test if work fine.
By: nivio (nivio) 2009-01-23 09:25:23.000-0600

loss: I meet more errors. Building dahdi-linux shows errors:

/home/nivio/dahdi-linux-2.1.0.3/drivers/dahdi/wctdm.c: In function ‘wctdm_dtmfcheck_fakepolarity’:
/home/nivio/dahdi-linux-2.1.0.3/drivers/dahdi/wctdm.c:399: error: request for member ‘xlaw’ in something not a structure or union
/home/nivio/dahdi-linux-2.1.0.3/drivers/dahdi/wctdm.c:399: error: request for member ‘readchunk’ in something not a structure or union
/home/nivio/dahdi-linux-2.1.0.3/drivers/dahdi/wctdm.c:404: warning: passing argument 1 of ‘dahdi_qevent_lock’ from incompatible pointer type
make[2]: *** [/home/nivio/dahdi-linux-2.1.0.3/drivers/dahdi/wctdm.o] Error 1
make[1]: *** [_module_/home/nivio/dahdi-linux-2.1.0.3/drivers/dahdi] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.24-23-generic'
make: *** [modules] Error 2
By: nivio (nivio) 2009-01-23 09:35:48.000-0600

loss: asterisk builds fine.
By: nivio (nivio) 2009-01-23 09:43:05.000-0600

loss: asterisk startups fine.
By: loos (loos) 2009-01-24 05:32:38.000-0600

nivio: my bad... i dont have a linux system here to test. My version (zaptel-bsd) is a little bit different.

please try the version 2 of this patch, it will work

thanks!
By: loos (loos) 2009-01-24 05:36:33.000-0600

blitzrage: thanks ! i think this new status is more accurate, at least for now.
By: nivio (nivio) 2009-01-24 07:10:10.000-0600

loss: with the patch v2, dahdi-linux builds fine.
By: nivio (nivio) 2009-01-24 07:15:59.000-0600

I'll test dahdi-linux patched and I'll report results.
By: nivio (nivio) 2009-01-24 07:16:42.000-0600

Thanks loss.
By: Tzafrir Cohen (tzafrir) 2009-01-27 11:32:16.000-0600

Adding a zaptel version of 9096.nopolaritypatch-dahdi-linux-2.1.0.3-v2.diff to help testers.

That version is only tested to build. I suppose it will also work, but I'm not completely sure.
By: Evandro César Arruda (ecarruda) 2009-01-27 13:59:58.000-0600

loos,

Send to me your chan_dahdi.conf configuration, i tried but don't work to me on São José dos Campos


When i call to fxo I see on debug for all callerid digits:

[Jan 27 18:06:53] DEBUG[7446]: chan_dahdi.c:5158 dahdi_handle_event: Ignoring Polarity switch to IDLE on channel 2, state 9
[Jan 27 18:06:53] DEBUG[7446]: chan_dahdi.c:5161 dahdi_handle_event: Polarity Reversal event occured - DEBUG 2: channel 2, state 9, pol= 0, aonp= 0, honp= 0, pdelay= 600, tv= 431199600


Thanks


By: Hesham Ahmed (hahmed) 2009-04-27 04:08:44

*EDIT* Managed to fix the kernel panic by adding code to delay fakepolarity detection till all the ports are initialized in the module. CID detections works fine in Saudi Arabia

tzafrir: 9096.nopolaritypatch-dahdi-linux-2.1.0.3-v2.diff applies and builds cleanly on both dahdi 2.1.0.3 and 2.1.0.4 but gives kernel panic on at least the following kernels:

2.6.18 (Elastix 1.5.2)
2.6.23 (Ubuntu Hardy Heron)

Tested with a Digium TDM800 card with 8 FXO lines

Kernel crash log:

dahdi_transcode: Unloaded.
ACPI: PCI interrupt for device 0000:0a:01.0 disabled
Freed a Wildcard
dahdi: Telephony Interface Unloaded
dahdi: Telephony Interface Registered on major 196
dahdi: Version: 2.1.0.4
PCI: Enabling device 0000:0a:01.0 (0150 -> 0153)
ACPI: PCI Interrupt 0000:0a:01.0[A] -> GSI 26 (level, low) -> IRQ 201
ProSLIC on module 0, product 3, version 15
VoiceDAA System: 04
ISO-Cap is now up, line side: 03 rev 06
setting FXO tx gain for card=0 to 0
setting FXO rx gain for card=0 to 0
DEBUG fxotxgain:0.0 fxorxgain:0.0
Port 1: Installed -- AUTO FXO (FCC mode)
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
f8b67712
*pde = 7ec50067
Oops: 0000 [#1]
SMP
last sysfs file: /class/dahdi/dahdi!ctl/dev
Modules linked in: wctdm24xxp(U) wcte11xp(U) wct1xxp(U) wcte12xp(U) wct4xxp(U) dahdi(U) ipv6 xfrm_nalgo crypto_api crc_ccitt sunrpc dm_multipath video sbs backlight i2c_ec button battery asus_acpi ac parport_pc lp parport scb2_flash mtdc
ore chipreg pcspkr tg3 floppy i2c_piix4 i2c_core cpqphp serio_raw dm_snapshot dm_zero dm_mirror dm_mod cciss sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
CPU:    0
EIP:    0060:[<f8b67712>]    Tainted: G      VLI
EFLAGS: 00010246   (2.6.18-92.1.22.el5 #1)
EIP is at handle_receive+0x2bc/0x617 [wctdm24xxp]
eax: 00000000   ebx: 00000000   ecx: f6f36000   edx: f6a94000
esi: 07901d00   edi: f6f36000   ebp: 0000000a   esp: c074cf84
ds: 007b   es: 007b   ss: 0068
Process kjournald (pid: 415, ti=c074c000 task=f7f81aa0 task.ti=f7f82000)
Stack: 00000016 7b4d3800 00000082 00000082 00000000 00000246 f6511c18 f6511c00
      f6e7be14 f6e7be00 f6512400 f6511c00 f8b78faf 00000041 f74231e0 00000000
      00000000 000000c9 c044deb3 f7f82f04 c06e5300 000000c9 f74231e0 c06e5328
Call Trace:
[<f8b78faf>] vb_isr+0x1af/0x634 [wctdm24xxp]
[<c044deb3>] handle_IRQ_event+0x23/0x49
[<c044df5d>] __do_IRQ+0x84/0xd6
[<c04073f4>] do_IRQ+0x93/0xae
[<c040592e>] common_interrupt+0x1a/0x20
[<f8852dde>] journal_file_buffer+0x44/0x62 [jbd]
[<f88537c1>] journal_commit_transaction+0x961/0xf18 [jbd]
[<c042d934>] lock_timer_base+0x15/0x2f
[<f8856c01>] kjournald+0xa1/0x1c2 [jbd]
[<c0435f3b>] autoremove_wake_function+0x0/0x2d
[<f8856b60>] kjournald+0x0/0x1c2 [jbd]
[<c0435e79>] kthread+0xc0/0xeb
[<c0435db9>] kthread+0x0/0xeb
[<c0405c3b>] kernel_thread_helper+0x7/0x10
=======================
Code: 00 0f 85 80 00 00 00 8b 81 84 04 00 00 05 90 01 00 00 39 87 10 02 00 00 76 6d 8b 94 9f 48 11 00 00 8b 44 24 10 03 82 94 00 00 00 <0f> b6 00 01 c0 03 82 9c 08 00 00 0f bf 00 05 d0 07 00 00 3d a0
EIP: [<f8b67712>] handle_receive+0x2bc/0x617 [wctdm24xxp] SS:ESP 0068:c074cf84
BUG: warning at arch/i386/kernel/crash.c:145/nmi_shootdown_cpus() (Tainted: G     )
[<c041b332>] machine_crash_shutdown+0x88/0xc5
[<c04441f5>] crash_kexec+0x96/0xad
[<f8b67712>] handle_receive+0x2bc/0x617 [wctdm24xxp]
[<c04064b3>] die+0x233/0x291
[<c060ae93>] do_page_fault+0x3ea/0x4b8
[<c060aaa9>] do_page_fault+0x0/0x4b8
[<c0405a71>] error_code+0x39/0x40
[<f8b67712>] handle_receive+0x2bc/0x617 [wctdm24xxp]
[<f8b78faf>] vb_isr+0x1af/0x634 [wctdm24xxp]
[<c044deb3>] handle_IRQ_event+0x23/0x49
[<c044df5d>] __do_IRQ+0x84/0xd6
[<c04073f4>] do_IRQ+0x93/0xae
[<c040592e>] common_interrupt+0x1a/0x20
[<f8852dde>] journal_file_buffer+0x44/0x62 [jbd]
[<f88537c1>] journal_commit_transaction+0x961/0xf18 [jbd]
[<c042d934>] lock_timer_base+0x15/0x2f
[<f8856c01>] kjournald+0xa1/0x1c2 [jbd]
[<c0435f3b>] autoremove_wake_function+0x0/0x2d
[<f8856b60>] kjournald+0x0/0x1c2 [jbd]
[<c0435e79>] kthread+0xc0/0xeb
[<c0435db9>] kthread+0x0/0xeb
[<c0405c3b>] kernel_thread_helper+0x7/0x10
=======================


By: Luar Roji (cyberplant) 2009-05-08 02:49:50

Hi all!

I've tested the patch, but don't works for Uruguay.

Correct me if I made something wrong.. downloaded the patch for dahdi-linux, applied it, compiled, installed and loaded the new kernel driver with the parameter dtmf=1 in wctdm.

After that downloaded and applied the patch to asterisk. Compiled, installed and started asterisk.

The patches gave some rejects but I managed to patch manually.

All OK, but didn't work at all the callerid.. Any ideas?

Thanks.
By: zelik888 (zelik888) 2009-06-10 10:08:20

I've tested this patch for zaptel and it works fine (detects caller id in Taiwan) but I'm getting an issue with busydetect.

Since I can't get polarity reversal, I'm relying on busydetect to detect hangups.  If an incoming call is on ZAP and is bridged out to a SIP/IAX channel, busydetect will not work if the incoming zap call decides to hang up before the destination SIP/IAX channel picksup.  It will keep ringing the destination channel even though the caller hungup (and the telco is generating the busy tone for hangup).

On calls that are not bridged (zap->IVR) the busydetect works fine


By: Shaun Ruffell (sruffell) 2009-06-18 12:12:38

I've attached 9096.nopolaritypatch-dahdi-linux-trunk-r6690.  This updates the patch to apply to trunk and also moves the fakepolarity call on the wctdm24xxp driver out of the vpm100 block and into the wc->initialized block which appears to be the way to go.  However, I have not tested this.
By: Ronald Chan (loloski) 2009-06-21 07:53:21

sruffell,

could you please post a similar patch against dahdi-2.1.0.4, so that other can test this? i'm also running into this issue, but i can't test this for now on a dahdi driver based on trunk.

many thanks.

hahmed,

can you post your changes on v2.diff ? if sruffel can't post a patch againt 2.1.0.4

Thanks to both of you!
By: Luar Roji (cyberplant) 2009-06-28 17:21:32

Well.. It doesn't work yet for Uruguay.

I've found that my phone company has "polarity reversal" for a fee, so I decided to go for it. Now I've solved my hangup detection problems, but the callerid still doesn't work.

I've discovered that the polarity reversal is AFTER the DTMF's of the callerid! Sounds weird!

So, here it's like:
[idle][DTMF's CallerID][polarity reversal][RING]...[polarity reversal (hangup)].

Any ideas?
By: Sebastian Gutierrez (sum) 2009-07-21 12:23:55

What is needed to move this issue forward? I had the same problem, used the patch and work perfect, the patch didn't apply cleanly to DAHDI trunk but is easy to get it working, do you need any more info? I'm using trunk version of dahdi and asterisk 1.6.2

cyberplant: this patch should work for you. I've tested it in Uruguay also, and works ok.
By: Shaun Ruffell (sruffell) 2009-07-23 15:40:56

I'm aware of one person who is using the patch that still has the issue, but what really needs to be done is that I need to audit the patch to convince myself that it won't cause problems for the users who do not need it.
By: Sebastian Gutierrez (sum) 2009-07-23 16:23:42

maybe the dtmf option that the module is loaded with could be a new option of chan_dahdi.conf so it won't change the beheavior for the people who don't need this, defaulting it to 0, what do you think?.
By: Sebastian Gutierrez (sum) 2009-08-18 10:27:50

I'm using this with no problems yet, but using this I'm missing CDR callerid in Master.csv and also on MySQL backend, maybe it misses some function call to get the CDR(scr) and CDR(clid, any idea??

As a workaround I'm setting CDR(userfield) with the value of CallerID(num) to get the callerid on the CDR.

UPDATE: this was happening testing Answer and Background and then hangup.
now with queues, etc is setting the cdr just fine.
I can confirm this patch works on a line with polarity reversal activated for incoming and outgoing as well with a line that has no polarity reversal activated.


By: Doug Bailey (dbailey) 2009-08-20 13:53:07

Instead of using the driver to send what is a false event (i.e. a polarity event when none has actually occurred) I have posted a patch that has chan_dahdi monitor the incoming channel to look for the incoming line traversal that should signal the start of DTMF CID.  ( 9096-chan_dahdi-trunk.diff)

This uses the same mechanism that is already in place for detecting incoming MWI FSK spills in the do_monitor loop.  

At present, this is trunk only.
By: Sebastian Gutierrez (sum) 2009-08-24 21:46:44

I could test it if I can port this to 1.6.2 branch, the problem is the sig_analog part, that I'm not sure how this code goes into this branch.
By: Doug Bailey (dbailey) 2009-08-25 16:08:42

The addition of sig_analog has really made it difficult to back port chan_dahdi centric trunk patches into 1.6.2.  Is there anyway you can build trunk to test out this feature?
By: Sebastian Gutierrez (sum) 2009-08-25 16:26:46

I can test it this week with trunk version, but just for basic testing porpouse, if we can get the patch on 1.6.2 I could test in a production environment.
I'll post this week the result of this basic testing using the las trunk svn version avaiable at the time I test.
By: R.deAndres (maturs) 2009-08-28 10:46:33

sum, i'm trying the patch in Uruguay. i patched the zaptel module with 9096.nopolaritypatch-zaptel.diff and i can't detect the caller id yet. Can you give some guidelines on what to do. Thank's
By: Shaun Ruffell (sruffell) 2009-08-28 10:50:23

maturs:  Could you try the 9096-chan_dahdi-trunk.diff patch that dbailey made against the trunk of Asterisk?  I think dbailey is right that this belongs in chan_dahdi and not in the drivers.  If it works, then the drivers will never be patched for this issue.
By: R.deAndres (maturs) 2009-08-28 11:46:56

sruffell. i don't have the files sig_analog.c and sig_analog.h to apply the patch.
I'm using asterisk-1.6.1.4,  dahdi-linux-2.2.0.2.
Do i have to compile another module??

Thanks


By: Doug Bailey (dbailey) 2009-08-28 13:17:18

The patch is based off of the trunk asterisk build.

It is available using subversion and retrieving it from:
http://svn.asterisk.org/svn/asterisk/trunk
By: R.deAndres (maturs) 2009-08-28 16:52:39

i need to use the zaptel patch in uruguay. i'm using asterisk-1.4.26.1 and zaptel-1.4.12.1. I can't get CID yet. do anyone tested the 9096.nopolaritypatch-zaptel.diff in uruguay?? thanks
By: Shaun Ruffell (sruffell) 2009-08-28 16:54:05

maturs: Why can't you use DAHDI and the asterisk trunk for testing?  Is there some technical reason you can't upgrade just to test?
By: R.deAndres (maturs) 2009-08-28 17:09:53

yes sruffell. I'm running other applications that are incompatible with the newer version. Do u need try the trunk version patch to be sure that it works??? maybe i can do that test on another server if necessary .. just let me know.
By: R.deAndres (maturs) 2009-08-28 19:12:17

i'd  tried the 9096-chan_dahdi-trunk.diff patch on the trunk version (only this patch) and can't get CID yet.
my /etc/dahdi/system.conf
loadzone=br
defaultzone=br

#Sangoma AFT-A200 [slot:4 bus:2 span:1] <wanpipe1>
fxsks=1
echocanceller=mg2,1
fxsks=2
echocanceller=mg2,2
fxsks=3
echocanceller=mg2,3
fxsks=4
echocanceller=mg2,4
fxsks=5
echocanceller=mg2,5
fxsks=6
echocanceller=mg2,6
fxsks=7
echocanceller=mg2,7
fxsks=8
echocanceller=mg2,8

/etc/asterisk/chan_dahdi.conf

;Sangoma AFT-A200 [slot:4 bus:2 span:1]  <wanpipe1>
context=from-zaptel
callerid=asreceived
usecallerid=yes
cidsignalling=dtmf
hidecallerid=no
cidstart=polarity
group=0
echocancel=yes
signalling = fxs_ks
channel => 1-8

any ideas?? do i have to use 9096.nopolaritypatch-dahdi-linux-trunk-r6690 patch too??

thanks
By: Sebastian Gutierrez (sum) 2009-08-30 14:15:45

ok, Tested with  SVN-trunk-r214819M, the CID is ok, but there seems to be an issue with audio after the line is answer, I just listen static (I don't have that problem without the CID detection). example

 == Starting DTMF CID detection on channel 1
   -- Starting simple switch on 'DAHDI/1-1'
   -- Executing [s@incoming:1] Answer("DAHDI/1-1", "") in new stack
   -- Executing [s@incoming:2] NoOp("DAHDI/1-1", "XXXXXXXXXXX") in new stack
   -- Executing [s@incoming:3] BackGround("DAHDI/1-1", "test") in new stack
   -- <DAHDI/1-1> Playing 'test.gsm' (language 'es')
   -- Auto fallthrough, channel 'DAHDI/1-1' status is 'UNKNOWN'
   -- Hanging up on 'DAHDI/1-1'
   -- Hungup 'DAHDI/1-1'

XXXXX is the callerid detected ok.
the test audio is ok without cid detection, but when I enable it I just listen static. any idea? I have the test environment ready.


By: R.deAndres (maturs) 2009-08-30 16:49:41

sum, could you give me the /etc/dahdi/system.conf and /etc/asterisk/chan_dahdi.conf that your are using??
What type of card are you using (sangoma or digium)??

thanks
By: Doug Bailey (dbailey) 2009-08-31 09:24:20

sum,

These changes from this patch should only affect the detection of when a call starts.

Do you hear the same static when you change cidstart to polarity?   (This will prevent the execution of the patches code.)
By: Doug Bailey (dbailey) 2009-08-31 09:26:17

dditions to chan_dahdi.conf in order to use the 9690_chan_dahdi-trunk patch

; causes monitor loop to look for dtmf energy on the incoming channel to initate
; cid acquisition
cidstart=dtmf

; The energy level used to trigger dtmf cid acquisition.   This number is
; compared to the average over a packet of audio of the absolute values of 16
; bit signed linear samples. The default is set to 256.  The choice of 256 is
; arbitrary.  The value you should select should be high enough to prevent false
; detections while low enough to insure that no dtmf spills are missed.

dtmfcidlevel=256
By: Sebastian Gutierrez (sum) 2009-08-31 09:56:46

maturs, as I can see you have chan_dahdi wrong check the note of dbailey about cidstart.

dbailey, if I use cidstart polarity, I heard a Background audio fine, but If I change it to dtmf I get only static.
By: R.deAndres (maturs) 2009-08-31 15:58:51

sum, can you give the configuration files that you are using?
/etc/asterisk/chan_dahdi.conf
/etc/dahdi/system.conf
/etc/wanpipe/wanpipe1.conf (i have a Sangoma A200)

i still can't get CID in Uruguay, using the 9096-chan_dahdi-trunk.diff patch.
I'm using the asterisk trunk version SVN-trunk-r214945M.

Do this work with Sangoma or it's only for Digium??
Thanks
By: Doug Bailey (dbailey) 2009-08-31 16:22:10

I've confirmed that something is distorting the audio with the 9096-chan_dahdi-trunk.diff patch.  I will try to determine what is causing the problem.
By: R.deAndres (maturs) 2009-08-31 19:25:39

after i applied the patch, i'm getting this:
 == Starting DTMF CID detection on channel 1
   -- Starting simple switch on 'DAHDI/1-1'
[Aug 31 18:20:08] WARNING[6813]: sig_analog.c:2054 __analog_ss_thread: DTMFCID timed out waiting for ring. Exiting simple switch
   -- Hanging up on 'DAHDI/1-1'
   -- Hungup 'DAHDI/1-1'
 == Starting DTMF CID detection on channel 1
   -- Starting simple switch on 'DAHDI/1-1'
[Aug 31 18:20:11] WARNING[6814]: sig_analog.c:2054 __analog_ss_thread: DTMFCID timed out waiting for ring. Exiting simple switch
   -- Hanging up on 'DAHDI/1-1'
   -- Hungup 'DAHDI/1-1'
 == Starting DTMF CID detection on channel 1
   -- Starting simple switch on 'DAHDI/1-1'
   -- Executing [s@from-zaptel:1] Wait("DAHDI/1-1", "2") in new stack
   -- Executing [s@from-zaptel:2] Answer("DAHDI/1-1", "") in new stack    
   -- Executing [s@from-zaptel:3] Verbose("DAHDI/1-1", "Incoming call from BT line  CallerID=") in new stack
Incoming call from BT line  CallerID=


What can i do to make this work?? ==>  DTMFCID timed out waiting for ring

i'm not getting CID yet.
By: Doug Bailey (dbailey) 2009-09-02 15:21:19

I found a problem in chan_dahdi.c in trunk where DTMF detection was placing the channel in 16 bit signed linear mode.  This corrupted any audio being transferred to/from the channel.

If you pull from the trunk after commit #215608, this issue should be resolved.
By: Doug Bailey (dbailey) 2009-09-02 15:31:54

maturs,
what dtmfcidlevel have you tried.  (This sets the threshold that triggers the channel processing)   You might try to adjust this value up or down to see if you can detect the start of the DTMF CID sequence cleanly.

You could use dahdi_monitor to capture the audio on the incoming channel to see what the state of the dtmf tones are and to get an idea as to their relationship to the initiation of the line ringing.
By: Luar Roji (cyberplant) 2009-09-02 18:51:43

I had the audio problem that sum reported but thought it was something wrong with my configuration.

Now with the last update it works fine, and it detects CID perfectly.

I'll keep an eye on it.

THANKS to all who helped to make this work! And specially to dbailey for making it work the "right way" (I didn't like the false polarity idea but it was hard for me to find another way).

BTW, I'm in Uruguay.
By: Sebastian Gutierrez (sum) 2009-09-02 19:21:04

I will test this tomorrow so we can close this issue.
By: Sebastian Gutierrez (sum) 2009-09-03 12:45:14

I can confirm is working fine now.
What else is necessary to move this issue forward?.

I think a patch for 1.6 branch would be necessary because if not, it will be difficult to have this patch in production environments for any time soon.
If someone point me in the right direction on how to manage the code at sig_analog  I could give it a try and also test it.
Then I could also upload the patch of the sample config file, adding the new parameters.
By: Doug Bailey (dbailey) 2009-09-03 14:26:19

1.6.2 is feature frozen, so this can't go into that branch or any earlier branch
officially.  If someone wants to make a patch for the latest releases on
those branches and attach them to this issue for other to hand apply, that would
be welcome.  

Otherwise, users will have to wait for the 1.6.3 release.
By: Digium Subversion (svnbot) 2009-09-03 14:41:23

Repository: asterisk
Revision: 216094

U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_analog.c
U   trunk/channels/sig_analog.h
U   trunk/include/asterisk/callerid.h

------------------------------------------------------------------------
r216094 | dbailey | 2009-09-03 14:41:23 -0500 (Thu, 03 Sep 2009) | 12 lines

Added detection DTMF CID without polarity change alert.

Added detection of DTMF tone energy levels on FXO channels in chan_dahdi
monitoring loop so DTMF CID can be detected without the need of a polarity
change precursor.  

(closes issue DAHLIN-4)
Reported by: fleed
Patches:
     9096-chan_dahdi-trunk.diff uploaded by dbailey (license 819)
Tested by: cyberplant, sum, maturs

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=216094
By: Sebastian Gutierrez (sum) 2009-09-03 15:12:01

ok, do you have any pointers on where should be the code of sig_analog? so I try to make a patch against 1.6.2 that is more likely to be in production in the near future.
By: Doug Bailey (dbailey) 2009-09-03 16:03:27

I've posted 9096-1.6.2-branch.diff which is the trunk patch but applied against the 1.6.2 branch and minimally tested.

As previously mentioned, 1.6.2 is feature frozen and this patch will not be committed to the 1.6.2 repository.  Please use accordingly.
By: R.deAndres (maturs) 2009-09-03 16:27:17

cyberplant, i'm in Uruguay too and i still can't detect CID.
Can you tell me if you are using sangoma or digium?
What /etc/asterisk/chan_dadhi.conf configuration have you tried??

Thanks
By: Luar Roji (cyberplant) 2009-09-04 00:01:32

I'm using an OpenVox card.

Maturs: Search for me in google and contact me in private so I can help you without making noise here, or contact me in IRC (irc.freenode.net), nickname "luar".

My name is Luar Roji.
By: Sebastian Gutierrez (sum) 2009-09-04 11:42:37

dbailey, the patch works ok on 1.6.2 branch. Thanks!
By: Sebastian Gutierrez (sum) 2009-09-04 14:55:48

attached the configuration for the sample config file.
By: R.deAndres (maturs) 2009-09-04 17:19:08

Cyberplant, I finally tried this patch with a Digium card y i was able to get CID.
Have you ever tried this patch with a Sangoma card?
By: Leif Madsen (lmadsen) 2009-09-08 13:19:56

It looks as if this issue is now closed due to it being merged into trunk. Please continue any discussions on the asterisk-users mailing list. Thanks!
By: Digium Subversion (svnbot) 2009-10-15 09:41:16

Repository: asterisk
Revision: 224144

U   trunk/configs/chan_dahdi.conf.sample

------------------------------------------------------------------------
r224144 | dbailey | 2009-10-15 09:41:15 -0500 (Thu, 15 Oct 2009) | 10 lines

chan_dahdi.conf.sample changes for DTMF CID detect

Explains new options for detecting DTMF CID on fxo lines

(issue DAHLIN-4)
Reported by: fleed
Patches:
     chan_dahid_sample_config.patch uploaded by sum (license 766)


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=224144