[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