[Asterisk-Users] Help with strategy for echo cancellation.

[Steve Edwards]

Not letting my ignorance of the issues get in the way, I humbly offer the 
following in the interest of starting a discussion on developing a 
strategy.

So the approach appears to need to be broken down into 2 categories: 
issues with the analog cable plant and issues within the Asterisk box

Debugging the analog cable plant probably should be done first, but 
probably also involves areas that we may not be in control of -- telco 
closets, inside wall wiring, etc.

Within the Asterisk box, you have motherboard issues you probably can't 
control and Rx and Tx gain you can tweak to mask the problem.

For mobo issues, is there a utility that can measure PCI latencies? Maybe 
an application that could measure the delay between sending and receiving 
a tone between 2 analog ports tied together with a stub of cable and a 
couple of rj11's?

For a "[rx|tx]gain tweaking strategy," can somebody reply with a step by 
step approach? Something like:

1) Dial an extension that invokes the milliwatt application. Adjust 
[rx|tx]gain so that ztmonitor displays x octothorpes (a patch to display a 
"hard number" would be easier than counting "#'s")

2) Dial out in a IAX circuit to your FXO port, invoking the milliwatt 
application. Blah, blah, blah.

3) Dial out an FXO port to another FXO port, blah, blah, blah.

4) Dial out an FXO port to your buddy's FXO port on the opposite coast, 
blah, blah, blah.

Any comments? Is this barking up the wrong tree?

On Thu, 23 Sep 2004, Rich Adamson wrote:

>
>> I have just installed * (RH9, P4 3.0GHZ, 1G RAM) in a small office,
>> using three TDM400's with 4 FXO's each for incoming calls.  Outgoing
>> calls are (for the moment) routed via VoicePulse.  Phone sets are Cisco
>> 7940G's using SIP.  I'm getting intermittent echo on outgoing calls, and
>> my understanding, based on reviewing the wiki and several posts here, is
>> this:
>>
>> >>>>  The source of the echo is the analog tail circuit at the
>> far end of the call.  This is consistent with the facts -- I don't have
>> echo on internal calls or on IAX2 calls to another Cisco 7940 on another
>> * box.
>
> That's because those paths are basically equivalent to 4-wire full-duplex
> links. The only place where echo 'could' be generated is from within the
> sip devices themselves, or from the handset (eg, echo tunneled through the
> handle). Handset echo 'has been' an issue with some cheap sip phones, and
> usually stuffing foam rubber into the handle takes care of it.
>
>> >>>>	 There's nothing that I can do about the echo using *
>> echo cancellation because (according to Cisco's Echo Analysis paper) my
>> echo cancellation only deals with echo originating at my end.  (Am I
>> wrong?  Hope so).
>
> Not necessarily true, but could be. If you're hearing your own voice
> when talking, you're getting feedback from "something" along the path.
> In very general terms, the delay between a spoken word and when the
> feedback (echo) occurs should help determine the source location, but
> you have to listen very closely. The greater the time between a word
> and the returning echo, the further the source of echo is from you.
>
> The Cisco paper assumes a near-perfect world; be careful with assumptions.
> Example: it assumes that if you have an echo canceller running on
> your end that its doing what it is supposed to be doing (eg, a quality
> echo canceller). As you've seen in many many earlier posts, the * echo
> canceller is not a high quality piece of software and has a rather
> narrow range of operation. When echo occurs outside that range, the
> canceller is not handling it at all. Also, you've probably read some
> of the posts relative to differences that motherboards have on the *
> echo canceller; if the delay in moving packets from * to the TDM cards
> and asterisk reading packets back from the TDM card is lengthy, then
> you will hear echo. Depending on how long that delay actually is, you
> can easily jump to an incorrect conclusion that its caused by far-end
> problems (per the Cisco document), when in fact its not. The motherboard
> issue has something to do with interrupt latency and/or pci bus
> characteristics, and has absolutely nothing to do with the speed of
> the processor, brand name on the front of the box, or far-end echo.
> (I've not heard anyone in six months actually offer up a way to figure
> out what the issue truly is, just lots of opinions thus far.)
>
>> >>>>	 I may be able to minimize the problem by tweaking the
>> Rx/Tx gain in zapata.conf.
>>
>> So, if my understanding is right, can someone please suggest a strategy
>> for adjusting the gain controls?  There are two controls, and each can
>> be adjusted up or down.  I'd like to adopt a method other than random
>> fiddling.  Where's a good place to start?
>
> Each site seems to be a little different, so there's no such thing as
> a good value to start at. Some machines are very close to Central Offices
> (where cable loss is insignificant) while others are some distance from
> the Office (where the loss might be 10 db or so). In very general terms
> start with 0,0 (rxgain, txgain) and adjust in maybe 2.0 db increments.
> In most cases you need to stop/start asterisk (not just a reload). The
> smaller the gain settings, the less echo, but will also become difficult
> to hear as well. Going to low will also kill DTMF and/or CallerID functions.
>
> Rich
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

Thanks in advance,
------------------------------------------------------------------------
Steve Edwards      sedwards at sedwards.com      Voice: +1-760-468-3867 PST
Newline           pagesteve at sedwards.com            Fax: +1-760-731-3000