[asterisk-dev] RFC: DAHDI echo canceller configuration change

Tzafrir Cohen tzafrir.cohen at xorcom.com
Thu Jun 19 02:48:09 CDT 2008


On Wed, Jun 18, 2008 at 06:11:06PM -0500, Kevin P. Fleming wrote:
> I'm working in a branch of DAHDI's 'linux' package:
> 
> http://svn.digium.com/svn/dahdi/linux/team/kpfleming/modular_ec
> 
> This branch contains modifications to allow one (or many) echo cancelers
> to be built and loaded at the same time, and then runtime selection made
> as to which one should be used on which channel(s). All of the existing
> modules have been converted, and the core code is ready to use them, so
> what I'm left with is deciding on a configuration method.

Wow, looks good!

> 
> I'd like to just use the existing /etc/dahdi.conf and dahdi_cfg tools to
> do the configuration, adding something like:
> 
> echocanceler=MG2
> 
> or
> 
> echocanceler=HPEC

What happens if you run dahdi_cfg twice?

> 
> Doing so would then apply that choice to all subsequent channels
> configured in the file in *any* signaling mode (although obviously many
> signaling modes don't support audio, and thus will never actually use
> the echo canceler defined for those channels).
> 
> This seems pretty straightforward to me, however, it would be the *only*
> parameter in /etc/dahdi.conf that 'inherits' into later definitions in
> the file, which is probably not a wise choice.
> 
> An alternative would be for the syntax to be something like:
> 
> echocanceler=MG2,1-4
> echocanceler=HPEC,8-12
> 
> This fits the existing model a bit more.
> 
> In addition to this, there is a need to find some way to set a default
> echo canceler to be used if the configuration file does not specify one.
> In Zaptel, this was done at compile time, but since all available echo
> cancelers are compiled and installed now, there isn't any practical way
> to do that, and I'd rather move away from compile-time configuration anyway.

Actually, I keep asking myself why running dahdi_cfg is really required.
If you have hepc and mg2, why would you use mg2?

BTW: any reason to build (by default) any other EC beside MG2?

Also, what exactly do you do on unregistration of an echo canceller
module? Channels may be left with pointers to ec. 

> 
> I could certainly add an additional configuration parameter for this, or
> make the 'echocanceler=<name>,<channels>' parameter accept *no channels*
> as an argument, which would then apply it to all channels.
> 
> Thoughts? Whichever way this goes, I'll end up documenting it in
> UPGRADE.txt in the source tree, because it will be a significant change
> in behavior from Zaptel 1.4.

This is still overriden by the span-specific echo-canceller method
(which is basically for a hardware echo canceller), right?

> 
> Another note: I won't require the user to forcibly load echo canceler
> modules; if a name is provided and no module currently provides it, the
> DAHDI core will attempt to 'autoload' that module to satisfy the request.

BTW: the modules do not have to be names dahdi_ec_* . They can also
provide an alias with that name. As do the xpp/card_*.c .

One small downside of this is that modprobe can only load from the default
modules location. You can check the mess around the loading of the
various xpd_* modules in the script live_zap in the zaptel source tree
for a very lousy work around in case you actually want to use your own
modules and not the system ones. E.g. because you have not installed
them yet and the system ones won't load.

(Or worse: a case where the system ones will load, but panic)

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir



More information about the asterisk-dev mailing list