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

Oron Peled oron.peled at xorcom.com
Thu Jun 19 00:35:19 CDT 2008


On Thursday, 19 בJune 2008, Kevin P. Fleming wrote:
> 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).

Looks very good.

> I'd like to just use the existing /etc/dahdi.conf and dahdi_cfg tools to
> do the configuration,

I think the inevitable renaming is a good timing to prepare for the
future and have the configuration for dahdi in its own subdirectory.

Example: /etc/dahdi/dahdi.conf

That would provide a central location for other config files that are
currently maintained in a linux distribution specific places
(e.g: /etc/default/zaptel, /etc/sysconfig/zaptel, etc.)
Also, since dahdi became a pretty big framework on its own, we are
bound to need more info/control files in the future -- let's not
scatter them in /etc.

> 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.

Agreed this is bad idea. Tzafrir already had his own share of
work to (somewhat) eliminate this "leakage" in zapata.conf.

> 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.

Very good.

> 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.

Or maybe:

default_echocanceler=<name>

While it is mouthfull, it's easy to parse for everybody (humans,
dahdi_config, miscellaneous scripts, etc.) and less prone to
human errors.

> 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.

Good. The hard part is to decide what to do in case of failure (in
addition to a message), as dahdi is already loaded at this stage.

Maybe put the relevant channels in some alarm (now that we have
per-channel alarms implemented)?


-- 
Oron Peled                             Voice/Fax: +972-4-8228492
oron at actcom.co.il                  http://www.actcom.co.il/~oron
You know, someone once told me that New York has more lawyers than people.
                                         -- Warren Buffett, Fortune, 1999



More information about the asterisk-dev mailing list