> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Andrew Kohlsmith
> Sent: Tuesday, October 11, 2005 9:31 AM
> To: [email protected]
> 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 --
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
