[Asterisk-Users] PRI echo issues: solvable?

[Tad Heckaman]

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.

On 10/11/05, Kris Boutilier <Kris.Boutilier at scrd.bc.ca> wrote:
>
> > -----Original Message-----
> > From: asterisk-users-bounces at lists.digium.com
> > [mailto:asterisk-users-bounces at lists.digium.com]On Behalf Of Andrew
> Kohlsmith
> > Sent: Tuesday, October 11, 2005 9:31 AM
> > To: asterisk-users at lists.digium.com
> > Subject: Re: [Asterisk-Users] PRI echo issues: solvable?
> >
> >
> > On Tuesday 11 October 2005 11:49, alan wrote:
> > > After solving the other "low hanging fruit" audio issues in our
> Asterisk
> > > PBX, we are left with occasional cases of severe echo which we have
> not
> > > found a solution for yet.
> >
> {clip}
> >
> > > Most calls have minimal, acceptable echo levels. But occasionally, we
> > > get a call where the echo is delayed by a substantial amount
> (sometimes
> > > around 250ms), and sounds as loud as the remote party.
> >
> > Yup.
> >
>
> 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.
>
> 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.
>
> > > One example: when one number (local to the same CO as our PRI) calls
> us,
> > > the echo on our end is unbearably bad. When we call them, No Problem.
> >
> > I've never seen that, it's always when we call out. Certain
> > numbers will always trigger it. 888-737-4787 (IPC Resistors, it dumps
> into an IVR so it's
> > safe to call) is one such number, but we have local numbers that hit
> other
> > COs which exhibit this problem as well so it's not a specific
> > CO or switch problem.
>
> 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.
>
> {clip}
> > > - Gain tuning: Is the ztmonitor quantitative target value 14500 or
> > > 14844? These two sources conflict on this point:
> > > http://www.voip-info.org/wiki/view/Asterisk+zapata+gain+adjustment
> >
> > I think you want to achieve an effective value of -2 to -3dBm. I'm
> unsure
> > what "value" this is in ztmonitor -v. I know this should not be needed
> at
> > all on a PRI or other digital connection.
> >
> 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.
>
> 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.
>
> Hope that helps.
>
> Kris Boutilier
> Information Services Coordinator
> Sunshine Coast Regional District
> _______________________________________________
> --Bandwidth and Colocation sponsored by Easynews.com <http://Easynews.com>--
>
> 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
>



--
Tad Heckaman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20051011/872c54e5/attachment.htm