Reoccurring Issues: Multiple Problems with DAHDI Line

General Help
,
22

After re-reading your post, I see you have a hardware echo canceller. I remembered a similar issue, where if the echo canceller was set to detect DTMF instead of Asterisk, audio issues would arise. I know this is not supposed to happen, but after re-configuring the card to not detect DTMF through the echo canceller, the issue went away. Again, this is not supposed to happen, but worth giving it a try.

23

Hello arielgrin, I changed the setting in /etc/wanpipe/global.conf from WANPIPE_GLOBAL_HW_DTMF=YES to WANPIPE_GLOBAL_HW_DTMF=NO but I still experienced issues. Is there somewhere else I should be changing so that Asterisk detects the DTMF and not the echo canceller? Thanks!

24

I never did it manually, I used the configuration script. But that script might modify other files, so take that into consideration.

25

Which script are you referring to?

26

If I recall correctly, the script is called wancfg_dahdi

27

Oh alright, the manual install doesn’t have that script included. But I ran the commands found on digium’s website here: (http://kb.digium.com/articles/FAQ/How-do-I-disable-echo-cancellation-module-without-removing-the-hardware) and disabled the echo cancellation. I’ll see how this goes, but the phones went down twice today, the first time I could call in but didn’t hear anything, including the IVR, running fwconsole restart fixed it, and then just a little bit ago, I called in and could hear the IVR, but it wouldn’t accept the extensions or any options and again, fwconsole restart fixed it.

28

Caught this symptom today. After seeing the Unable to disable sw companding on echo cancellation channel 0 (reason 4) in the dmesg output, I used dahdi_monitor to look at the channels. The output seems to show that each channels Rx is pegged at the maximum.

# dahdi_monitor 1 -vv -m

Visual Audio Levels.
--------------------
 Use chan_dahdi.conf file to adjust the gains if needed.

( # = Audio Level  * = Max Audio Hit )
<----------------(RX)----------------> <----------------(TX)---------------->
 ###################################*                           
Rx: 30076 (30076) Tx:     0 (    0)

All 4 ports reported the same. Now inbound call gets nothing but silence, despite the IVR messages playing. All inbound calls also cause the companding errors to occur as listed below.

[Mon Apr 30 17:00:18 2018] wctdm24xxp 0000:05:08.0: RING on WCTDM/0/0!
[Mon Apr 30 17:00:20 2018] wctdm24xxp 0000:05:08.0: NO RING on WCTDM/0/0!
[Mon Apr 30 17:00:24 2018] wctdm24xxp 0000:05:08.0: RING on WCTDM/0/0!
[Mon Apr 30 17:00:26 2018] wctdm24xxp 0000:05:08.0: NO RING on WCTDM/0/0!
[Mon Apr 30 17:00:30 2018] wctdm24xxp 0000:05:08.0: RING on WCTDM/0/0!
[Mon Apr 30 17:00:34 2018] wctdm24xxp 0000:05:08.0: Unable to set SW Companding on channel 0 (reason 4)
[Mon Apr 30 17:01:17 2018] wctdm24xxp 0000:05:08.0: NO BATTERY on 1/1!
[Mon Apr 30 17:01:18 2018] wctdm24xxp 0000:05:08.0: BATTERY on 1/1 (-)!
[Mon Apr 30 17:01:18 2018] wctdm24xxp 0000:05:08.0: WCTDM/0/0: Polarity POSITIVE -> NEGATIVE
[Mon Apr 30 17:01:18 2018] wctdm24xxp 0000:05:08.0: NO RING on WCTDM/0/0!
[Mon Apr 30 17:01:18 2018] wctdm24xxp 0000:05:08.0: WCTDM/0/0: Polarity NEGATIVE -> POSITIVE
[Mon Apr 30 17:01:21 2018] wctdm24xxp 0000:05:08.0: Unable to disable sw companding on echo cancellation channel 0 (reason 4)

fwconsole restart resets the system back to normal operation.

Any ideas what to look at next to figure out what is going on?

1 Like
29

You will probably need the help of digium with that companding error.

30

I suspect that you need a different version of DAHDI, what do you have right now?

31

Dahdi 2.11.1
From: http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/dahdi-linux-complete-current.tar.gz

32

I would try regressing to an earlier version 2.9 is what works for me

33

I think your original mistake is not using FreePBX Distro. It’s already configured and tested for all this stuff. Can I suggest deploying a new machine, and not messing around recompiling everything?

Oh, and almost everything on voip-info is almost certainly wrong. It’s pretty much read-only and unmaintained these days.

34

Still getting issues with 2.10.2. Going to downgrade to dahdi 2.9 next.

35 
# dahdi_monitor 1 -vv -m

Visual Audio Levels.
--------------------
Use chan_dahdi.conf file to adjust the gains if needed.

( # = Audio Level  * = Max Audio Hit )

<----------------(RX)----------------> <----------------(TX)---------------->
###################################*
Rx: 30076 (30076) Tx: 0 ( 0)

Getting the same issue again, this time using dadhi 2.9.1. The IVR answers, but does not respond to input.

36

System stable for the last 6 days after putting dahdi 2.11.1 back.

37

Today the IVR audio was not making it to the caller, but the DTMF was working when tested.

38

One-way audio is almost always a NAT configuration problem.

Of course, that’s for most VOIP systems - your system (being DAHDI) may not be that issue. A review of the logs in this case might help us see what’s happening. If you can provide the log info for that call, it could be an issue on the front end (language selection, for example). You’ve also tuned your receive and transmit levels quite a bit - perhaps your output is running “too hot” and getting clipped out of the call by the upstream switch?

39

perhaps your output is running “too hot” and getting clipped out of the call by the upstream switch?

Thought about that, but I am not sure why it would start to work immediately after restarting. I would think that if the problem was upstream, it would happen consistently.

1 Like
40

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.