aboutsummaryrefslogtreecommitdiffstats
path: root/apps/app_channelredirect.c
AgeCommit message (Collapse)AuthorFilesLines
2009-01-28This patch fixes h-exten running misbehavior in manager-redirected murf1-0/+5
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.4@172030 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-21merge new_loader_completion branch, including (at least):kpfleming1-19/+7
- restructured build tree and makefiles to eliminate recursion problems - support for embedded modules - support for static builds - simpler cross-compilation support - simpler module/loader interface (no exported symbols) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@40722 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-07simplify autoconfig include mechanism (make tholo happy he can use lint ↵kpfleming1-4/+4
again :-) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@32846 f38db490-d61c-443f-a65b-d21fe96a405b
2006-05-16make this app actually compilekpfleming1-0/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@27478 f38db490-d61c-443f-a65b-d21fe96a405b
2006-05-16Adding check of option_debugoej1-1/+2
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@27436 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-14This rather large commit changes the way modules are loaded. rizzo1-13/+7
As partly documented in loader.c and include/asterisk/module.h, modules are now expected to return all of their methods and flags into a structure 'mod_data', and are normally loaded with RTLD_NOW | RTLD_LOCAL, so symbols are resolved immediately and conflicts should be less likely. Only in a small number of cases (res_*, typically) modules are loaded RTLD_GLOBAL, so they can export symbols. The core of the change is only the two files loader.c and include/asterisk/module.h, all the rest is simply adaptation of the existing modules to the new API, a rather mechanical (but believe me, time and finger-consuming!) process whose detail you can figure out by svn diff'ing any single module. Expect some minor compilation issue after this change, please report it on mantis http://bugs.digium.com/view.php?id=6968 so we collect all the feedback in one place. I am just sorry that this change missed SVN version number 20000! git-svn-id: http://svn.digium.com/svn/asterisk/trunk@20003 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-11normalize code preparing for loader changesrizzo1-3/+2
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@19220 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-08since the module API is changing, it's a good time to const-ify the ↵kpfleming1-2/+2
description() and key() return values git-svn-id: http://svn.digium.com/svn/asterisk/trunk@18552 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-05Bug 6508 - if priority was a number, then findlabel failstilghman1-4/+5
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@17626 f38db490-d61c-443f-a65b-d21fe96a405b
2006-03-28remove the long since unused STANDARD_LOCAL_USERS macrorizzo1-2/+0
so that new apps will not try to use it by mistake. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@15517 f38db490-d61c-443f-a65b-d21fe96a405b
2006-03-26rename file to match new application namekpfleming1-0/+158
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@15067 f38db490-d61c-443f-a65b-d21fe96a405b