Summary:	ASTERISK-21059: Bridge API Enhancements - Refactor the Park family of applications
Reporter:	Matt Jordan (mjordan)	Labels:	Asterisk12
Date Opened:	2013-02-08 16:07:54.000-0600	Date Closed:	2013-06-06 11:59:29
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/Bridging Features/Parking
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	As part of the [API work|https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+API+Improvements], the model for bridging used within Asterisk is undergoing some major rework. In particular, all bridging in Asterisk will use the existing Bridging API, added by Joshua Colp since 1.6. Please see the [Bridge Construction|http://svn.asterisk.org/svn/asterisk/team/group/bridge_construction/] Team project for the current status of this work. Now it gets fun! Since all bridges are now managed by the API, an obvious impact is that the previous model of sticking channels in loops that handle frames isn't going to always work as well anymore. Particularly when you want to avoid masquerades completely. A first candidate for this refactoring is Park! * Parking should be a bridging technology. The bridge technology should have some number of channels, each in it's own independent mini-mixer that pipes MoH to it. ** The bridge technology should manage channels in parking slots. ** Each instance of the bridging technology should probably correspond to a parking lot. (The mapping of parking slots/lots to bridging technology is a design decision that should be based off of the number of channels a single thread can service. Since the current implementation uses a single thread, a single technology instance may suffice) * The parking applications/actions should be refactored to use the bridging API with the new technology. * Moving a channel in and out of the parking lot should be accomplished using the bridging APIs (including transfers). As part of this, it may be beneficial to define a new configuration schema for call parking. If so, it should be backwards compatible with the existing schema in features.conf. Note that whether or not these applications continue to exist in features.c is up to the implementer. These features may live better in a resource module, assuming the dependencies between other applications and parking is not extensive.
Comments:	By: Matt Jordan (mjordan) 2013-02-13 14:57:13.549-0600 The first effort on this should be to: # Define roles and responsibilities between the bridging layer and the application layer. The bridging technology should, in general, not be terribly aware of the concept of 'parking' but instead should be able to handle the mixing of media for channels who are parked. ## Requirements for the bridge are (hereafter called the 'waiting' bridge): ### Be able to have _n_ 'normal' channels placed in the bridge. Normal Channels should not be able to talk to each other, but can hear. ### Have a 'player' channel be able to join the bridge. A player channel should be able to send media to normal channels, but should not be able to hear them. ### Allow a timed feature to be set on normal channels that ejects them from the bridge after _n_ seconds. Such a feature should be set on a channel by channel basis. ### Allow a timed feature to play periodic messages on the normal channels. If a player channel is in the bridge, this should preempt the player channel. This should be enabled on a channel by channel basis. ## Requirements for the parking application: ### Organize parked channels into parking lots/slots. Each parking lot should correspond to an instance of the bridge. A parking slot is just the limit on the number of channels in the bridge. ### Parking should organize the player channels, features, and manipulation of the channels in/out of the bridge. This new set of bridging/applications can be implemented separately as new applications/functions, mimicking the existing functionality. When it is feature complete, the old parking mechanics can be removed and the applications renamed.