[Asterisk-Users] Help! Zap echo on bridged calls

[Kris Boutilier]

-----Original Message-----
From: JD Austin [mailto:jd at twingeckos.com]
Sent: Tuesday, June 07, 2005 1:57 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Help! Zap echo on bridged calls


> I've been going nuts lately trying to get rid of an annoying echo problem that makes my asterisk server unusable when clients try to call me.
> Here's the breakdown of the issue  - Hoping that someone can throw me a clue: 
> My setup is as such:
> Single AMD Athon machine with X100P clone card and voip through multiple providers .
> 
> Inbound calls through the X100P that do not bridge to voip are fine. 

This is probably because there is no substantial time delay being introduced, hence the reflected signal is not perceived as echo but rather as 'sidetone'.

>Outbound calls that do not bridge with the X100P are fine. 

If you mean iax-sip or sip-sip etc., then that makes sense as the only possible place a signal could be reflected would be through acoustic coupling inside the remote parties handset, assuming the path were entirely digital from end to end.

>PSTN ->*->VOIP calls have so much echo on the called party side (sidetone) that it is almost impossible to have a conversation. 

I'm not entirely clear on this, however I think you're saying that on _any_ calls to PSTN destinations, regardless if they originate on the PSTN (dialed inwards) or on the VOIP side (dialed outwards) the VOIP user is experiencing talker echo. That would be the expected behaviour.

If the PSTN user is hearing an echo, then it's probably acoustic coupling in the VOIP device - try a different headset and/or device.

I have not worked with the X100P card, only with T100P T1s. I have studied the mec2 echo canceller (the default for zaptel) in some detail. If you are confident that separate interrupts and so on are all properly assigned (lspci -vv) and there is nothing else weird going on (you've tried going all the way back to a ulaw codec, right?) then I would suggest you try to determine if mec2 is even bothering to try and cancel the echo. For that you'll need to explore the patch at http://bugs.digium.com/view.php?id=2820

Try applying it, recompiling and seeing what happens. It should apply against either cvs-head or stable as mec2 hasn't changed in a very long time. Once you've got it going you could try twiddling some knobs in mec2_const.h (pay particular attention to MIN_UPDATE_THRESH_I) or get busy studying the refered to Texas Instruments whitepaper and then uncommenting MEC2_STATS and/or MEC2_STATS_DETAILED.

Good luck, you have an unenviable problem.
:-)

Kris Boutilier
Information Services Coordinator
Sunshine Coast Regional District