[asterisk-bugs] [JIRA] (ASTERISK-21051) Bridge Construction: Refactor callers of ast_bridge_call to use Bridging API model

[Matt Jordan (JIRA)]

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

Matt Jordan updated ASTERISK-21051:
-----------------------------------

    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.

{{ast_bridge_call}} has already been refactored to use the Bridging API. However, because multiple channels can be in a single bridge, the concept of a 'bridge peer' no longer applies. This task is to refactor {{ast_bridge_call}} callers to not expect getting peer back. Entities wishing to get the participants in a bridge should expect to get back an {{ao2_container}} or some other iterable objects from an API call.

One other piece of work that must occur under this task is to add an optional goto dialplan location datastore to set where
the peer should go when it exits the bridge.  The location datastore is
removed if a channel exits with {{AST_SOFTHANGUP_ASYNCGOTO}} set or the
channel is masqueraded.


  was:
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.

{{ast_bridge_call}} has already been refactored to use the Bridging API. However, because multiple channels can be in a single bridge, the concept of a 'bridge peer' no longer applies. This task is to refactor {{ast_bridge_call}} callers to not expect getting peer back. Entities wishing to get the participants in a bridge should expect to get back an {{ao2_container}} or some other iterable objects from an API call.

Two other pieces of work must occur under this task:

# Add an optional goto dialplan location datastore to set where
the peer should go when it exits the bridge.  The location datastore is
removed if a channel exits with {{AST_SOFTHANGUP_ASYNCGOTO}} set or the
channel is masqueraded.
# Implement the self managing bridge functionality. A self managing bridge has a central bridge thread that manages adding/removing channels and merging bridges. This allows bridge technologies to switch between two-party and multi-party technologies, merge bridges, etc.

    
> Bridge Construction: Refactor callers of ast_bridge_call to use Bridging API model
> ----------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21051
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21051
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Core/Bridging
>    Affects Versions: 12
>            Reporter: Matt Jordan
>
> 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.
> {{ast_bridge_call}} has already been refactored to use the Bridging API. However, because multiple channels can be in a single bridge, the concept of a 'bridge peer' no longer applies. This task is to refactor {{ast_bridge_call}} callers to not expect getting peer back. Entities wishing to get the participants in a bridge should expect to get back an {{ao2_container}} or some other iterable objects from an API call.
> One other piece of work that must occur under this task is to add an optional goto dialplan location datastore to set where
> the peer should go when it exits the bridge.  The location datastore is
> removed if a channel exits with {{AST_SOFTHANGUP_ASYNCGOTO}} set or the
> channel is masqueraded.

--
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