bridges/bridge_native_rtp: Reconfigure bridge on removal of framehook

This patch is a re-do of r414122.

When r414122 was merged, a major problem with it was uncovered. UNBRIDGE soft
hangup flags have a catastrophic effect on the pbx core if they leak out from
the bridge layer: the channel gets hung up. With the number of threads
involved in a blind transfer, and with the initial patch, it was likely that
this would occur. This caused a large number of test failures

This patch is nearly identical with the one proposed in r414122, save for the
following changes:
 - We explicitly clear the UNBRIDGE flag when setting an after goto on a
   channel in a bridge
 - Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it

https://reviewboard.asterisk.org/r/3585/



git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@415443 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
Matthew Jordan
2014-06-08 18:11:54 +00:00
parent 7cccdb70d4
commit c87dbe9922
7 changed files with 54 additions and 7 deletions

View File

@@ -1757,8 +1757,8 @@ void bridge_channel_internal_pull(struct ast_bridge_channel *bridge_channel)
* outgoing channel, clear the outgoing flag.
*/
if (ast_test_flag(ast_channel_flags(bridge_channel->chan), AST_FLAG_OUTGOING)
&& (ast_channel_softhangup_internal_flag(bridge_channel->chan) & (AST_SOFTHANGUP_ASYNCGOTO | AST_SOFTHANGUP_UNBRIDGE)
|| bridge_channel->state == BRIDGE_CHANNEL_STATE_WAIT)) {
&& (ast_channel_is_leaving_bridge(bridge_channel->chan)
|| bridge_channel->state == BRIDGE_CHANNEL_STATE_WAIT)) {
ast_debug(2, "Channel %s will survive this bridge; clearing outgoing (dialed) flag\n", ast_channel_name(bridge_channel->chan));
ast_clear_flag(ast_channel_flags(bridge_channel->chan), AST_FLAG_OUTGOING);
}