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

[Kevin P. Fleming]

Tzafrir Cohen wrote:

> What happens if you run dahdi_cfg twice?

Same thing that happens now; if the configuration of the channel hasn't
changed, it won't be touched. If the configuration has changed, but the
channel is open, then dahdi_cfg will attempt to reconfigure it but fail
due to it being open.

> Actually, I keep asking myself why running dahdi_cfg is really required.

Because there are a lot of possible configurations today that can't be
represented by the userspace application (networking, DACS, stuff like
that).

> If you have hepc and mg2, why would you use mg2?

If you don't have enough licenses for HPEC for all of your channels, or
if you don't want to run a complex EC like HPEC (or OSLEC) on FXS ports
where something simpler could do the job.

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

Yeah... I don't want to build a configuration mechanism to allow them to
be turned off (except for building DAHDI in-tree in a kernel source
build). Building them is cheap and fast, and they won't be loaded unless
they are requested.

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

The EC module can't be unloaded while any channels are attached to it,
because it's reference count won't allow it. Note that I said
*attached*, not actively using it. Attaching a channel to an EC means
that EC will be used if and when the channel has the EC turned on, but
even when it is off the reference count is still there, so that the EC
can't go away while the channel is in use.

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

Yes.

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

Yeah, but I'd rather have the file names reflect what they are, since
they are specific to DAHDI because they require the DAHDI registration
and use interface.

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

Well, a user can manually load the EC module(s) he/she wants to load, in
that case.

-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)