Hello, 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. Our system: - Asterisk 1.2.0-beta1 - TE110P on a PRI - TDM04 and TDM40, but these are unrelated to current echo issues - Fedora core 3 - Echo canceller KB1 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. 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. Am I right in guessing that we're unlikely to solve this in a system-wide manner on our end, and at best we'd have to convince the phone company they're misconfigured, for one remote phone number at a time? Some other specific questions: - 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 http://lists.digium.com/pipermail/asterisk-users/2004-November/071301.html - Is the difference between 14500 and 14844 big enough to worry about? If my gain settings are incorrect, am I going to be seeing quantitative values a few hundred away, or ten thousand away (for example)? - Is gain tuning effective using CO or asterisk-local milliwatt sources useful on a PRI line? Presumably, the path to the local CO's milliwatt line is all digital, and the loopback path to call our own internal milliwatt source will almost definitely be all digital, so where would the loss come from? - Assuming gains are tuned correctly, or don't matter for the PRI, is there any other hope I have for solving these echo issues? Thanks, Alan Ferrency pairNIC pair Networks, Inc. alan@pair.com
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.> Our system: > - Asterisk 1.2.0-beta1 > - TE110P on a PRI > - TDM04 and TDM40, but these are unrelated to current echo issues > - Fedora core 3 > - Echo canceller KB1Add to the mix Asterisk CVS HEAD (always within a couple of weeks of today) Slackware 10.1 TE405 and TE406 (with and without VPM support) Tried with various motherboards and chipsets (all P4)> 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.> 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. I have just verified today with the 888 # mentioned above that zaptel is NOT disabling its echo canceller. dmesg shows no "disabling echo canceller due to tone" message and "zap show channel [affectedchannel] shows that the echo canceller is configured correctly (128 taps for us) and is ON. I hope to do further testing as I am made more aware of the numbers causing the issues.> - 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+adjustmentI 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. -A.
> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com > [mailto:asterisk-users-bounces@lists.digium.com]On Behalf Of Andrew Kohlsmith > Sent: Tuesday, October 11, 2005 9:31 AM > To: asterisk-users@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
I'd be interested to know if this gets worse over time. Shutdown asterisk, remove card driver, load card driver, load asterisk.... then test. =========================================Rod Bacon Empowered Communications Ground Floor, 102 York St. South Melbourne Victoria, Australia. 3205 Phone: +613 99401600 Fax: +613 99401650 FWD: 512237 ICQ: 5662270 ========================================= alan wrote:> Hello, > > 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. > > Our system: > - Asterisk 1.2.0-beta1 > - TE110P on a PRI > - TDM04 and TDM40, but these are unrelated to current echo issues > - Fedora core 3 > - Echo canceller KB1 > > 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. > > 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. > > Am I right in guessing that we're unlikely to solve this in a > system-wide manner on our end, and at best we'd have to convince > the phone company they're misconfigured, for one remote phone > number at a time? > > Some other specific questions: > > - 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 > http://lists.digium.com/pipermail/asterisk-users/2004-November/071301.html > - Is the difference between 14500 and 14844 big enough to worry about? > If my gain settings are incorrect, am I going to be seeing > quantitative values a few hundred away, or ten thousand away > (for example)? > - Is gain tuning effective using CO or asterisk-local milliwatt sources > useful on a PRI line? Presumably, the path to the local CO's milliwatt > line is all digital, and the loopback path to call our own internal > milliwatt source will almost definitely be all digital, so where would > the loss come from? > - Assuming gains are tuned correctly, or don't matter for the PRI, is > there any other hope I have for solving these echo issues? > > Thanks, > > Alan Ferrency > pairNIC > pair Networks, Inc. > alan@pair.com > _______________________________________________ > --Bandwidth and Colocation sponsored by Easynews.com -- > > Asterisk-Users mailing list > Asterisk-Users@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 > >
> Subject: RE: [Asterisk-Users] PRI echo issues: solvable?"Kris Boutilier" <Kris.Boutilier@scrd.bc.ca> wrote:> > 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 finally got time to spend on looking into this again.> 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.How does one use ztmonitor to record into separate files for transmit and receive? My ztmonitor man page doesn't describe how to do this, it only allows one -f File specification. When I monitored a sample conversation with ztmonitor, it recorded both channels in one file. Then I set up a call from the number which gives us "big echo". Although I heard echo when I was on the call, the recorded version of the call did not record the echo. There are two possibilities here: 1. it wasn't recording the incoming call leg. 2. the echo is entirely internal to our system I couldn't see how #1 could be the case when the immediately previous ztmonitor recorded both call legs. On the other hand, I told the remote party to just put the phone down so I have no evidence that any sound they made was missing. But I can't see how #2 is the case either, since it only affects certain phone numbers, and it affects them consistently whenever it happens. I have a feeling I just did something wrong, so I'll go back and try again. I'll also try a greater echocancel= value and see if it helps. Thanks, Alan Ferrency pair Networks, Inc. alan@pair.com
> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com > [mailto:asterisk-users-bounces@lists.digium.com]On Behalf Of alan > Sent: Tuesday, October 18, 2005 10:34 AM > To: asterisk-users@lists.digium.com > Subject: [Asterisk-Users] Re: PRI echo issues: solvable? > > > > Subject: RE: [Asterisk-Users] PRI echo issues: solvable? > > "Kris Boutilier" <Kris.Boutilier@scrd.bc.ca> wrote: > > > > 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. > > >{clip}> > > 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. > > How does one use ztmonitor to record into separate files for transmit > and receive? My ztmonitor man page doesn't describe how to do this, it > only allows one -f File specification. >Oops. It seems I was thinking of cmd_monitor(), which records tx and rx legs seperately... my error, sorry. Sounds like a good idea for a patch to ztmonitor. :-)> When I monitored a sample conversation with ztmonitor, it > recorded both channels in one file. Then I set up a call from the number which gives > us "big echo". Although I heard echo when I was on the call, the > recorded version of the call did not record the echo. > > There are two possibilities here: > 1. it wasn't recording the incoming call leg. > 2. the echo is entirely internal to our systemAlmost there - I would suggest the echo is indeed present, but the time taken for the echo to arrive back on the zap interface is imperceptibly small (ie < 20ms) so you can't perceive it as an 'echo'. You might still be able to see the reflection if the impulse is sharp (ie. short) enough by loading the wav file from ztmonitor into Sonogram (http://www.dfki.de/~clauer/sonogram/) and visually examining the waveform. If the echo delay path is too short to see then the reflection will have been merged with the transmitted signal in the consolidated file and have just resulted in an increase in amplitude. It's the time delay due to processing and conveyance inside Asterisk and everything else between your endpoint and the zap interface that causes the reflection to change from 'sidetone' to 'perceptible echo'. cmd_monitor() should be recording after at least some amount of delays are introduced, thus the echo should be clearly audible there. It's very important to understand that short echo paths (ie. < 20ms) occur quite frequently in the PSTN but unless something introduces an additional delay into the signal path, and ISDN based digital PBXs such as the Norstar or Meridian don't, the echo can't be perceived. Thus Asterisk, because everything it does involves packetization and it's associated processing and conveyance delays, needs to meet a much higher standard of echo cancellation. Hope that helps. Kris Boutilier Information Services Coordinator Sunshine Coast Regional District
Hi, I?ve just installed an Asterisk Server on a Fedora Core 4, and made it work between diferrent extensions in the office and now I need to make it work on calling outside the office and I think I need a Dial Plan, can somebody help me a little with this? Thanks a lot