[Asterisk-code-review] ConfBridge: Rework announcer channel methodology (asterisk[13])

[Mark Michelson]

Hello Richard Mudgett, Anonymous Coward #1000019,

I'd like you to reexamine a change.  Please visit

    https://gerrit.asterisk.org/3504

to look at the new patch set (#2).

Change subject: ConfBridge: Rework announcer channel methodology
......................................................................

ConfBridge: Rework announcer channel methodology

One feature that confbridge has is the ability to play sounds to all
participants in the conference. Prior to this commit, the algorithm for
this was as follows:

* Grab the playback lock
* Push the conference announcer channel into the bridge
* Play back the sound
* Pull the conference announcer channel from the bridge
* Release the playback lock

The issue here is that the act of adding the playback channel to the
bridge and removing it for each announcement is expensive. Amongst the
expenses:

* The announcer channel is imparted into the bridge, meaning a new
  thread is spun up for each playback.
* When the announcer is added or removed from the bridge, it results
  in the BRIDGEPEER channel variable being set on all channels in the
  bridge. This requires keeping the bridge locked and locking each
  individual channel in order to set it.
* There's also just the general overhead of adding the channel and
  removing it from the bridge. The bridge potentially has to reconfigure
  every single time

With this commit, the paradigm for playing back announcements has
shifted.

* The announcer channel is now added to the bridge when the conference
  is allocated, and it is hung up when the conference is destroyed.
* A taskprocessor is used to queue playbacks onto the announcer channel.
  This keeps the behavior from before where playbacks do not overlap.
* The announcer channel is no longer placed into the bridge as
  departable. Since we are not constantly removing the channel from
  the bridge, it is safe to add the channel using an independent thread
  and simply hang the channel up when it is time for the conference to
  be destroyed.

The use of the taskprocessor for playbacks opens up the interesting
possibility of having asynchronous announcements played. In this commit,
however, the behavior is still exactly the same as it previously was.

ASTERISK-26289
Reported by Mark Michelson

Change-Id: Ic5cd2c4b98a1eaa1715eb7a5b35d62f1a76d78a5

ConfBridge: Make some announcements asynchronous.

Confbridge announcements tend to block a channel while they are being
played. In some circumstances, this is warranted since you want that
particular channel not to hear the announcement (Example: "John Doe has
entered the conference"). For others it makes less sense.

This change first introduces methods for playing sounds asynchronously
into the conference. This is very similar to how synchronous sounds are
played, except the channel initiating the playback does not wait for the
sound to complete before moving on.

Asynchronous announcements are used for two circumstances:
* Sounds played for a user after they have left the bridge
* Sounds that play first to a single user and then the rest of the
  conference (if the channel and conference use the same language)

ASTERISK-26289 #close
Reported by Mark Michelson

Change-Id: Ie486bb3de1646d50894489030326a423e594ab0a
---
M CHANGES
M apps/app_confbridge.c
M apps/confbridge/conf_chan_announce.c
M apps/confbridge/conf_state_multi_marked.c
M apps/confbridge/include/confbridge.h
5 files changed, 409 insertions(+), 118 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/04/3504/2
-- 
To view, visit https://gerrit.asterisk.org/3504
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Ie486bb3de1646d50894489030326a423e594ab0a
Gerrit-PatchSet: 2
Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-Owner: Mark Michelson <mmichelson at digium.com>
Gerrit-Reviewer: Anonymous Coward #1000019
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>