I am having echo problems as well. One thing a Cisco guy recommended to
me was adjust the txgain down, and see if the echo gets better. I
changed mine to -10, and that drastically improved the echo. What the
guy was explaining to me was that there could be a device on the line
someplace that is increasing gain by 10-15db, and perhaps its also
adding some delay. With that combination, asterisk's echo cancelation
cant handle that, and thus we hear echo. Tomorrow I am going to call
bellsouth and see if they can check to see if there is anything on the
lines that might be causing that.<br><br><div><span class="gmail_quote">On 10/11/05, <b class="gmail_sendername">Kris Boutilier</b> <<a href="mailto:Kris.Boutilier@scrd.bc.ca">Kris.Boutilier@scrd.bc.ca</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> -----Original Message-----<br>> From: <a href="mailto:asterisk-users-bounces@lists.digium.com">
asterisk-users-bounces@lists.digium.com</a><br>> [mailto:<a href="mailto:asterisk-users-bounces@lists.digium.com">asterisk-users-bounces@lists.digium.com</a>]On Behalf Of Andrew Kohlsmith<br>> Sent: Tuesday, October 11, 2005 9:31 AM
<br>> To: <a href="mailto:asterisk-users@lists.digium.com">asterisk-users@lists.digium.com</a><br>> Subject: Re: [Asterisk-Users] PRI echo issues: solvable?<br>><br>><br>> On Tuesday 11 October 2005 11:49, alan wrote:
<br>> > After solving the other "low hanging fruit" audio issues in our Asterisk<br>> > PBX, we are left with occasional cases of severe echo which we have not<br>> > found a solution for yet.<br>
><br>{clip}<br>><br>> > Most calls have minimal, acceptable echo levels. But occasionally, we<br>> > get a call where the echo is delayed by a substantial amount (sometimes<br>> > around 250ms), and sounds as loud as the remote party.
<br>><br>> Yup.<br>><br><br>I
suspect that the delay isn't really meaningful as it's a function of
all the intervening processing occurring after the incoming signal
arrives on the interface. If you were to use ztmonitor on the channel
to record the transmit and receive sides to separate wav files, drive
an impulse down the channel (ie. a sharp, loud click) and then load the
files into a tool where they could be viewed side by side you'd see the
actual echo endpath (tail) length. It's possible that the tail is
longer than the echo canceller, particularly if the other caller is on
a digital cordless phone - you can try changing
'echocancel=' in zapata.conf to a higher number (eg. 256) to get a
specific tail length. If you're feeling really adventurous go into
asterisk/channels/chan_zap.c and search for the line 'if ((y == 32) ||
(y == 64) || (y == 128) || (y == 256))' - add higher multiples of 2 to
get longer tail lengths, where 1 unit = 1/8000 of a second (for T1).
FYI, values other than powers of 2 may break zaptel. Note that
excessively long tails are not necessarily better.<br><br>More likely
what's happening on these calls is that the signal level of the
reflected echo is so high (aka. 'hot') that the echo canceller is
refusing to subtract (ie. it thinks the far end speaker is talking) -
the mec2/kb1 canceller uses a form of 'doubletalk' detection that
relies on the reflected signal being at least somewhat attenuated. Take
a look at the comments in the kb1 echo canceller and review the
whitepaper referred to there for specific detail.<br><br>> > One example: when one number (local to the same CO as our PRI) calls us,<br>> > the echo on our end is unbearably bad. When we call them, No Problem.
<br>><br>> I've never seen that, it's always when we call out. Certain<br>> numbers will always trigger it. 888-737-4787 (IPC Resistors, it dumps into an IVR so it's<br>> safe to call) is one such number, but we have local numbers that hit other
<br>> COs which exhibit this problem as well so it's not a specific<br>> CO or switch problem.<br><br>That's
quite interesting. It would be worthwhile to call the number, run a
test signal down the line (eg. milliwatt) and measure both the
transmitted and received signal levels to see if there is positive gain
on that particular circuit.<br><br>{clip}<br>> > - Gain tuning: Is the ztmonitor quantitative target value 14500 or<br>> > 14844? These two sources conflict on this point:<br>> > <a href="http://www.voip-info.org/wiki/view/Asterisk+zapata+gain+adjustment">
http://www.voip-info.org/wiki/view/Asterisk+zapata+gain+adjustment</a><br>><br>> I think you want to achieve an effective value of -2 to -3dBm. I'm unsure<br>> what "value" this is in ztmonitor -v. I know this should not be needed at
<br>> all on a PRI or other digital connection.<br>><br>I
beleive the value is simply a linear representation of amplitude,
between 0 and 32k, hence the proposed use of a loopback to determine
the level developed from a milliwatt reference.<br><br>There is another
article referred to on that page that tries to demonstrate the purpose
of loss-plans and their relationship to echo cancellation. Certainly I
had to introduce some intentional loss on my local asterix-echocan-pbx
PRI link to get optimum performance from the hardware echo cancellers
I'm using. The same theory would apply (if not more so) to the zaptel
software echo can code.<br><br>Hope that helps.<br><br>Kris Boutilier<br>Information Services Coordinator<br>Sunshine Coast Regional District<br>_______________________________________________<br>--Bandwidth and Colocation sponsored by
<a href="http://Easynews.com">Easynews.com</a> --<br><br>Asterisk-Users mailing list<br><a href="mailto:Asterisk-Users@lists.digium.com">Asterisk-Users@lists.digium.com</a><br><a href="http://lists.digium.com/mailman/listinfo/asterisk-users">
http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users
</a><br></blockquote></div><br><br clear="all"><br>-- <br>Tad Heckaman