The style of echo canceller in use in MEC2 cannot cope with both echoed sound 
and 'new' sounds coming down the pipe at the same time (double talk). 
Accordingly it has to stop certain parts of the processing during the so called 
event. Once double talk has been 'detected' the echo can is frozen for at least 
DEFAULT_HANGT samples (the default is 600 samples = 75ms). Put another way, the 
echo can stays frozen at least 75ms _after_ the end of detectable double talk - 
known variously as the 'holdover' or 'hangover' timer. The AGGRESSIVE_HCNTR on 
the other hand causes the echo can tracking to kick back in _before_ the 
holdover timer has expired (default 160 samples = 20ms). In addition, enabling 
the 'aggressive suppression' option also changes the math around subtraction of 
the echo model from the signal resulting in stronger suppression at the cost of 
more noticable distortion on low-echo calls.
 
You can find a fairly detailed reference implementation of the same algorithm 
in:
 
 Messerschmitt, David; Hedberg, David; Cole, Christopher; Haoui, Amine; 
Winship, Peter; "Digital Voice Echo Canceller with a TMS32020", in Digital 
Signal Processing Applications with the TMS320 Family, pp. 415-437, Texas 
Instruments, Inc., 1986.

A pdf of which is available by searching on the quoted document title at 
http://www.ti.com/

I would suggest experimenting with (raising) the value of MIN_UPDATE_THRESH_I 
if you're getting unsupressed echo. My understanding is that this represents 
the minimum reference signal power estimate level that will cause filter 
adaptation. If this is too low relative to the signals coming off the T1 then 
background noise can cause the filter coefficients to constantly be updated and 
the echo can to 'diverge'. 
 
I suspect the problems people have are to do with digital pad being added to 
the signal somewhere that pushes the signal floor out of range of the fixed 
constants that this implementation uses - hence people who have success from 
fiddling with the channel gain parameters. I've got a sneaking suspicion its 
Central Office related - perhaps some vendors switches correct for pad before 
putting digital signals out to the customer? We're hooked to a Lucent GTD5 
remote office and I've had bad, but extremely inconsistent echo problems with 
both analog and digital 1B channels regardless of where the far end is - down 
the road or across the country. I've heard of others doing VoIP on the same 
model switch with similar problems. 
 
I've put quite a few tens of hours into understanding MEC2 and I'm still 
nowhere near all the way there. Getting input on this kind of thing from people 
with the CO engineering experience gets difficult... I'll be honest here - we 
coughed up for some an old mid 1980s Tellabs 2531 hardware echo cans off of 
eBay and they did a 100% better job than any of the software cans provided with 
Asterisk. Wierdly that Tellabs still has issues with some calls (particularly 
with loud background noise) but upgrading to a newer 2572 64ms unit pretty much 
took care of that too. Regardless, do not underestimate the damage unresolved 
echo can do to the viability of a VoIP project.

Hope that helps.
Kris Boutilier
 

-----Original Message-----
From: Dennis Webb [mailto:[EMAIL PROTECTED]
Sent: Monday, March 07, 2005 10:51 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Tweaking AGGRESSIVE_SUPPRESSOR


This seems to be how AGGRESSIVE_SUPPRESSOR works.  To make sure you don't get 
echo, it does what a speakerphone does, mute the other party if it hears audio 
from your end.  There is a setting in mec2_const.h for AGGRESSIVE_HCNTR=160 
that says in the comments 20ms, I'm assuming this is to tell how long to 
suppress the other party.  There is nothing on this that I have found anywhere 
and since we are live, I can't change until later to see how it works. 
 {clip} 

_______________________________________________
Asterisk-Users mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to