[Asterisk-Users] Will Echo problems EVER be solved, I'm scared

[Rich Adamson]

> I'm not the OP, but I had a similar problem, in my case fxotune ran 
> successfully for just one out of 3x FXO modules, but the coefficients were 
> all 0's. My kernel is  2.6.11 on CentOS 4.1.
> 
> So I'm curious if 2.6 kernel (instead of 2.4) has any input in this whole 
> echo issue, not just fxotune.
> 
> Yesterday I switched to KB1 echo canceller, it is by far the best. But today 
> I had a similar experience to Eric Rees's Strange Echo post. After 
> transfering to another internal line, echo starts. My theory is that after 
> transfer some characteristics of the internal connection change, especially 
> the Tx voice (the person talking on our side changes). So if the echo 
> canceller is too committed to the voice of the first person answering the 
> line (the operator), that would be quite expected. I don't know how KB1 or 
> other echo cancellers work, but if I'm right, it would be better if echo 
> canceller readjusted itself after transfer. Sorry if that's plain wrong. Can 
> somebody comment please?
> 
> I'm really interested in all posts in this thread and others or documents on 
> echo.
> 
> Btw, thanks Eric Wieling for the Cisco link.

That article is an excellent read. Readers should be a little carefull
with it however as there can be additional sources not mentioned in
the article.

Others that have more capability to read code then I might want to
comment on the following to help ensure we're all running with the
same reasonable understanding.

Relative to asterisk's canceler and based on two years of rather heavy
experience with asterisk, one can characterize the existing canceler(s)
by saying there are two distinct functional pieces:
 1. the pstn line pulsing used to preload the canceler, and,
 2. the ongoing real-time training.

The first function is controlled by 'echotraining=800' (or whatever
value including 'yes' might be provided) in zapatal.conf.

The second part can actually be heard in most implementations by
changing echotraining=no and listen to an actual call. Typically,
it takes about ten seconds or so for the training to occur. (The
actual time varies depending upon how good/bad the end-to-end
circuit happens to be.

Is it practical to 'assume' that in your case mentioned above that
#1 is not going to occur again (since I assume when you say 'line'
you are referring to an outside pstn line), and, #2 is in a mode
of fine-tuning the training when in fact you'd really like it to
start the coarse-training from scratch?

Relative to the fxotune app, it would appear the app is specific
to the v2.4 kernels (/dev/zap*), which the v2.6 kernels don't use
(but rather the udev equivalent). (When I had * running on a v2.4
kernel, the output from fxotune never deviated from all zero's. So
I'm assuming the default chipset values were already tweaked by the
chipset manufacturer to US telco lines. If that is true, then 
running fxotune in the US has very little value.)

The KB1 canceler _does_ work just fine in the v2.6 kernels and I'm
in favor of moving it to the default for future Head and Stable
releases as soon as practical.