[asterisk-bugs] [JIRA] (ASTERISK-21054) Bridge API Enhancements: Add roles to the bridging model

[Matt Jordan (JIRA)]

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

Work on ASTERISK-21054 started by Jonathan Rose.

> Bridge API Enhancements: Add roles to the bridging model
> --------------------------------------------------------
>
>                 Key: ASTERISK-21054
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21054
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Core/Bridging
>    Affects Versions: 12
>            Reporter: Matt Jordan
>            Assignee: Jonathan Rose
>              Labels: Asterisk12
>
> 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.
> Add control frame support/processing to the appropriate bridging technologies and the API. This will require roles to be added to bridging technologies so that concepts such as Hold can be implemented properly. Initially, we should add support for the following roles:
> * Caller - Only significant in early media bridge. The caller flag can also be used for COLP interception macros.  Attended transfers would need to manipulate the caller roll flag for proper rolls. In such as case, Party A is always the caller roll and Party C is the callee roll.
> * Callee/Peer - Normal bridges exchange control frames when only two channels are marked as peers. Early media bridge technologies also look at the Caller flag for control frame exchanges. Other bridges will use the concept of peer to restrict what control a channel may have on a bridge and/or to prevent control frame swapping.
> *NOTE*: It is up to the appropriate applications to ensure that channels entering a bridge object have the correct flags. In general, switching bridge technologies (going from two-party to multi-party) will have to be careful about role flags, as the roles may change. 
> In addition, this task will need to:
> * Add AST_CONTROL_SRCUPDATE generation on 1-1 bridging.
> * Update the softmix bridging technology/ConfBridge to make channels with the correct roles (peer)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira