[asterisk-dev] Introducing the new ConfBridge

[Tony Mountifield]

In article <1561053615.95365.1298491443721.JavaMail.root at zimbra>,
David Vossel <dvossel at digium.com> wrote:
> Howdy,
> 
> 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.

Seeing the latest commit for the max_members option, made me think about
this approach a bit more.

> URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=310880
> Log:
> Addes max_members option to ConfBridge bridge profiles
> +;max_members=50                ; This option limits the number of participants for a single
> +                               ; conference to a specific number.  By default conferences
> +                               ; have no participant limit. After the limit is reached, the
> +                               ; conference will be locked until someone leaves.  Note however
> +                               ; that an Admin user will always be alowed to join the conference
> +                               ; regardless if this limit is reached or not.
> +

This is the kind of option for which the ability to dynamically set it
at run time would be very useful. Having to have a profile for every
possible desired value would obviously be very cumbersome.

Similarly for some of the other options - wait for leader, recording,
identify participants, etc. My application currently sets channel
variables to control each of these options, which are then referred to
in the Meetme command in the dialplan. Again, the more different
options that need to be independently settable, the more profiles
would need to be defined, one for each combination.

So, what could be a better way of making all the different profile items
settable independently at runtime? Some kind of syntax to say take the
value from a channel variable? Reinstate dialplan options for some features?

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org