[asterisk-dev] app_confbridge

[Tony Mountifield]

In article <20080311094540.8a7a5460 at neutrino.file-radio.com>,
Joshua Colp <jcolp at digium.com> wrote:
> ----- Original Message -----
> From: Tony Mountifield
> [mailto:tony at softins.clara.co.uk]
> To: asterisk-dev at lists.digium.com
> Sent: Tue, 11 Mar 2008 06:15:59 -0400
> Subject: [asterisk-dev] app_confbridge
> 
> > I've been interested to see the recent activity in svn.commits concerning
> > team/file/bridging/apps/app_confbridge.c
> 
> It's good to know that someone has been peeking at it :)
>  
> > It looks like this ConfBridge is intended to replace MeetMe in the future.
> > Is that correct?
> 
> Correct. It's one of the uses of the new bridging API, and will be the first step. 
>  
> > Will it be introduced in Asterisk 1.6.x, or not until 1.8?
> 
> It will be introduced in a future Asterisk 1.6 version.
>  
> > The reason I'm asking is because a lot of my work is with customisations
> > to Meetme, and I won't want to do any new major additions if it is going
> > to be replaced by a cleaner archirecture sometime soon.
> 
> What sort of customizations have you done? Will they easily fit into the current
> architecture of app_confbridge?

Well, I haven't looked at the architecture of app_confbridge yet - just
noticed with interest the SVN updates. All my work as been on V1.2; I
haven't yet moved on to 1.4 or 1.6, since Meetme had a lot of changes
(SLA stuff etc).

Some of my customisations were specific to customers' needs, and some
things I've done have subsequently been implemented in 1.4 or trunk in
a different way. But here are the main ones:

- Outbound dialling (option 'o'): DTMF '9' gives a dialtone and waits
for a number to be dialled, matching it against extensions in the context
${MEETME_OUTBOUNDCONTEXT}. When it has the number, makes a call to
Local/<exten>@${MEETME_OUTBOUNDCONTEXT} with audible call progress, and
bridges on answer. Caller can press '#' or '*' to return to the conference;
'#' hangs up the called party, '*' sends the called party (provided it was
answered) into the dialplan using async_goto to the context^exten^pri stored
in MEETME_INVITE_GOTO. CDRs and Manager Dial events are created properly,
includeing MeetmeHold when the user presses 9 and MeetmeUnhold when the
user returns to the conference. The reason for using this approach rather
than just using X option to drop out to the dialplan for dialling and then
re-invoking Meetme was because that doesn't work well with the 'i' option.

- MeetmeAdmin 'V' (verify) command tells all participants individually to
press a key to return to the conference. Useful to get rid of answering
machines and IVRs after a blast-dial to several parties.

- Playing sounds and files into a conference uses a background thread
(this was submitted to Mantis ages ago and rejected - I still think
it's the correct way to do it).

- Option to announce to users when a conference is being recorded

- Option to pause recording during periods of silence, using talkdetect

- Option to delay recording until a second party is present

- Menu option *5 to pause/unpause recording (admin menu only)

- Manager API to mute and unmute users, with optional announcement to user

- Manager events to report mute, unmute, recording start/pause/resume/stop.

- MeetmeAdmin x and X commands (exit) like "kick" but without the offensive
"kicked" announcement.

- Re-coded the enter and leave sounds in slin, so that the pseudo channels
could always be in SLINEAR mode instead of starting in ULAW.

- Menu option *0 for roll-call of users names (recorded using 'i' option)

- Menu option ** to play "system operator requested" and generate a
manager event.

- When using 'i' option, include Namefile entry in the MeetmeJoin Manager
event, so a control program can stream the namefile on demand (useful for
a control screen operator to identify callers).

- Re-ordered the DTMF logic within conf_run()

- Re-ordered some of the prologue in conf_run (testing of option flags, etc)

- Option to wait until second persion joins before cancelling indications
(e.g. ringing tone). Optional timeout on this, with exit on timeout.

- Store uniqueID of creating channel in the conf struct, and return this
in MEETMEUNIQUEID for all participating channels. Also include this in
manager MeetmeJoin and MeetmeLeave events as MeetmeID.

A lot of the above haven't been submitted to Mantis purely because I have
not had time to update them from 1.2 to trunk (let alone to 1.4 even).

Things that I want to work on, but haven't had time to yet:

- Storing the menu structures in a config file. See my post with initial
ideas at http://lists.digium.com/pipermail/asterisk-dev/2007-December/030982.html

- Transparent spanning of conferences between boxes, where the meetme
on each box would advertise the conferences it has running, and would
send the audio for each conference that exists on another box to that box.
The receiving box would inject the received audio into the conference.
Other info that would have to be shared would be admin user counts (for 'w'
option), recording status, mute/unmute all commands, kick/exit all commands,
and probably others. Each conference would need to be in a star configuration
around the first box to create it (master), to avoid audio travelling round
in circles! There may be better approaches, which I would be interested to
hear about.

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