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

[Joshua Colp (JIRA)]

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

Joshua Colp updated ASTERISK-21271:
-----------------------------------

    Affects Version/s: 13.18.4

> 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, 13.18.4
>            Reporter: Matt Jordan
>            Severity: Minor
>              Labels: Asterisk12
>
> 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}} s in the code:
> * 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.
> {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}
> * This should also include role understanding where appropriate in softmix. Ideally, roles would be part of the subclass.
> {noformat}
> /home/mjordan/projects/trunk/bridges/bridge_softmix.c:
>   595  static int softmix_bridge_write_control(struct ast_bridge *bridge, struct ast_bridge_channel *bridge_channel, struct ast_frame *frame)
>   596  {
>   597: /* BUGBUG need to look at channel roles to determine what to do with control frame. */
>   598: 	/*! \todo BUGBUG softmix_bridge_write_control() not written */
>   599  	return 0;
>   600  }
> {noformat}
> * Remove external suspends. The bridging core itself should handle suspending/unsuspending the channels.
> {noformat}
> /home/mjordan/projects/trunk/include/asterisk/bridging.h:
>   131   */
>   132  struct ast_bridge_channel {
>   133: /* BUGBUG cond is only here because of external party suspend/unsuspend support. */
>   134  	/*! Condition, used if we want to wake up a thread waiting on the bridged channel */
>   135  	ast_cond_t cond;
>   ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)