Hi,
There is a huge echo on outgoing calls, and I’m unsure how to resolve it. I’m using asterisk-v1.8.5.0 on fedora15 with a Tiger3XX FXO card over business-class cable voice (optimum online). I’m seeing the following in the logs:
[Sep 21 16:00:32] WARNING[22225] chan_dahdi.c: Unable to request echo training on channel 1: Invalid argument
I have the following in chan_dahdi.conf:
[channels]
language = en
context = incoming
accountcode = pstn-incoming
signalling = fxs_ks
callwaiting = no
immediate = no
amaflags = default
cancallforward = no
busydetect = yes
callprogress = no
musiconhold = default
threewaycalling = no
callreturn = no
transfer = no
usedistinctiveringdetection = no
usecallerid = yes
hidecallerid = no
callwaitingcallerid = no
usydetect = yes
busycount = 3
hanguponpolarityswitch = yes
echocancel = yes
echotraining = 800
group = 1
pickupgroup = 1
channel => 1
channel => 2
group = 2
context = incoming
channel => 3
group = 3
context = incoming
channel => 4
I posted the message below a few days ago and haven’t received any replies. Is there someone who can help?
If there is a more appropriate forum to post this question, please advise.
Thanks,
Alex
[quote=“gossamer”]Hi,
There is a huge echo on outgoing calls, and I’m unsure how to resolve it. I’m using asterisk-v1.8.5.0 on fedora15 with a Tiger3XX FXO card over business-class cable voice (optimum online). I’m seeing the following in the logs:
[Sep 21 16:00:32] WARNING[22225] chan_dahdi.c: Unable to request echo training on channel 1: Invalid argument
I have the following in chan_dahdi.conf:
[channels]
language = en
context = incoming
accountcode = pstn-incoming
signalling = fxs_ks
callwaiting = no
immediate = no
amaflags = default
cancallforward = no
busydetect = yes
callprogress = no
musiconhold = default
threewaycalling = no
callreturn = no
transfer = no
usedistinctiveringdetection = no
usecallerid = yes
hidecallerid = no
callwaitingcallerid = no
usydetect = yes
busycount = 3
hanguponpolarityswitch = yes
echocancel = yes
echotraining = 800
group = 1
pickupgroup = 1
channel => 1
channel => 2
group = 2
context = incoming
channel => 3
group = 3
context = incoming
channel => 4
Any ideas greatly appreciated.
Thanks,
Alex[/quote]
The rejection was by dahdi, so the dahdi version and the specific low level driver in use are more important than the Asterisk version.
However, the likely cause is trying to pass parameters to a low level driver that supports echo cancellation but doesn’t accept parameters. It might also be an invalid parameter value for the low level driver.
I note that the fallback code only accepts powers of two for the number of taps, although it uses a default, rather than rejecting, for other values.
[quote=“david55”]The rejection was by dahdi, so the dahdi version and the specific low level driver in use are more important than the Asterisk version.
However, the likely cause is trying to pass parameters to a low level driver that supports echo cancellation but doesn’t accept parameters. It might also be an invalid parameter value for the low level driver.
I note that the fallback code only accepts powers of two for the number of taps, although it uses a default, rather than rejecting, for other values.[/quote]
Hi, thanks very much for the note.
dahdi show version
DAHDI Version: SVN-trunk-r10179 Echo Canceller: HWEC
I don’t see any references to “fallback” or where the echo canceller would be accepting arguments.
Do you have any suggestions on how to fix the echo problem?
You are using a development version of DAHDI. Why?
HWEC presumably stands for hardware echo cancellation.
You haven’t identified the low level driver.
There seems to have been a major rework of the echo cancellation API between the DAHDI version that I checked and the current development version. I don’t know if your version is closer to the current development or the Asterisk 1.6 compatible release versions, so I don’t know if showing the relevant code from the latter will help explain.
If the low level driver came with the card, you need to contact the card’s support organisation. If the card is providing the echo-cancellation function, you need to do the same.
For some errors, you will find kernel log messages from the dahdi driver.
The most likely culprit here is that you are attempting to enable echotraining on the channel but you have not attached a software echocanceler to the channel.
What are the contents of /etc/dahdi/system.conf? You will want to make sure you have an echocanceler configured as described at the end of svnview.digium.com/svn/dahdi/too … onf.sample.
You can also see what the current echocanceler attached to a channel is in the proc file system. For example:
The most likely culprit here is that you are attempting to enable echotraining on the channel but you have not attached a software echocanceler to the channel.
What are the contents of /etc/dahdi/system.conf? You will want to make sure you have an echocanceler configured as described at the end of svnview.digium.com/svn/dahdi/too … onf.sample.
You can also see what the current echocanceler attached to a channel is in the proc file system. For example: