Hi,
I’ve set up a MeetMe conference on a pure voip system (i.e. I have no telephony cards on my Asterisk server). We are using X-Lite and that too on our LAN (nothing going outside). Now occasionally we hear echo on our phones and I wonder if that is because of the unavoidable dahdi_dummy timing source or because the other dahdi hardware modules are also running alongside the dummy?
Regards.
are you using computer speakers, or head phone speakers?
Just wondering if your microphone is hearing noise from the speakers…
I am using headphone speakers and they work fine with normal calls.
If you absolutely must minimise echo, you should invest in custom moulded headphone earpieces. They are sold to hifi enthusiasts, and the broadcast and security industries, although the earmoulds are also used for hearing aids. IPod style in the ear phones may work, but not as well.
Don’t use a microphone boom attached to the headset, as the boom will conduct sound.
It is unlikely that Dahdi has any connection with the echo, which is simply the result of the microphone picking up some of the sound from the headphones.
Conferencing is probably exacerbating things as normal echo cancellation may be limited to handing one echo. You need VOX to deal with that, but you will still get echoes between when you stop speaking and the VOX cuts your microphone off.
Normally the phone has to deal with echo cancellation (and VOX) on VoIP as the PABX is often optimised out of the speech path.
Note that it is the headsets of the other parties, not yours, that matter here.
Hi
This sounds like the classic meetme problem with the rtp streams going “out of sync”. is it more noticable if more users are in the conference ?
Ian
The echo is at our individual headsets i.e. I can hear my own speech. It happens even when we have merely two parties. It seems either very high quality headphones or decent hard phones may minimise the problem. It is strange though that echo does not occur during a normal call with the same headphones.
[quote=“ianplain”]This sounds like the classic meetme problem with the rtp streams going “out of sync”. is it more noticable if more users are in the conference ?
[/quote]
Ian,
Can you elaborate on this ‘classic’ problem? I use MeetMe extensively in my production platform. I have, on occassion, had some complaints of echo which I was unable to track down or reproduce.
I am a SIP only environment with no Zaptel/Dahdi hardware, so I use the dummy drivers.
thanks,
G
Whilst you may be hearing the echo, it is not your headset that is the problem. You voice is going out to the other participants, getting coupled between one or more of their headsets and microphones, then returning to you.
It is their headsets that have to be sealed from the microphones to completely eliminate echo.
What I think Ian was saying is that, normally, the conference is set up so that the round trip time, from the conference bridge, to each participant, is the same. Assuming that the audio feedback delay is also small or consistent, the combined echoes can be treated as a single echo, by the phone’s echo canceller.
If, however, the round trip times change (e.g. because a latency buffer overflows or underflows) for one participant. The echoes generated at that participant will arrive at a significantly different time from those from the other ones, and the phone’s echo cancellation will have difficulty coping with it.
(I don’t know if the conference bridge has any specific tricks to try and maintain matched round trip times.)
Hi
The classic problem with meetme is that under load in a sip only environment the rtp streams can get mixed out of sync ie delayed. this can lead to a delay of of upto about a second or so. I have seen this in all sip only environments when meetme gets under load.
For this reason we dont use meetme in production. but use an alternative based upon app_conference but with many custom modifications.
This issue has nothing to do with RTT but this will make it worse. We have experienced it when the systems where located next to the public gateways so all calls have exactly the same RTT.
Ian
For clarification, what I mean by round trip time is the combination of the time in the latency buffers and the time to physically propagate the packets. (The purpose of the latency buffer is to add enough extra delay that, hopefully you can compensate for temporary high propagation delays by reducing the time in the buffer.)
Hi,
What kind of kit are you using for your server, phones and how many participants do you have on average on your conference calls?
Thanks.
Dell servers connected to Cisco PSTN Gateways . 200+ callers per server.
Ian
Ian,
Is your version of app_conference proprietary, or have you given back to the community? I started out with app_conference, but there were some things I didn’t like in regards to stability. The project seemed, well, dead, so I wasn’t thrilled to build out around it.
We use MeetMe exclusively now… but as discussed, it has issues.