[Home]

Summary:ASTERISK-21051: Bridge API Enhancements: Refactor callers of ast_bridge_call to use Bridging API model
Reporter:Matt Jordan (mjordan)Labels:Asterisk12
Date Opened:2013-02-08 09:37:44.000-0600Date Closed:2013-02-18 14:07:58.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/Bridging
Versions:12 Frequency of
Occurrence
Related
Issues:
must be completed before resolvingASTERISK-21052 Bridge API Enhancements: Implement threading model for bridge management thread
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.

{{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 tasks are needed:
# 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.
# Allow a bridge object to be destroyed when no objects reference the bridge any longer. An explicit call to ast_bridge_destroy() should not be needed.
Comments: