aboutsummaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authormurf <murf@f38db490-d61c-443f-a65b-d21fe96a405b>2009-01-28 20:56:48 +0000
committermurf <murf@f38db490-d61c-443f-a65b-d21fe96a405b>2009-01-28 20:56:48 +0000
commita133d997d849e3a1023033b726737b1785e66afc (patch)
treef86df98e2a2e154de5f8dc107826e9c267c02f4f /include
parent4fa796a06ccfb35e73e387414fb3ca53557acf15 (diff)
Merged revisions 172063 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk ................ r172063 | murf | 2009-01-28 13:31:06 -0700 (Wed, 28 Jan 2009) | 52 lines Merged revisions 172030 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r172030 | murf | 2009-01-28 11:51:16 -0700 (Wed, 28 Jan 2009) | 46 lines This patch fixes h-exten running misbehavior in manager-redirected situations. What it does: 1. A new Flag value is defined in include/asterisk/channel.h, AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the bridge hangup exten code not to run the h-exten there (nor publish the bridge cdr there). It will done at the pbx-loop level instead. 2. In the manager Redirect code, I set this flag on the channel if the channel has a non-null pbx pointer. I did the same for the second (chan2) channel, which gets run if name2 is set... and the first succeeds. 3. I restored the ending of the cdr for the pbx loop h-exten running code. Don't know why it was removed in the first place. 4. The first attempt at the fix for this bug was to place code directly in the async_goto routine, which was called from a large number of places, and could affect a large number of cases, so I tested that fix against a fair number of transfer scenarios, both with and without the patch. In the process, I saw that putting the fix in async_goto seemed not to affect any of the blind or attended scenarios, but still, I was was highly concerned that some other scenarios I had not tested might be negatively impacted, so I refined the patch to its current scope, and jmls tested both. In the process, tho, I saw that blind xfers in one situation, when the one-touch blind-xfer feature is used by the peer, we got strange h-exten behavior. So, I inserted code to swap CDRs and to set the HANGUP_DONT field, to get uniform behavior. 5. I added code to the bridge to obey the HANGUP_DONT flag, skipping both publishing the bridge CDR, and running the h-exten; they will be done at the pbx-loop (higher) level instead. 6. I removed all the debug logs from the patch before committing. 7. I moved the AUTOLOOP set/reset in the h-exten code in res_features so it's only done if the h-exten is going to be run. A very minor performance improvement, but technically correct. (closes issue #14241) Reported by: jmls Patches: 14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf (license 17) Tested by: murf, jmls ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@172067 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'include')
-rw-r--r--include/asterisk/channel.h4
1 files changed, 4 insertions, 0 deletions
diff --git a/include/asterisk/channel.h b/include/asterisk/channel.h
index ff8521c00..357bc34e3 100644
--- a/include/asterisk/channel.h
+++ b/include/asterisk/channel.h
@@ -556,6 +556,10 @@ enum {
* a message aimed at preventing a subsequent hangup exten being run at the pbx_run
* level */
AST_FLAG_BRIDGE_HANGUP_RUN = (1 << 17),
+ /*! This flag indicates that the hangup exten should NOT be run when the
+ * bridge terminates, this will allow the hangup in the pbx loop to be run instead.
+ * */
+ AST_FLAG_BRIDGE_HANGUP_DONT = (1 << 17),
};
/*! \brief ast_bridge_config flags */