I am in the process of migrating from my current (Asterisk 220.127.116.11 / Zaptel 1.4 ) server to a new server which will be running Asterisk 1.4 and DAHDI.
The current server uses the ZTDUMMY source for timing and has NO Digium cards to interface with my PBX. I strictly use SIP trunks to connect with my Iwatsu PBX.
The purpose of the asterisk server is to use MEETME to conference callers via SIP channels coming from my Iwatsu PBX. Some of these callers are located directly on my Iwatsu PBX using TDM or IP phones and some are calling from outside sources arriving via PRI’s which terminate into our Iwatsu PBX.
So far the experience is great. Very little complaints about echo.
Now I am moving to a new server and diving into the world of DAHDI. I am also using a Sangoma UT50 Voice Time USB Sync tool as a clock source (hoping it would be more “business class” than using ZTDUMMY).
My question is:
According to all the reading I have done, DAHDI is configured on a PER-CHANNEL basis unlike Zaptel.
Since I have no physical channels (only my Sangoma USB time source) and all calls arrive via SIP, is anything required in my DAHDI config to enable the same level of echo cancellation as I had with Zaptel?
Currently in my zapata.conf I use the following:
In some cases I have required echotraining=yes but have not had that variable set for some time now as I have no echo problems.
Please help me configure DAHDI so that my echo cancellation settings are similar to the ones I used with Zaptel and not ignored for SIP / MEETME.
Thanks in advance,
The echo canceling setting you may have set would have no effect as you are not using any physical zaptel channels.
Echo in zaptel/DAHDI is due to impedance imbalance. You are only using it a a timimng source.
Thanks for your reply.
If zaptel echo cancellation options have no impact on SIP calls, please explain why on other asterisk servers I have (identical setup) that I would experience massive feedback / echo on MeetMe with only 2 or 3 callers.
So bad that all callers hang up in order to save their ears from bleeding.
I set the echotraining=yes option and restart zaptel / asterisk and the problem is completely solved. That would clearly indicate that zapata.conf settings DO apply to SIP channels.
I’m trying to establish whether or not I’ll run into feedback / echo problems after I migrate all my SIP trunks to my new server with DAHDI.
Faulty phones. In paraticular speaker phones that don’t have either excellent echo cancellation, or VOX.
It is also my understanding that Asterisk relies on IP phones to do their own echo cancellation.
[quote]If zaptel echo cancellation options have no impact on SIP calls, please explain why on other asterisk servers I have (identical setup) that I would experience massive feedback / echo on MeetMe with only 2 or 3 callers.
Who knows, This is what echo traing does and that is to the zap channel
[quote]in your zapata.conf.sample:
; In some cases, the echo canceller doesn’t train quickly enough and there
; is echo at the beginning of the call. Enabling echo training will cause
; asterisk to briefly mute the channel, send an impulse, and use the impulse
; response to pre-train the echo canceller so it can start out with a much
; closer idea of the actual echo.
If it works for you then great.
Ok, I will use the same options for DAHDI that I did for Zaptel and hope it all works.
If I begin to experience echo issues then at that point I will dig deeper into the issue of DAHDI being configured PER CHANNEL for echo cancellation.
I’m guessing that DAHDI still uses the generic options for SIP calls, and you only need to configure the echo canceler PER CHANNEL if you are using physical channels connected directly to asterisk.
Thanks for your input,
Zaptel/DAHDI settings and options have NOTHING to do with SIP at all. a SIP call is a SIP call and a DAHDI call is a DAHDI call any options only effect that channeltype.
Yes if you echocancel a DAHDI channel yes the outcome of it are heard on a SIP device but thats all you do, Hear the outcome as its the DAHDI channel that the echo is cancelled upon.