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

Merged revisions 415443 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415444 65c4cc65-6c06-0410-ace0-fbb531ad65f3

1 files changed, 6 insertions, 0 deletions

diff --git a/main/pbx.c b/main/pbx.c
index 2d9e15b08..ba985199f 100644
--- a/main/pbx.c
+++ b/main/pbx.c
@@ -6323,6 +6323,12 @@ static enum ast_pbx_result __ast_pbx_run(struct ast_channel *c,
 		while (!(res = ast_spawn_extension(c, ast_channel_context(c), ast_channel_exten(c), ast_channel_priority(c),
 			S_COR(ast_channel_caller(c)->id.number.valid, ast_channel_caller(c)->id.number.str, NULL),
 			&found, 1))) {
+
+			/* Defensively clear the UNBRIDGE flag in case it leaked
+			 * out of the bridging framework. UNBRIDE never implies
+			 * that a channel is hung up.
+			 */
+			ast_channel_clear_softhangup(c, AST_SOFTHANGUP_UNBRIDGE);
 			if (!ast_check_hangup(c)) {
 				ast_channel_priority_set(c, ast_channel_priority(c) + 1);
 				continue;