[asterisk-bugs] [JIRA] (ASTERISK-21271) Bridge API Enhancements - subclass ConfBridge with its own Virtual Method table

[Matt Jordan (JIRA)]

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

Matt Jordan updated ASTERISK-21271:
-----------------------------------

    Description: 
Once bridges have the ability to be subclassed, ConfBridge needs to be refactored to properly handle bridge join/leave/merge operations.

This prevents needing to masquerade channels into/out of ConfBridge, and effectively makes it a full participant in bridge interactions.

*NOTES:*

The initial foray into this work by Richard revealed this to be much larger of a task than initially thought. The primary issues revolve around two major concerns:
# The ConfBridge state machine exists outside of the bridging core. As such, a ConfBridge can change state in 'unsafe' ways when full sub-classed. For the sub-classing to work, the ConfBridge state machine will probably require significant work.
# The act of suspending/unsuspending channels from an external source is unsafe when the bridging core may choose to nuke the bridge out from underneath it. This occurs during smart bridge operations. ConfBridge should, instead, ask the bridging core to play media on a channel. This would allow the bridging core to know the state of the channel such that, if a smart bridge operation occurs, it can safely unsuspend the channel.

This work would also resolve the following {{BUGBUG}} in the code:

{noformat}
/home/mjordan/projects/trunk/apps/confbridge/conf_config_parser.c:
 1923  	aco_option_register_custom(&cfg_info, "template", ACO_EXACT, user_types, NULL, user_template_handler, 0);
 1924
 1925: /* BUGBUG need a user supplied bridge merge_priority to merge ConfBridges (default = 1, range 1-INT_MAX) */
 1926  	/* Bridge options */
 1927  	aco_option_register(&cfg_info, "type", ACO_EXACT, bridge_types, NULL, OPT_NOOP_T, 0, 0);
{noformat}

The issue there is that a bridge merge priority could be supplied through configuration to control how two ConfBridges are merged together when connected by an optimizing Local channel.

  was:
Once bridges have the ability to be subclassed, ConfBridge needs to be refactored to properly handle bridge join/leave/merge operations.

This prevents needing to masquerade channels into/out of ConfBridge, and effectively makes it a full participant in bridge interactions.


    
> Bridge API Enhancements - subclass ConfBridge with its own Virtual Method table
> -------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21271
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21271
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: Applications/app_confbridge, Core/Bridging
>    Affects Versions: 12
>            Reporter: Matt Jordan
>            Assignee: Richard Mudgett
>              Labels: Asterisk12
>      Target Release: 12
>
>
> Once bridges have the ability to be subclassed, ConfBridge needs to be refactored to properly handle bridge join/leave/merge operations.
> This prevents needing to masquerade channels into/out of ConfBridge, and effectively makes it a full participant in bridge interactions.
> *NOTES:*
> The initial foray into this work by Richard revealed this to be much larger of a task than initially thought. The primary issues revolve around two major concerns:
> # The ConfBridge state machine exists outside of the bridging core. As such, a ConfBridge can change state in 'unsafe' ways when full sub-classed. For the sub-classing to work, the ConfBridge state machine will probably require significant work.
> # The act of suspending/unsuspending channels from an external source is unsafe when the bridging core may choose to nuke the bridge out from underneath it. This occurs during smart bridge operations. ConfBridge should, instead, ask the bridging core to play media on a channel. This would allow the bridging core to know the state of the channel such that, if a smart bridge operation occurs, it can safely unsuspend the channel.
> This work would also resolve the following {{BUGBUG}} in the code:
> {noformat}
> /home/mjordan/projects/trunk/apps/confbridge/conf_config_parser.c:
>  1923  	aco_option_register_custom(&cfg_info, "template", ACO_EXACT, user_types, NULL, user_template_handler, 0);
>  1924
>  1925: /* BUGBUG need a user supplied bridge merge_priority to merge ConfBridges (default = 1, range 1-INT_MAX) */
>  1926  	/* Bridge options */
>  1927  	aco_option_register(&cfg_info, "type", ACO_EXACT, bridge_types, NULL, OPT_NOOP_T, 0, 0);
> {noformat}
> The issue there is that a bridge merge priority could be supplied through configuration to control how two ConfBridges are merged together when connected by an optimizing Local channel.

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