[Asterisk-Users] Echo on my TDM fxo

[Rich Adamson]

> > Then try the following in zapata.conf:
> >  echotraining=800
> >  echocancel=yes
> >  echocancelwhenbridged=yes
> > as a starting point for each fxo channel.
> 
> Does echotraining *improve* echo cancellation at all?  All I've ever found it 
> to do is help the canceller converge faster.  i.e. if the echo does 
> eventually go away, echotraining helps it go away faster.  If the echo never 
> goes away I have never seen echotraining do anything to help that.

Having worked with a large number of * implementors (and Mark) on
this issue, yes echotraining will oftentimes make a hugh difference.
The issue has been (and continues to be) "when" does the pulsing of
the pstn line occur that is used to preload the echo canceller?

If that occurs to quickly, the preloaded values are totally incorrect,
and since the echo canceller has relatively narrow operating margins,
there have been several cases where the canceller does not converge in
any timeframe that is considered reasonable. (Mark and I worked together
to come up with the echotraining=800 approach.)

So, for those first-time x100p/tdm-fxo implementors with echo problems,
trail & error has found that the starting point noted above works in 
many many cases (but obviously not all). That does not suggest that =800 
is something that should remain in a config forever, but rather just 
a starting point that is known to have good results in a large number 
of cases.

Since the timing of the pulse on the pstn line is not recognizable
by the average human being, leaving the value =800 has not caused any
noticeable side effects other then frequently correcting the echo issue
(by preloading the echo canceller with something that is realistic
which therefore allows convergence much quicker). (As a 20 year
veteran of detailed telephony engineering, I can't even detect when
that pulse occurs by simply listening on a 7960.)

If one takes a working * system with minimal or no echo, and moved
that system to another location that is served by a different pstn
provider, those same values may or may not actually be acceptable.
In other words, the exact timing appears to be _dependent_ on the
type of central office and/or pstn plant involved.

Using the above approach followed by mucking with rxgain/txgain and
number of taps, will frequently result in a very acceptable config.

In my specific case, all four pstn lines are Alltel (unknown CO 
manufacturer), ~15,000 feet of real copper to the CO, and any 
smaller value then =800 is not usable at all. Go figure.

Rich