We are having trouble with an installation that is getting a lot of echo on some calls. The installation is all SIP phones and they have a VoIP provider. When we call through the voip provider and into another of their customers (voip throughout) there is no echo problem. If we call in their landline, through the TDM400's FXO to one of the SIP phones, there is no echo problem. Sometimes when we dial from SIP --> Voip provider --> PSTN --> destination it is okay, but other times the echo is horrible. In trying to figure this out, I found this article at Cisco's site: http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a00800d6b68.shtml#1041385 It claims that echo always comes from the far end of the connection. So if I hear echo, then the origin of the echo is in the equipment on the end of the line near the person to whom I'm talking. The description seems to make sense, but the zapata.conf setting for echo cancellation seem to also help echo on the near end of the connection. I have read about echo on the wiki and in the mailing list, but it almost always discusses it with respect to the digium cards, not SIP alone. Is the Cisco article accurate? Thanks! -- -M There are 10 kinds of people in this world: Those who can count in binary and those who cannot.
Yes, if you hear echo then the source of the echo is from the far end equipment. This is due to the fact that delay is what makes echo noticeable. Think of yelling in a small room. Your voice bounces off all of the walls and returns to your ears but you probably don't hear any echo since the time from when you spoke to the time when the sound was returned to your ears was too short. Now think of yelling in a large canyon. The time it takes your voice to leave your mouth, bounce off the canyon walls and return is large enough that you now notice the echo. The same principle applies to VoIP. If you are hearing echo on your conversation it is because there is something at the far end equipment that is reflecting the signal (typically a A/D conversion or 2/4 hybrid). Now although the echo is caused by the far end the *near end* echo canceller is responsible for eliminating this echo which is why when you tweak zapata.conf you notice a difference. Essentially the near end echo canceller is looking at the outgoing signal and analyzing the return signal for the same wave form. Also, keep in mind that *delay* is what really causes echo. As the delay in your ISP increases the echo will become more noticeable (remember the canyon analogy) If you can reduce delay through QOS or some other mechanism you should also be able to reduce echo. Another common problem that causes echo in networks is not setting your loss plan correctly. You need to be sure that you aren't coming in too hot at any of your analog interfaces. In general you should see a signal between -20dbm and -12dbm when someone is talking on the line. If it is significantly hotter then you run the chance of having a larger reflected signal resulting in echo. I typically try padding down analog levels by 3dB at a time to see if echo is reduced. In the canyon analogy this equates to yelling louder which in turn makes the echo louder. ----------------------------------------- It claims that echo always comes from the far end of the connection. So if I hear echo, then the origin of the echo is in the equipment on the end of the line near the person to whom I'm talking. The description seems to make sense, but the zapata.conf setting for echo cancellation seem to also help echo on the near end of the connection. I have read about echo on the wiki and in the mailing list, but it almost always discusses it with respect to the digium cards, not SIP alone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20050326/1adcd7d6/attachment.htm
On Sat, 2005-03-26 at 09:16, Michael George wrote:> We are having trouble with an installation that is getting a lot of echo on > some calls. The installation is all SIP phones and they have a VoIP provider. > > When we call through the voip provider and into another of their customers > (voip throughout) there is no echo problem. If we call in their landline, > through the TDM400's FXO to one of the SIP phones, there is no echo problem. > > Sometimes when we dial from SIP --> Voip provider --> PSTN --> destination it > is okay, but other times the echo is horrible. > > In trying to figure this out, I found this article at Cisco's site: > http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a00800d6b68.shtml#1041385 > > It claims that echo always comes from the far end of the connection. So if I > hear echo, then the origin of the echo is in the equipment on the end of the > line near the person to whom I'm talking. > > The description seems to make sense, but the zapata.conf setting for echo > cancellation seem to also help echo on the near end of the connection. > > I have read about echo on the wiki and in the mailing list, but it almost > always discusses it with respect to the digium cards, not SIP alone. > > Is the Cisco article accurate? Thanks!The Cisco article is accurate, but incomplete. Echo is a difficult problem to troubleshoot. You described an intermittent echo problem. Here's the most likely reason for it.... Telephone companies install echo cancelers in racks and the echo cancelers are a shared resource. That means that the same echo canceler is not always attached to the same T-1. If one of the echo cancelers is wired backwards (not often, but it happens) it will still pass signal, but it won't cancel the echo from the 4-wire to 2-wire hybrid. This scenario is one reason why you might have intermittent echo. Another is if the far end is using a low quality speaker phone and there is acoustic echo (i.e. sound waves bouncing around the room, just like echo in a cave). Acoustic echo is harder to cancel than electrical echo. If the echo cancelers use old technology and don't take frequency distortions into account (many don't) then the acoustic echo won't be canceled very well. I'm new to Asterisk, but from what (admittedly little) I've learned so far about Asterisk echo cancellation, I don't think the tail length is long enough. This link http://www.voip-info.org/wiki-Asterisk+echo+cancellation says that the Asterisk echo cancellation algorithm uses a finite impulse response filter with 128 taps. 128 taps divided by 8 taps per millisecond = 16 milliseconds of echo cancellation. If this is correct, then the algorithm is doing absolutely nothing for you. Echo cancelers that sit very close to the source of the echo (the hybrid) have tail lengths of 16 msec. For echo cancellation, the round trip delay is important because an echo canceler works by comparing a copy of the original signal to the returned signal to determine whether or not there is echo. Tail length is how long echo canceler will look for a signal that is close to the original signal (i.e echo). The Asterisk PBX is a long way (in time) from the source of the echo. Consider this.... Asterisk ---> network ---> PSTN ---> hybrid (echo) ---> end user | | near user <--- echo cnx <--- jitter buffer <--- ntwk <--- PSTN <-| What's the round trip time? It's at least 80 milliseconds. If you're designing an echo canceler you must allow for it to be at least 128 msec (that's because echo cancelers make use of FFTs and therefore always have tail lengths that are a factor of 2). This means that the Asterisk tail length needs to be 256 milliseconds (256 msec * 8 taps per msec 2048 taps). As I said before, I'm new to Asterisk, so I don't know if there's a configuration setting to increase the number of taps. I will say this though... echo cancellation requires a lot of processing cycles. In the PSTN, echo cancelers are hardware devices that use DSPs with the FFT algorithms in silicon. Do a 2048 tap echo canceler in software for 100 simultaneous call streams and you'll burn a lot of processor cycles. Echo is a complex problem. Jeff Heath
Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3034 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20050425/8594ea76/smime.bin
Don't; forget the Milliwatt application in Asterisk -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Keith O'Brien Sent: Monday, April 25, 2005 4:28 PM To: lists@masonc.com; Asterisk-Users@lists.digium.com Subject: RE: [Asterisk-Users] Cisco's description of echo If you are running a Cisco VoIP gateway you can send a 0dBm 1000Khz test tone into or out of a voice port with: "test voice port <port#> inject-tone network 1000hz" to measure the tone do a: "sh call active voice brief">>Another common problem that causes echo in networks is not settingyour>>loss plan correctly. You need to be sure that you aren't coming intoo>>hot at any of your analog interfaces. In general you should see asignal>>between -20dbm and -12dbm when someone is talking on the line. If itis>>significantly hotter then you run the chance of having a largerreflected>>signal resulting in echo. I typically try padding down analog levelsby>>3dB at a time to see if echo is reduced. >How do you measure the amplitude of a pstn line? As an audio engineerin a>previous life, I would love to be able to send standard level tonesdown a>pstn line and measure the amplitude at my end, then adjust the inputgain>accurately. Is there a way to do this?-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20050425/ce1dcbc0/attachment.htm