Summary:ASTERISK-16265: [patch] Severe clicking, popping and talkoff when inbound call from SIP
Reporter:basildane (basildane)Labels:
Date Opened:2010-06-18 07:52:06Date Closed:2010-06-22 20:38:43
Versions:Frequency of
Environment:Attachments:( 0) bug17529.diff.txt
Description:Under certain conditions, calls to Dahdi channels are full of clicks, pops, and spurious DTMF digits.  (Usually DTMF-1 for me).

The conditions to reproduce are:
Answer and incoming call from a SIP provider on an analog extension.

Other types of calls are clean and have no problems.  For example:
SIP calls answered on SIP extensions.
SIP extension answering call from analog extension.
SIP extension answering call from SIP, transferred to analog.


Tested on multiple installations.

Asterisk 1.4.32, 1.4.33rc1, 1.4.33rc2
OS: Centos, Ubuntu
Digium TDM400
Comments:By: Shamus Rask (juggler00) 2010-06-18 09:20:10

I second this issue. Please see full description in forums: http://forums.digium.com/viewtopic.php?f=1&t=74356&start=0&sid=bb50cd47a1fd70ec1a324e9b800f5399

By: Russell Bryant (russell) 2010-06-18 10:15:33

This is an issue that normally needs to be handled through tech support of your hardware vendor.  However, this particular card has already reached end of life.  I would suggest taking a recording of the audio coming from your SIP provider, to make sure that what you hear isn't coming from upstream.  Beyond that, there is nothing we can do here.

By: basildane (basildane) 2010-06-18 10:17:26


This has nothing to do with hardware or a card.
My card has been running perfectly for years.  And there are others who suddenly have the same problem after updating their DAHDI drivers.

We didn't all suddenly experience a hardware failure at the same time.

By: Shaun Ruffell (sruffell) 2010-06-18 10:20:09

basildane:  In your setup, what is the last version of DAHDI that worked for you?  Also, are IRQ misses increasing in /proc/dahdi/1?

Based on your description, it sounds like problems servicing the interrupt in time, but if you could tell me a version that worked for you, then I could look at the differences between the version.  

And please, keep *everything* else the same.  Platform, asterisk version (you may have to recompile asterisk to move back a dahdi version, kernel version, etc..

By: basildane (basildane) 2010-06-18 10:26:59

About 2 weeks ago, I updated Freepbx from 2.5 up to 2.8.
At the same time, I recompiled Asterisk to 1.4.33rc2.
I updated DAHDI to
I brought everything up to date.

At that time I made test calls, they worked. (going out). So I assumed everything was good.  My phone is SIP, so I didn't realize there was a problem for over a week until I happened to answer a call on a DAHDI extension.

I think I still have a full Mondo backup from back then, it will take me some time to locate it and mount it somewhere.

I need to add; this is not me.  Others installations are experiencing the same thing.  I.E. Juggler00.  He/she may be able to answer your version question more quickly.  If not, I will restore my backups and get you a version.  I think it was Zaptel however.

By: Shaun Ruffell (sruffell) 2010-06-18 10:33:45

Ok.  What I would need to be able to help is someone to triage this to a point where you can say given x,y,z  if I change only the drivers from a -> b.  With that information I could form a hypothesis about what the problem may be.

By: basildane (basildane) 2010-06-18 10:52:05

Can you tell me how to get the missing interrupt info for dahdi/1?
Linux is not my first language.  :)

By: Shaun Ruffell (sruffell) 2010-06-18 11:00:25

Ughh..my mistake.  The TDM400 doesn't provide that information (TDM410/TDM800/TDM2400 do...).  So, I would continue with trying to isolate the driver version where the behaviour changed for you.  Sorry about that.

By: basildane (basildane) 2010-06-18 12:31:46

CORRECTION: Internal calls from SIP to an analog extension DO have the problem.

By: Shamus Rask (juggler00) 2010-06-18 20:11:24

WRT the interrupt question. I originally thought my problem might be due to this. I moved the WCTDM card to a different PCI slot and verified (lspci -v) that it had a unique interrupt. The problem persisted.

Note that the sounds are only present on a SIP-initiated (either external or internal) to DAHDI call, not the reverse!

By: basildane (basildane) 2010-06-19 12:34:08

After 5 hours of trying, I am not able to restore the backup to get you the version number.  I tried, but it corrupted too far.  Sorry.

Anyway, the problem is trivial to reproduce.

By: basildane (basildane) 2010-06-20 11:12:24

I recompiled with DAHDI all the back to versions 2.0.0.
Continued to have the problem each time.

Leads me to think something became misconfigured in the card.
I compiled back to  Ran fxotune.
Foxtune returns "/dev/zap/1 absent: No such file or directory" for 252 iterations.

Shouldn't it be checking /dev/dahdi/*?

By: Shaun Ruffell (sruffell) 2010-06-20 11:39:28

Yes.  Perhaps dahdi-tools was not installed?

By: Shamus Rask (juggler00) 2010-06-20 11:51:16

I compiled & installed the complete package: DAHDI-linux complete. The version I grabbed was the latest: The problems still persist even with this.

By: Shaun Ruffell (sruffell) 2010-06-20 13:02:45

Juggler00:   Did you have the same error running fxotune that basildane reported?  What is the output from 'dahdi_cfg -vvf'

By: basildane (basildane) 2010-06-20 15:31:37

I recompiled and confirmed installation of dahdi tools.
I also ran fxotune right from the source folder.

This is my output from dahdi_cfg:
DAHDI Tools Version - 2.3.0

DAHDI Version:
Echo Canceller(s): MG2

Channel map:

Channel 01: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 02)
Channel 03: FXS Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 03)
Channel 04: FXS Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 04)

4 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2
Setting echocan for channel 3 to mg2
Setting echocan for channel 4 to mg2

By: Shamus Rask (juggler00) 2010-06-20 21:13:02

sruffell: Here is my output... I have 2 FXS modules and 1 FXO module installed. This looks correct to me?
?DAHDI Tools Version - 2.3.0

DAHDI Version:
Echo Canceller(s): MG2

Channel map:

Channel 01: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 02)
Channel 03: FXS Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 03)

3 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2
Setting echocan for channel 3 to mg2

By: basildane (basildane) 2010-06-21 09:06:06

I found an old fxotune in the /sbin folder and deleted it.
fxotune now correctly scans the /dev/dahdi devices.

Here is the fxotune.conf file it wrote.  All zeros! :

Ran fxotune -s, restarted asterisk.
Clicking problem remains.

By: Shaun Ruffell (sruffell) 2010-06-21 14:42:26

Ok...then at least it's not an installation issue.  So, in order to be any help, I would still need someone with a system experiencing this issue to triage it down to the breakage with just a change between DAHDI version.  Since I cannot reproduce it here and there are so many system level things that could result in clicking, etc..

What does dahdi_test report?

By: basildane (basildane) 2010-06-21 16:10:44

You don't think the problem is related to my fxotune.conf file being empty / full of zeros?

Here is the dahdi_test:

Opened pseudo dahdi interface, measuring accuracy...
99.996% 99.986% 99.994% 99.993% 99.994% 99.994% 99.993% 99.994%
99.993% 99.990% 99.994% 99.994% 99.993% 99.994% 99.994% 99.992%
--- Results after 17 passes ---
Best: 99.996 -- Worst: 99.986 -- Average: 99.993201, Difference: 99.993202

By: Shaun Ruffell (sruffell) 2010-06-21 16:23:14

The dahdi_test output looks good.  The fxotune output of all 0's can be ok depending on your line conditions.

If you use dahdi_monitor to record the call on the DAHDI interface, do you hear the clicking and popping in the dahdi_monitor recording?

By: sasquatch (sasquatch) 2010-06-21 21:47:43

Hi Everybody,

I have the same issue as described here.  I made tests and I found the following things:  The issue is only there when asterisk v1.4.32 or v1.4.33 is applied on my server.  It works fine with asterisk v1.4.31 and earlier versions.

Also, it only happens when the analog extensions are being called (dahdi-inbound).  All my 3 FXS are acting the same.  The problem IS NOT there when I am calling from them (dahdi-outbound).  Whatever where the call is coming (external IAX2, SIP device, analog FXO) you can always reproduce it.  The problem is periodic, ie it happen at about every 6-7 seconds, no error messages on the console.  It act like a FLASH being sent on the line.  I tested it on 2 servers with the same results (with same TDM410 config).

I have the following config:

Ubuntu Linux v8.04 LTS server
TDM410 3FXS / 1FXO

I am using the HPEC echo canceller.  Using the latest config from ASTERISK site, I can reproduce the problem from version 1.4.32 and 1.4.33.  It works fine with asterisk 1.4.31 and earlier.  So this is not related to the hardware or Dahdi driver.  It`s related to something in Asterisk since the same config with different version of Asterisk works..  

Hope this can help.

Thanks in advance.


By: Alec Davis (alecdavis) 2010-06-22 02:47:11

Going by the description in ~123690 , if I read it right, this is fixed in the asterisk-1.4-branch see:

regression for 1.4 happened at:

By: Alec Davis (alecdavis) 2010-06-22 06:46:52

uploaded patch 'bug17529.diff.txt' for asterisk 1.4.32 and 1.4.33

By: basildane (basildane) 2010-06-22 07:56:32

Applied patch and tested.  WORKS!

Did a quick 30 second call and it was perfectly clean.
Thanks everyone.

By: Shamus Rask (juggler00) 2010-06-22 10:12:24

Also applied patch... also works!

Many thanks!

By: basildane (basildane) 2010-06-22 13:04:03

I'm trying to make sense of SVN...

Is this patch going to make it into the 1.4 trunk?  It seems to be in the 1.6 trunk only.

According to the notes it says "target 1.4.32".  But it wasn't in 1.4.33?

By: Alec Davis (alecdavis) 2010-06-22 14:43:13

basildane: Already applied to 1.4 trunk, before the 1.4.33 final release.

By: Alec Davis (alecdavis) 2010-06-22 20:38:42

Actually fixed in