Shilliday, Jim
2004-Sep-23 06:51 UTC
[Asterisk-Users] Help with strategy for echo cancellation.
I have just installed * (RH9, P4 3.0GHZ, 1G RAM) in a small office, using three TDM400's with 4 FXO's each for incoming calls. Outgoing calls are (for the moment) routed via VoicePulse. Phone sets are Cisco 7940G's using SIP. I'm getting intermittent echo on outgoing calls, and my understanding, based on reviewing the wiki and several posts here, is this: >>>> The source of the echo is the analog tail circuit at the far end of the call. This is consistent with the facts -- I don't have echo on internal calls or on IAX2 calls to another Cisco 7940 on another * box. >>>> There's nothing that I can do about the echo using * echo cancellation because (according to Cisco's Echo Analysis paper) my echo cancellation only deals with echo originating at my end. (Am I wrong? Hope so). >>>> I may be able to minimize the problem by tweaking the Rx/Tx gain in zapata.conf. So, if my understanding is right, can someone please suggest a strategy for adjusting the gain controls? There are two controls, and each can be adjusted up or down. I'd like to adopt a method other than random fiddling. Where's a good place to start? Thanks! Jim Shilliday IT Director Equal Justice Center 1315 Walnut St. Suite 400 Philadelphia PA 19107 215-238-6970
David Cook
2004-Sep-23 08:12 UTC
[Asterisk-Users] Re: Help with strategy for echo cancellation.
I'd like a good plan for this too, however this problem seems to exist only with analog FXO interfaces. If you have 12 lines, would it not have been cost effective to go fractional T1 then the box would be cleaner and the problem be averted? Quoting asterisk-users-request@lists.digium.com:> I have just installed * (RH9, P4 3.0GHZ, 1G RAM) in a small office, > using three TDM400's with 4 FXO's each for incoming calls. Outgoing > calls are (for the moment) routed via VoicePulse.
Shilliday, Jim
2004-Sep-23 08:49 UTC
[Asterisk-Users] Re: Help with strategy for echo cancellation.
All this is consistent with Cisco's analysis -- you can have echo without analog ports IF there's an analog circuit at the other end of the call (and there usually is). We're getting echo on outgoing calls through VoicePulse, not on the FXO's that only carry incoming traffic. Jim Shilliday IT Director Equal Justice Center 1315 Walnut St. Suite 400 Philadelphia PA 19107 215-238-6970 -----Original Message----- From: Bruce Komito [mailto:brucek@bagel.com] Sent: Thursday, September 23, 2004 11:21 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Re: Help with strategy for echo cancellation. Not true, in my experience. We have no analog lines (i.e., no FXO ports), only PRIs, and we have consistent echo problems. Bruce Komito High Sierra Networks, Inc. www.servers-r-us.com (775) 236-5815 On Thu, 23 Sep 2004, David Cook wrote:> I'd like a good plan for this too, however this problem seems to exist > only with analog FXO interfaces. If you have 12 lines, would it not > have been cost effective to go fractional T1 then the box would be > cleaner and the problem be averted? > > Quoting asterisk-users-request@lists.digium.com: > > I have just installed * (RH9, P4 3.0GHZ, 1G RAM) in a small office, > > using three TDM400's with 4 FXO's each for incoming calls. Outgoing > > calls are (for the moment) routed via VoicePulse. > _______________________________________________ > 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 > > This message has been categorized as "Legitimate" by BayesianAnalyzer.> If you do not agree, please click on the link below to train theAnalyzer.>http://216.162.162.39/bt/a.aspx?M=C:%5Csmtpmail%5CBayesTraining%5C2004-0 9-23%5Ca2e4810afa4a433fafbcb80b7ed0e93e&C=2> > -- >-----------------------------------------------------------------------> This message has been inspected by DynaComm i:mail >-----------------------------------------------------------------------> > >_______________________________________________ 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
Rich Adamson
2004-Sep-23 10:15 UTC
[Asterisk-Users] Help with strategy for echo cancellation.
> I have just installed * (RH9, P4 3.0GHZ, 1G RAM) in a small office, > using three TDM400's with 4 FXO's each for incoming calls. Outgoing > calls are (for the moment) routed via VoicePulse. Phone sets are Cisco > 7940G's using SIP. I'm getting intermittent echo on outgoing calls, and > my understanding, based on reviewing the wiki and several posts here, is > this: > > >>>> The source of the echo is the analog tail circuit at the > far end of the call. This is consistent with the facts -- I don't have > echo on internal calls or on IAX2 calls to another Cisco 7940 on another > * box.That's because those paths are basically equivalent to 4-wire full-duplex links. The only place where echo 'could' be generated is from within the sip devices themselves, or from the handset (eg, echo tunneled through the handle). Handset echo 'has been' an issue with some cheap sip phones, and usually stuffing foam rubber into the handle takes care of it.> >>>> There's nothing that I can do about the echo using * > echo cancellation because (according to Cisco's Echo Analysis paper) my > echo cancellation only deals with echo originating at my end. (Am I > wrong? Hope so).Not necessarily true, but could be. If you're hearing your own voice when talking, you're getting feedback from "something" along the path. In very general terms, the delay between a spoken word and when the feedback (echo) occurs should help determine the source location, but you have to listen very closely. The greater the time between a word and the returning echo, the further the source of echo is from you. The Cisco paper assumes a near-perfect world; be careful with assumptions. Example: it assumes that if you have an echo canceller running on your end that its doing what it is supposed to be doing (eg, a quality echo canceller). As you've seen in many many earlier posts, the * echo canceller is not a high quality piece of software and has a rather narrow range of operation. When echo occurs outside that range, the canceller is not handling it at all. Also, you've probably read some of the posts relative to differences that motherboards have on the * echo canceller; if the delay in moving packets from * to the TDM cards and asterisk reading packets back from the TDM card is lengthy, then you will hear echo. Depending on how long that delay actually is, you can easily jump to an incorrect conclusion that its caused by far-end problems (per the Cisco document), when in fact its not. The motherboard issue has something to do with interrupt latency and/or pci bus characteristics, and has absolutely nothing to do with the speed of the processor, brand name on the front of the box, or far-end echo. (I've not heard anyone in six months actually offer up a way to figure out what the issue truly is, just lots of opinions thus far.)> >>>> I may be able to minimize the problem by tweaking the > Rx/Tx gain in zapata.conf. > > So, if my understanding is right, can someone please suggest a strategy > for adjusting the gain controls? There are two controls, and each can > be adjusted up or down. I'd like to adopt a method other than random > fiddling. Where's a good place to start?Each site seems to be a little different, so there's no such thing as a good value to start at. Some machines are very close to Central Offices (where cable loss is insignificant) while others are some distance from the Office (where the loss might be 10 db or so). In very general terms start with 0,0 (rxgain, txgain) and adjust in maybe 2.0 db increments. In most cases you need to stop/start asterisk (not just a reload). The smaller the gain settings, the less echo, but will also become difficult to hear as well. Going to low will also kill DTMF and/or CallerID functions. Rich