[asterisk-dev] bug in echo cancel at 256 taps

[Matthew Fredrickson]

On Aug 2, 2006, at 11:14 AM, Roy Sigurd Karlsbakk wrote:

>>> Yesterday and this morning we experienced a serious bug in the echo
>>> cancellation.
>>>
>>> While trying to tweak out some echo on a new asterisk install we set
>>> echocancel=256. From then on, calls would usually start out ok (but
>>> still with some echo) then there would be what users describe as a
>>> 'click' followed by a huge blast of echo making the call impossible 
>>> to
>>> continue.
>>>
>>> At that point it seems as though the echo is actually being inserted
>>> into the call rather than removed.
>>>
>>> asterisk-1.2.10
>>> libpri-1.2.3
>>> zaptel-1.2.7 with default ECHO_CAN_KB1
>>>
>>> Card is a Sangoma A101 using wanpipe-beta7-2.3.4.tgz .
>>>
>>> Just wanted to run it by the list before entering a bug report to 
>>> make
>>> sure its appropriate and that this isn't actually a wanpipe bug.
>>>
>>> Is there any other sort of other debugging or analysis that would be
>>> helpful?
>>
>> As previously suggested, make sure you are running the most current 
>> version of the echo canceler (MG2 in trunk right now) before you file 
>> any sort of bug report.  It is unlikely that you will find anybody 
>> that wants to fix bugs in old code.
>
> 1.2.10 is less than three weeks old, trunk is not ready for 
> production, and 1.4 probably won't be out before next year, so perhaps 
> 'old' bugs should be fixed anyway?
>

It's more like this:  there are only a handful (if that) of people that 
actually have the technical know-how to even work on this type of code, 
and most of them are not working consistently on it.  They only work on 
it when they have a need to.  So even though you submit a bug on mantis 
about it, the person that actually might be able to fix it is very 
unlikely to actually see it.  And like I said, nobody likes to fix bugs 
that potentially already have been fixed in a current version.  We 
don't usually like to change something as major as the default echo 
canceler in a release branch anyways, there are too many people that 
depend on the existing performance nuances of the code that is there.

Matthew Fredrickson