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

[dimas at dataart.com]

Joshua,
Don't get me wrong - I did not say that any talker detection, optimization needs to be done in bridging core :) I totally agree with you about that.

What I tried to say is that someone who clearly understands bridging API and design of ConfBridge needs to give us some starting point by creating a code which can process and manipulate media streams there. From what you say looks like that bridging API knowledge is not required for this operation at all and it is all about audiohooks. Cool. However to me it is still good idea that original author of ConfBridge (you, right?) or someone under his supervision provided some basic stub for media processing so then other can extend it with:
* Talked detection
* Auto Gain control
* Talker optimization (strange name btw - from what I saw in the code it is just cutting off voice which is lower than threshold).

I could definitely participate myself but still need where to start :)

Regards,
Dmitry Andrianov


-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Joshua Colp
Sent: Monday, December 07, 2009 6:18 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] app_meetme call for testing: Roll call, eject all, mute all, record in-conf

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

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev