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

[Oron Peled]

On Thursday, 19 בJune 2008, Kevin P. Fleming wrote:
> Oron Peled wrote:
> > Example: /etc/dahdi/dahdi.conf
> 
> We've had this discussion briefly and hadn't reached a decision, but I
> think if we *do* move it to /etc/dahdi, the filename shouldn't be
> dahdi.conf, since that is just redundant. It should be something like
> 'channels.conf' or 'system.conf' or something like that, but I can't
> come up with a good suggestion.

We could think about many alternative names, but reserving
the namespace /etc/dahdi/ is important.

Let's try to flesh some of it out:
 * /etc/dahdi/system.conf
   Sound reasonable and can replace /etc/zaptel.conf

   Or split it into two files to be read by dahdi_cfg:
     1. read - /etc/dahdi/defaults.conf
     2. read - /etc/dahdi/channels.conf
   That may provide simple semantics (contents of channels.conf
   overrides defaults.conf) -- not sure if that's better...

 * /etc/dahdi/module_list
   Would replace the funny $MODULES games in /etc/sysconfig/zaptel
   Should simply contain one module name per line and be used
   by /etc/init.d/dahdi and other scripts of this type.

 * /etc/dahdi/init.sh
   Would contain configuration variables used by /etc/init.d/dahdi
   (instead of /etc/sysconfig/zaptel, /etc/default/zaptel)

> > 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.
> 
> If we do that, it will work the same way that the 'defaultlaw' setting
> works, which is that it overrides the setting for all channels at the
> time it is parsed, even if previous configurations have set channels
> already. In other words, the 'default<foo>' settings have to be appear
> *before* any channel-specific settings; making dahdi_cfg able to handle
> intermingling them would complicate the code too much to be worthwhile.

That's pretty bad semantic for "default", but I'm not looking at
the code right now, so I'll leave it for the time being.

> > 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)?
> 
> Well, the DAHDI_CHANCONFIG ioctl will fail if the chosen echo canceler
> can't be attached to the channel, which will cause dahdi_cfg to abort
> and report the failure as well. I hadn't thought about the possibility
> of using channel alarms for this purpose; that may be a good solution,
> and if we did that, we'd let dahdi_cfg continue to attempt to put the
> same (unavailable) echo canceler onto each channel it is configured for
> so that all of them will go into alarm, not just the first one.

I must admit your original suggestion (failing the ioctl and as a result 
failing dahdi_cfg) seems better than my alarms idea. I think a critical
configuration error should be evident immediately and loudly.


-- 
Oron Peled                             Voice/Fax: +972-4-8228492
oron at actcom.co.il                  http://www.actcom.co.il/~oron
    .--.
   |o_o |
   |:_/ |
  //   \ \
 (|     | )
/'\_   _/`\
\___)=(___/