[Home]

Summary:ASTERISK-23780: Failing to join a bridge could leave the bridge orphaned.
Reporter:Richard Mudgett (rmudgett)Labels:
Date Opened:2014-05-22 18:05:42Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Applications/app_bridgewait Core/Bridging
Versions:SVN 12.2.0 13.18.4 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:A typical two party bridge gets the participants into it by using {{ast_bridge_impart()}} for the peer channel and {{ast_bridge_join(AST_BRIDGE_JOIN_PASS_REFERENCE)}} for the calling channel as in {{ast_bridge_call_with_flags()}}.  Unfortunately, if the channels fail to join the bridge for some reason (e.g., The channel hangs up before joining.) then the bridge could get orphaned and never destroyed.  The caller of {{ast_bridge_join(AST_BRIDGE_JOIN_PASS_REFERENCE)}} cannot correct this because it *intentionally* no longer has a bridge reference.

Proposed solution:
* Make {{ast_bridge_join()}} and {{ast_bridge_impart()}} do the {{bridge_channel_dissolve_check()}} as if the channel had just left the bridge.
* Any hooks that are marked {{AST_BRIDGE_HOOK_REMOVE_ON_PULL}} should be removed as if the channel was pulled out of the bridge.  Currently only one bridge join failure path removes the hooks causing an inconsistent return state.  This may need to be the other way around and not remove these hooks if joining fails.

The {{BridgeWait}} application needs to be fixed up if the channel fails to join the bridge in {{bridgewait_exec()}} because the interval hook may not be there if/when the channel fails to join the bridge.  Also {{BridgeWait}} looks to get in an infinite loop if the channel hangs up or becomes a ZOMBIE while {{BridgeWait}} is trying to put it into the holding bridge.
Comments: