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

@@ -6310,6 +6310,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;