[asterisk-dev] Introducing the new ConfBridge
Kevin P. Fleming
kpfleming at digium.com
Wed Feb 23 14:59:42 CST 2011
On 02/23/2011 02:04 PM, David Vossel wrote:
> Over the next couple of weeks I will be working on a new feature set for ConfBridge. In order to accomplish some of the features I have planned, a new configuration method for ConfBridge will be necessary. This new configuration method is what I am bringing to you all today. Before I get started on implementation I want to tell you all what I have planned and open the floor for feedback.
> At the moment ConfBridge's configuration is centralized entirely in the dialplan. The new configuration method will be a combination of a new confbridge.conf file and a new ConfBridge application syntax that takes advantage of the options declared in that config file. This will result in a ConfBridge application that is much more powerful than the current application, but not backwards compatible with the ConfBridge syntax used in 1.8. The lack of backwards compatibility with the previous syntax is unfortunate but necessary to achieve the new functionality we have planned.
> --- ConfBridge Configuration Concepts
> Bridge Profiles - Contains options such as mixing interval, internal sample rate, and other bridge specific options.
> User Profiles - Contains options such as conference pins, marked user, noise gate filters, volume control, and other user specific options.
> Menus - Custom mappings of DTMF sequences to conference actions. This allows for different menus to be assigned to each individual user depending on their permissions.
> --- ConfBridge Dialpan Syntax
> The ConfBridge dialplan application now uses these three configuration concepts, bridge profiles, user profiles, and menus as arguments. The new syntax will look like this ConfBridge([confno][,bridge profile[,user profile[,menu]]]). The only required argument to ConfBridge is the confno. In the case of when no user or bridge profiles are provided, the options declared in the [general] section of confbridge.conf will be used.
> --- Sample Configuration exercising these concepts.
> ; The general section is used to build the default bridge and user profile. Both bridge
> ; and user options can be declared here under this section. When ConfBridge is called without
> ; any bridge or user profile arguments, the options in this section are exercised.
> mix_sample_rate=dynamic ;adjust to best quality sample rate for the channels joined.
> denoise=yes ; denoise every channel that joins the bridge
> ; Custom Bridge profiles can be made. These options take precedence over the general section when
> ; this profile is used.
> mix_sample_rate=32khz ;fixed 32khz internal sample rate for mixing.
> ; Custom user profile can be made as well. All users who join
> ; with this profile will be muted by default.
> ; Custom Menus are created by mapping DTMF sequences to ConfBridge
> ; actions. This is a custom menu for the silent users so they can
> ; adjust their listening volume.
> ; Any number of user profiles can be created and applied to a
> ; single bridge. Channels joining the bridge with this
> ; user profile will be asked for a pin and be marked as
> ; a moderator.
> ; This menu is not that useful and is just for example purposes.
> ; It shows how more complex menu structures can be created.
> '*'=playback_continue(conf-menu) ;play a prompt while continuing to gather DTMF sequence
> '*3'=toggle_deaf, toggle_mute ;notice multiple actions can be associated with a single DTMF sequence
> '*5'=playback_continue(conf-menu2) ;play another prompt while collecting more of the DTMF sequence
> --- Using the sample configuration in the dialplan with the ConfBridge app.
> ; users who can only listen to the conference call this extension
> exten => muted_listener,1,Answer()
> exten => muted_listener,n,ConfBridge(1111, custom_bridge, silent_user, silent_menu)
> ;Moderators call this extension but have to put in a pin because they are a moderator_user.
> exten => moderator,1,Answer()
> exten => moderator,n,Conf(1111, custom_bridge, moderator_user, moderator_menu)
> I look forward to any feedback you have to offer on this new configuration method!
I would like to suggest that you *not* allow setting of bridge and user
profile parameters in the [general] section, but instead only allow
specification of the *default* bridge and user profiles (by name) that
should be used if none is specified when the application is invoked.
We already have many confusing examples of the same options existing in
both the general section and in specific categories and users not being
able to know for sure which settings will be used.
For example, in the sample you included above, does the 'denoise=yes'
from [general] apply when I specify [custom_bridge], or does the fact
that [custom_bridge] doesn't specify 'denoise' at all mean it defaults
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org
More information about the asterisk-dev