> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of alan > Sent: Tuesday, October 18, 2005 10:34 AM > To: [email protected] > Subject: [Asterisk-Users] Re: PRI echo issues: solvable? > > > > Subject: RE: [Asterisk-Users] PRI echo issues: solvable? > > "Kris Boutilier" <[EMAIL PROTECTED]> 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 system Almost 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 _______________________________________________ --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
