Hi Sean,
We were experiencing a similar problem with these units and were able to verify that it was in fact the remote end but the threshold of the echo canceler seems to be too low by default.  We could hear echo and then unplug the handset from the base on the other end, without muting, and the echo would stop.  We found that decreasing the gain slightly all but eliminated complaints.  This does reduce the level slightly but in our traces it was close to on par with an analog handset.  The pertinent configuration options are:

  <Handset_Input_Gain>-6</Handset_Input_Gain>
  <Headset_Input_Gain>-6</Headset_Input_Gain>
  <Speakerphone_Input_Gain>-6</Speakerphone_Input_Gain>
  <Handset_Additional_Input_Gain>0</Handset_Additional_Input_Gain>
  <Headset_Additional_Input_Gain>0</Headset_Additional_Input_Gain>
  <Speakerphone_Additional_Input_Gain>0</Speakerphone_Additional_Input_Gain>

Thanks,
Spencer


On Mar 19, 2013, at 7:49 AM, Anthony Minessale wrote:

Sean,

You are welcome to disagree.  Science is driven by people being unwilling to accept things as they are.
I do have some explanations for you if you are interested.

Cisco and Linksys ATA both have echo cancelers in them at the point where the analog data is converted to digital.  This is the ideal place for it as I mentioned earlier.  So they actually are doing something about the problem and that is why you do not observe one.  Getting echo while using a cell phone is also very common.  The more latency and conversion of the audio data you experience, the more likely you can have echo.  (iPhone is notorious) The other place where its important to have echo cancellation is the point where the digital data in the rtp stream is transferred into the TDM gateway interfacing with the PSTN.  This is why most TDM cards like Digium and Sangoma have onboard echo canceler chips.  We are not completely helpless, we can do some unnatural things like decode the audio signal we are passing through and try to run some echo cancellation on it but, in the conditions you describe where you hear a perfect replica of what you are saying 2-5 seconds later only softer.  That is for sure outside the range of any echo canceler.  It cannot reliably tell that this clean signal coming many seconds later should be filtered out because its a replica of data that has already passed by long before.  Usually in this type of issue, you are actually hearing the other side hear what you said.  So you say the statement, the latency takes its toll and the echo is coming back at you from the far end as they are hearing it.  

I am open to options.  We do have some work on doing some inline audio processing underway but we should not rely on them if we can possibly control the surroundings better first.  If you are talking to me in the same room using a megaphone and I am wearing ear plugs.  Its easier to tell you to turn off the megaphone and tell me to remove the ear plugs.





On Mon, Mar 18, 2013 at 9:24 PM, Sean Devoy <sdevoy@bizfocused.com> wrote:

Hey Anthony,

 

Does that mean PBXMate is not worth investigating?

 

I have to disagree here. Placing the blame entirely on the phones at the other end doesn’t hold water for me.  I have had echo problems calling from my cell phone when leaving a voice mail on FS where there is no phone at the other end. So clearly there are situations where it ain’t just the phone at the other end.  It also leaves no explanation why Cisco Phones and Linksys ATAs don’t have the same problem with Commercial Venders like Vonage.  They don’t have anything different at the end of the line for echo cancellation then FS does. I have also had users confirm they are still getting echo with the microphone MUTED on my end.

 

Again, I love FS and I am not trying to bash anyone or any code.  I am just saying there has to be more to this puzzle.  I know what a crappy speaker phone’s echo sounds like and I am not at all concerned about that. Crappy speaker phones sound like crappy speaker phones no matter what. I don’t think that’s what I am trying to track down.  These are business call where 90% are using the standard handset on business quality phones.  It happens at various levels, but when it is at the bad end of the spectrum (e.g. long delay and loud), it does not sound like echo off of walls coming back in a microphone.  It is like my input channel has been delayed, softened and looped directly back to me crystal clear.  Maybe it is one of my VOIP providers’ hardware or software and is load dependent, but the problem exists outside of cheap phones. And of course it is only reproducible on 3 calls in a hundred at peak usage hours, making it a nightmare to track or diagnose.  But those 3 calls are the ones my customers want to talk about at billing time.

 

Now, I have just thrown that all out there is hopes that 50 people will say “That absolutely never happens to me with FS” so I can look at it a different way.

 

Thanks for your thoughts.

Sean

 

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale
Sent: Monday, March 18, 2013 7:30 PM


To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] Removing echo.

 

The best place for echo cancelation is in the clients as close to the mic as possible.

Someone asked why skype and some apps are better.  It's because they have echo cans in the client app.

Sip soft phones are basically toys unless they have some kind of advanced gain and echo controls on your pc because that is where your mic is and could have the vol turned up too high etc.

 

From FS perspective in the middle, we can't tell its echo or not because we are just passing the data along and we're typically getting it 30-70 ms too late.  

 

 

In general, you don't get echo when using real phones because they have proper hardware and software to deal with the place where the audio is being sampled and rendered.

 

 

 

 

 

On Mon, Mar 18, 2013 at 5:15 PM, Christopher Rienzo <cmrienzo@gmail.com> wrote:

Echo cancellation is not easy.  The only open source one I've seen is GPL (making it license incompatible with FreeSWITCH) and is not suitable for handling echo over IP networks.  Perhaps tricks are being played using VAD to only allow only one speaker at a time in the ooVoo conference?



On Mon, Mar 18, 2013 at 5:53 PM, Mimiko <vbvbrj@gmail.com> wrote:

Today we tried ooVoo conference system with theirs client using same
boxes and microphones - again, no echo. How this can be? Is it only
commercial products have echo removing function?


--
Mimiko desu.

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

 


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



 

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org




--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org