[asterisk-bugs] [JIRA] (ASTERISK-21271) Bridge API Enhancements - subclass ConfBridge with its own Virtual Method table
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Thu Jul 18 12:00:03 CDT 2013
[ 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}}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}
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.
*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.
> 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
> 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}}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 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
More information about the asterisk-bugs
mailing list