[asterisk-dev] app_meetme call for testing: Roll call, eject all, mute all, record in-conf

[Joshua Colp]

----- dimas at dataart.com wrote:

> To me personally, there are some stuff missing in ConfBridge which is
> more important than some menus - there are no AMI events similar to
> MeetmeJoin/MeetmeLeave/MeetmeMuted. Which means people who use any
> kind of automation and/or Web UI cannot convert their code for the new
> application.

It's relatively easy to add such events in. The actual code in app_confbridge
is minimal and hopefully clear enough.
 
> It also look like there is not equivalent of T (talker detection)
> option too. And I guess talker optimization is also missing. And
> unlike the MeetmeJoin like events I do not see how these can be
> implemented - it takes someone with good knowledge of the new bridging
> API architecture to implement it.

I disagree here that this should be done in the bridging API. The bridging API
is meant to be a low level API that does bridging and provides low level features
to implement higher level features.

For example it provides a low level API for DTMF that allows a developer to associate
a DTMF string with a callback function in their own code. What that actually does is up
to them.

In the case of talker detection I would want to see this done using a manipulate audiohook.
Audiohooks already provide a way for a developer to get access to the audio stream of a
channel and it only makes sense to use that for talker detection. By attaching a manipulate
audiohook app_confbridge can get a signed linear frame that can be passed through a DSP
almost immediately and a decision made about what to do with it. The simple mute bit can be
toggled off/on in the bridged channel features structure.

I really want to keep the bridging API from becoming a monster that provides things that can
already be done using other methods that we already have. A user of the bridging API doesn't
have to confine themselves to just using that which is provided by it.

> So even if ConfBridge is a better thing from architectural/design
> standpoint it is just a bare bones application at the moment. Not so
> many of us will be able to use it.

This is entirely true but it is my hopes that even a new developer can come along and help
to bring app_confbridge to a more feature rich state.

-- 
Joshua Colp
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org