[asterisk-bugs] [JIRA] (ASTERISK-21059) Bridge API Enhancements - Refactor the Park family of applications

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-21059:
-----------------------------------

    Status: Open  (was: Triage)
    
> Bridge API Enhancements - Refactor the Park family of applications
> ------------------------------------------------------------------
>
>                 Key: ASTERISK-21059
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21059
>             Project: Asterisk
>          Issue Type: Improvement
>          Components: Core/Bridging, Features/Parking
>            Reporter: Matt Jordan
>      Target Release: 12
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira