Hi list! I have a strange echo problem. Two days ago I setup * 1.0.6. at a friend of mine. Just an * server and for outbound calls wengo.fr was used to place calls via sip. He had a strange echo on the line I didn't experience on my setup. Today I upgraded my asterisk 1.0.5 to 1.0.6 and suddenly I have an echo too on sip calls thru wengo!! I already verified wengo was not the source of the problems by switching accounts on the server so I'm pretty sure the problem appeared after installing astreisk 1.0.6. Is anyone else experiencing this problem and is there anything that can be done about it? Both setups are similar, an * box with SIP phones (Grandstream and Sipura SPA-2000's) and a wengo sip account to place calls. Thanks! Remco
Remco,> -----Original Message----- > I have a strange echo problem. Two days ago I setup * 1.0.6. > at a friend > of mine. Just an * server and for outbound calls wengo.fr was used to > place calls via sip. He had a strange echo on the line I didn't > experience on my setup. > > Today I upgraded my asterisk 1.0.5 to 1.0.6 and suddenly I > have an echo > too on sip calls thru wengo!!Can you identify which side of the conversation hears the echo ? As you know, echo is heard on the side opposite of where it is generated. Also it is good to have an idea of the audio path you are looking at. In general there can be no audio leakage in a digital path, so everything that is using VoIP cannot introduce an echo.> I already verified wengo was not the source of the problems > by switching > accounts on the server so I'm pretty sure the problem appeared after > installing astreisk 1.0.6.You could verify that by rolling back to 1.0.5 now. To be honest, I doubt that the asterisk version will introduce an new echo issue. There are a few things you might consider: - The methods in which asterisk cancels echo may have been changed between 1.0.5 and 1.0.6. You would never notice this, because your setup is all VoIP (no Zap) - You might experience echo because the length of the audio path is now exceeding 25 ms where it was not before. I doubt this is the case because almost any VoIP setup will exceed that boundary. You might try to verify it though.> Both setups are similar, an * box with SIP phones > (Grandstream and Sipura > SPA-2000's) and a wengo sip account to place calls.I can imagine the Grandstream or a cheap phone on the Sipura might introduce some accoustic echo (i.e. sound that is played out the speaker and then picked up on the microphone). In that case you would probably have noticed it with 1.0.5. too, but maybe you changed some gain settings in the mean time ? Also note that in this scenario the other party (behind the Wengo network) would hear the echo, not you. There are some ways to suppress this kind of echo, but the only real solution for this is lowering the volume on your phones. If this does not help, roll back to your previous version, test again. Also inquire at Wengo if they have changed anything on their setups recently that might cause such an effect. Best regards, Florian
> -----Original Message----- > From: Remco Barende [mailto:asterisk@barendse.to] > Sent: Sunday, March 20, 2005 9:13 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: RE: [Asterisk-Users] Echo after upgrade * 1.05 -> 1.06 > > >> The echo is quite slow, I would estimate about half a second > >> or even more! > > > > Wow, that's enormous - However your ears can easily deceive you on this. The > > only way to know for sure is to record and analyse. Half a second would > > imply its accoustic coming from the other end. Is it on all calls or only on > > calls with certain people ? Is it when they call you, you call them or both > > ? > > It could be deceiving indeed but the echo is slower than > usually. I did downgrade to asterisk 1.0.5 and the echo is less but still > there. I did not downgrade zaptel as I think it's not related. Or could it > be a zaptel timing problem?Increases and decreases in the time taken for the audio to traverse the entire audio path will manifest themselves as changes in percevability of echo. For example, changing from an entirely uLaw path to a Speex-compressed path will introduce additional non-trivial processing delays (see 'show translation' in console). It's possible to have an echo on a path that is initially perceived as sidetone suddenly become a problem echo because of the introduction of additional delays (ie. longer than the 20ms perceivability threshold). Perhaps there compiler options have changed or the code has become less efficient somewhere resulting in a greater delay. If you haven't changed your configuration anywhere then try comparing the output of 'show translation' on both versions to verify the codecs are performing similarly. Kris Boutilier Information Systems Coordinator Sunshine Coast Regional District