1857 Commits (c6837adabc5f7457bfe25ef4e2e187c9ee484792)

Author	SHA1	Message	Date
David Vossel	f94e5b2d7c	Merged revisions 180534 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r180534 | dvossel | 2009-03-06 11:26:38 -0600 (Fri, 06 Mar 2009) | 15 lines Merged revisions 180532 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r180532 | dvossel | 2009-03-06 11:19:55 -0600 (Fri, 06 Mar 2009) | 9 lines Fix handling of backreferences for ENUM lookups enum.c did not handle regex backtraces correctly. The '\1' in the regex is a backreference that requires a pattern match to be inserted. The way the code used to work is that it would find the backreference and insert the entire input string minus the '+'. This is incorrect. The regexec() function takes in a variable called pmatch which is an array of structs containing the start and end indexes for each backreference substring. The original code actually passed the pmatch array pointer into regexec but never did anything with it. Now when a backtrace is found, the backtrace number is looked up in the pmatch array and the correct substring is inserted. (closes issue #14576) Reported by: chris-mac Review: http://reviewboard.digium.com/r/187/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@180535 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Kevin P. Fleming	2a877c8fcb	Merged revisions 180373 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r180373 | kpfleming | 2009-03-05 12:29:38 -0600 (Thu, 05 Mar 2009) | 15 lines Merged revisions 180372 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r180372 | kpfleming | 2009-03-05 12:22:16 -0600 (Thu, 05 Mar 2009) | 9 lines Fix problems when RTP packet frame size is changed During some code analysis, I found that calling ast_rtp_codec_setpref() on an ast_rtp session does not work as expected; it does not adjust the smoother that may on the RTP session, in fact it summarily drops it, even if it has data in it, even if the current format's framing size has not changed. This is not good. This patch changes this behavior, so that if the packetization size for the current format changes, any existing smoother is safely updated to use the new size, and if no smoother was present, one is created. A new API call for smoothers, ast_smoother_reconfigure(), was required to implement these changes. Review: http://reviewboard.digium.com/r/184/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@180377 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Joshua Colp	75d0d2389e	Merged revisions 180195 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r180195 | file | 2009-03-04 15:24:59 -0400 (Wed, 04 Mar 2009) | 11 lines Merged revisions 180194 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r180194 | file | 2009-03-04 15:22:50 -0400 (Wed, 04 Mar 2009) | 4 lines Look for the number in a callerid string starting from the end. This way a value using <> can exist in the name portion. (issue #AST-194) ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@180196 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
David Vossel	9cad0b7e22	Merged revisions 180032 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r180032 | dvossel | 2009-03-03 17:21:18 -0600 (Tue, 03 Mar 2009) | 14 lines app_read does not break from prompt loop with user terminated empty string In app.c, ast_app_getdata is called to stream the prompts and receive DTMF input. If ast_app_getdata() receives an empty string caused by the user inputing the end of string character, in this case '#', it should break from the prompt loop and return to app_read, but instead it cycles through all the prompts. I've added a return value for this special case in ast_readstring() which uses an enum I've delcared in apps.h. This enum is now used as a return value for ast_app_getdata(). (closes issue #14279) Reported by: Marquis Patches: fix_app_read.patch uploaded by Marquis (license 32) read-ampersanmd.patch2 uploaded by dvossel (license 671) Tested by: Marquis, dvossel Review: http://reviewboard.digium.com/r/177/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@180078 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	ce5bbc3eb8	Merged revisions 179973 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r179973 | murf | 2009-03-03 15:12:02 -0700 (Tue, 03 Mar 2009) | 33 lines Merged revisions 179807 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 I had some work to do to port these changes to trunk; the check_expr stuff hasn't been updated here for quite some time, it appears. I added some more tests to the check_expr2 suite. I had to play around with the makefile a bit, etc. I added STANDALONE2 #ifdefs to ast_expr2.y so as not to conflict structure with aelparse. ........ r179807 | murf | 2009-03-03 11:11:34 -0700 (Tue, 03 Mar 2009) | 19 lines These changes allow AEL to better check ${} constructs within $[...], that are concatenated with text. I modified and added rules in ast_expr2.fl to better handle the concatenations. I added some default routines to ast_expr2.y so the standalone would compile. It also looks like I haven't run this thru bison since 2.1, so it's good to get this updated. The Makefile has comments added now for check_expr2 and check_expr to explain what they are for, and how to run them. The testexpr2s stuff has been removed, in favor of check_expr2. expr2.testinput has been updated to include the two expressions that inspired these changes (from mcnobody on #asterisk this morning) The regression has been run and all looks well. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@180058 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Joshua Colp	807cb98467	Merged revisions 179841 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r179841 | file | 2009-03-03 14:28:46 -0400 (Tue, 03 Mar 2009) | 16 lines Merged revisions 179840 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179840 | file | 2009-03-03 14:27:09 -0400 (Tue, 03 Mar 2009) | 9 lines Do not assume that the bridge_cdr is still attached to the channel when the 'h' exten is finished executing. It is possible for a masquerade operation to occur when the 'h' exten is operating. This operation moves the CDR records around causing the bridge_cdr to no longer exist on the channel where it is expected to. We can not safely modify it afterwards because of this, so don't even try. (closes issue #14564) Reported by: meric ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@179842 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	e4ae90e0cb	Merged revisions 179742 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r179742 | russell | 2009-03-03 10:47:28 -0600 (Tue, 03 Mar 2009) | 14 lines Merged revisions 179741 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179741 | russell | 2009-03-03 10:45:46 -0600 (Tue, 03 Mar 2009) | 6 lines Ensure chan->fdno always gets reset to -1 after handling a channel fd event. Since setting fdno to -1 had to be moved, a couple of other code paths that do process an fd event return early and do not pass through the code path where it was moved to. So, set it to -1 in a few other places, too. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@179743 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Joshua Colp	5284efc9ce	Merged revisions 179672 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r179672 | file | 2009-03-03 10:40:04 -0400 (Tue, 03 Mar 2009) | 10 lines Merged revisions 179671 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179671 | file | 2009-03-03 10:38:09 -0400 (Tue, 03 Mar 2009) | 3 lines Move where fdno is set to the default value to *after* the read callback of the channel driver is called. We have to do this as the underlying channel driver may need the fdno value to determine what to read. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@179673 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	1e4f2f5a1b	Merged revisions 179609 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r179609 | russell | 2009-03-03 07:54:41 -0600 (Tue, 03 Mar 2009) | 17 lines Merged revisions 179608 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179608 | russell | 2009-03-03 07:53:52 -0600 (Tue, 03 Mar 2009) | 9 lines Make it easier to detect an improper call to ast_read(). When you call ast_waitfor() on a channel, the index into the channel fds array that holds the file descriptor that poll() determines has input available is stored in fdno. This patch clears out this value after a call to ast_read() and also reports errors if ast_read() is called without an fdno set. From a discussion on the asterisk-dev list. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@179610 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	f355d2180a	Merged revisions 179537 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r179537 | jpeeler | 2009-03-02 18:01:51 -0600 (Mon, 02 Mar 2009) | 21 lines Merged revisions 179536 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179536 | jpeeler | 2009-03-02 17:54:39 -0600 (Mon, 02 Mar 2009) | 15 lines Fix bridging regression from commit 176701 This fixes a bad regression where the bridge would exit after an attended transfer was made. The problem was due to nexteventts getting set after the masquerade which caused the bridge to return AST_BRIDGE_COMPLETE. (closes issue #14315) Reported by: tim_ringenbach ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@179538 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	93bba53c69	Merged revisions 179469 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r179469 | tilghman | 2009-03-02 17:10:18 -0600 (Mon, 02 Mar 2009) | 17 lines Merged revisions 179468 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179468 | tilghman | 2009-03-02 17:09:01 -0600 (Mon, 02 Mar 2009) | 10 lines When ending a recording with silence detection, remember to reduce the duration. The end of the recording is correspondingly trimmed, but the duration was not trimmed by the number of seconds trimmed, so the saved duration was necessarily longer than the actual soundfile duration. (closes issue #14406) Reported by: sasargen Patches: 20090226__bug14406.diff.txt uploaded by tilghman (license 14) Tested by: sasargen ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@179470 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	9a6e93c561	Merged revisions 179462 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r179462 | russell | 2009-03-02 17:00:30 -0600 (Mon, 02 Mar 2009) | 16 lines Merged revisions 179461 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179461 | russell | 2009-03-02 16:58:18 -0600 (Mon, 02 Mar 2009) | 8 lines Ensure that only one thread is calling ast_settimeout() on a channel at a time. For example, with an IAX2 channel, you can have both the channel thread and the chan_iax2 processing threads calling this function, and doing so twice at the same time is a bad thing. (Found in a debugging session with dvossel and mmichelson) ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@179463 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jason Parker	98d73b0f65	Merged revisions 179396 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r179396 | qwell | 2009-03-02 14:16:51 -0600 (Mon, 02 Mar 2009) | 9 lines Merged revisions 179395 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179395 | qwell | 2009-03-02 14:14:57 -0600 (Mon, 02 Mar 2009) | 1 line Remove several silly warnings in editline. One about a broken preprocessor directive, and another about strlcpy/strlcat. (closes issue #14264) Reported by: dimas ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@179402 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	f42c14308d	Merged revisions 178986 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r178986 | murf | 2009-02-26 20:45:58 -0700 (Thu, 26 Feb 2009) | 26 lines Merged revisions 178956 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 In this case, it's just a matter of reducing the default timeouts from 2000 to 1000 msec, as the max def feature digit timeout is no longer halved. ........ r178956 | murf | 2009-02-26 14:27:32 -0700 (Thu, 26 Feb 2009) | 18 lines This change moves the default feature digit timeout to 1000 ms from the previous default of 500. As per bug 14515, a dev discussion arrived at a "mediated concensus" of a default feature digit timeout of 1.0 sec. Some voted for 1300; ctooley thought 1500 for distracted phone users in phone booths; kpfleming put his foot down at 1.0 sec. Users who found the previous default max delay of 250 msec perfect, are welcome to override the new default. Notice that I said that 250 msec was the default; wait a minute, you might say, the config file said it was 500 msec!; well, because of the bug fix for 14515, we found that 500 msec was actually enforcing a max of 250. The bug fix would restore 500 msec, but we felt even that was a bit tight for most users... 2000 msec was pushed earlier by mmichelson, so that reduces to 1000 msec after the bug fix. Enjoy! ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@178987 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	547b76aa6a	Merged revisions 178828 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r178828 | murf | 2009-02-26 10:22:11 -0700 (Thu, 26 Feb 2009) | 34 lines Merged revisions 178804 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178804 | murf | 2009-02-26 10:09:03 -0700 (Thu, 26 Feb 2009) | 28 lines This patch prevents the feature detection timeout from being cut in half. Because the ast_channel_bridge() call will return 0 and pass a frame pointer for both DTMF_BEGIN and DTMF_END, the feature_timer field in hte config struct is getting decremented twice, which effectively cuts the digittimeout in half. I added conditions to the if statement to only let DTMF_END frames to flow thru, which solved the problem. Also, when the frame pointer is null, let control flow thru-- this usually happens on timeouts. I added a comment to the code to explain what's going on and why. Many thanks to sodom for reporting this problem. Personnally, it always seemed like something was wrong with the featuredigittimeout, but I never could quite decide what... and was too busy to investigate. This bug forced the issue, and now we know. Sodom had other issues in 14515, but I couldn't reproduce them. If he still has problems, and wants to get them solved, he is welcome to reopen 14515. (closes issue #14515) Reported by: sodom Patches: 14515.patch uploaded by murf (license 17) Tested by: murf, sodom ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@178866 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	e1eba74ef4	Merged revisions 178509 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r178509 | russell | 2009-02-25 06:45:30 -0600 (Wed, 25 Feb 2009) | 10 lines Merged revisions 178508 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178508 | russell | 2009-02-25 06:43:36 -0600 (Wed, 25 Feb 2009) | 2 lines Update the copyright year for the main page of the doxygen documentation. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@178510 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	41451ea689	Merged revisions 178381 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r178381 | tilghman | 2009-02-24 14:52:44 -0600 (Tue, 24 Feb 2009) | 2 lines Apparently, a void cast doesn't override warn_unused_result. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@178382 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	239ad71be7	Merged revisions 178374 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r178374 | russell | 2009-02-24 14:39:57 -0600 (Tue, 24 Feb 2009) | 14 lines Merged revisions 178373 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178373 | russell | 2009-02-24 14:36:19 -0600 (Tue, 24 Feb 2009) | 6 lines Only set dtmfcount on BEGIN, and ensure it gets reset to 0 properly. (issue #14460) Reported by: moliveras Tested by: russell ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@178378 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	425201ca94	Merged revisions 178375 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r178375 | tilghman | 2009-02-24 14:40:02 -0600 (Tue, 24 Feb 2009) | 2 lines The 3 possible errors with pipe(2) are all impossible in this situation. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@178376 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	31fd4d3573	Merged revisions 178342 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r178342 | tilghman | 2009-02-24 14:06:48 -0600 (Tue, 24 Feb 2009) | 2 lines Use a SIGPIPE to kill the process, instead of depending upon the astcanary process being inherited by init. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@178343 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	07b9f97f48	Merged revisions 178142 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r178142 | russell | 2009-02-23 17:11:37 -0600 (Mon, 23 Feb 2009) | 22 lines Merged revisions 178141 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178141 | russell | 2009-02-23 17:09:01 -0600 (Mon, 23 Feb 2009) | 14 lines Fix infinite DTMF when a BEGIN is received without an END. This commit is related to rev 175124 of 1.4 where a previous attempt was made to fix this problem. The problem with the previous patch was that the inserted code needed to go _before_ setting the lastrxts to the current timestamp. Because those were the same, the dtmfcount variable was never decremented, and so the END was never sent. In passing, I removed the dtmfsamples variable which was completed unused. I also removed a redundant setting of the lastrxts variable. (closes issue #14460) Reported by: moliveras ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@178145 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	d6c817f2f1	Merged revisions 177787 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r177787 | tilghman | 2009-02-20 17:02:35 -0600 (Fri, 20 Feb 2009) | 16 lines Merged revisions 177786 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r177786 | tilghman | 2009-02-20 16:59:52 -0600 (Fri, 20 Feb 2009) | 9 lines Don't print the CR-NL combination when we aren't outputting to the manager. An embedded CR-NL in a CLI command screws up several AMI parsers that don't expect to see that combination in the middle of output. (Closes issue #14305) Reported by: martins Patch by: tilghman ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@177788 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	36f41cee56	Merged revisions 177664 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r177664 | tilghman | 2009-02-20 11:29:51 -0600 (Fri, 20 Feb 2009) | 8 lines Allow semicolons to be escaped, when passing arguments to the System command. (closes issue #14231) Reported by: jcovert Patches: 20090113__bug14231__2.diff.txt uploaded by Corydon76 (license 14) corrected_20090113__bug14231__2.diff.txt uploaded by jcovert (license 551) Tested by: jcovert ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@177665 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	7ea292e195	Merged revisions 177595 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r177595 | murf | 2009-02-19 16:56:50 -0700 (Thu, 19 Feb 2009) | 32 lines Merged revisions 177540 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 Trunk was already pretty 8-bit clean; but I'm still removing the --full from the flex command so everything is uniform. ........ r177540 | murf | 2009-02-19 15:51:37 -0700 (Thu, 19 Feb 2009) | 21 lines This patch fixes a problem with 8-bit input to the ast_expr2 scanner. The real culprit was the --full argument to flex in the Makefile! This causes a 7-bit scanner to be generated. I reviewed the rules and found one rule where I needed to specifically include 8-bit chars for a token. I tested against the text supplied by ibercom, and all looks very well. This has been there a surprisingly long time! (closes issue #14498) Reported by: ibercom Patches: 14498.patch uploaded by murf (license 17) Tested by: murf ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@177596 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	676fb48b9b	Merged revisions 177356 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r177356 | jpeeler | 2009-02-19 09:56:31 -0600 (Thu, 19 Feb 2009) | 4 lines Fix mismerge from revision 176708 pointed out by Kaloyan Kovachev on the asterisk-dev mailing list. Thanks! ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@177357 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Kevin P. Fleming	b72c17951f	Merged revisions 177229 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r177229 | kpfleming | 2009-02-18 17:09:58 -0600 (Wed, 18 Feb 2009) | 3 lines fix two very minor bugs: if anyone ever uses SLINEAR16 as a format in RTP, ensure that the samples are byte-swapped to network order if needed. also, when a smoother is operating on a format that has a sample rate other than 8000 samples per second, use the proper sample rate for computing delivery timestamps. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@177231 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
David Vossel	48cccb7858	Merged revisions 177226 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r177226 | dvossel | 2009-02-18 16:51:38 -0600 (Wed, 18 Feb 2009) | 9 lines Locking issue in action_bridge and bridge_exec action_bridge() and bridge_exec() both search for the channels to bridge to, and then immediately drop the lock. Instead, they should hold the lock until the masquerade is complete. This will guarantee the channel remains and prevent any other weirdness from occurring. In action_bridge() some more weirdness comes into play. Both channels are needlessly locked at the same time and perform the exact same logic. It makes sense from a coding organizational standpoint, but could cause a theoretical deadlock so I split the code up. There is an issue associated with this, but since its a rather complicated thing to reproduce I'm not certain this alone will close it. issue# 14296 Review: http://reviewboard.digium.com/r/167/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@177227 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Doug Bailey	010ec27cfd	Merged revisions 177035 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r177035 | dbailey | 2009-02-18 11:24:07 -0600 (Wed, 18 Feb 2009) | 2 lines Fixed error where a check for an zero length, terminated string was needed. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@177038 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Doug Bailey	20dea27b4b	Merged revisions 176948 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r176948 | dbailey | 2009-02-18 10:09:12 -0600 (Wed, 18 Feb 2009) | 2 lines Need to take into account the \0 terminator of the old string to determine the amount available. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@177004 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	babd94b38e	Merged revisions 176943 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r176943 | murf | 2009-02-18 08:35:26 -0700 (Wed, 18 Feb 2009) | 45 lines This patch fixes merge_contexts_and_delete so it does not deadlock when hints are present. Reason: when I re-engineered the merge_and_delete func to reduce its lock time, I failed to notice that the functions it calls still also do locking as before. This leads to deadlocks on dialplan reloads, when there are actually living, subscribed hints registered in the system. While the reporter come across this problem while using AEL, I might note that these deadlocks should also happen if extensions.conf were used. Here I added these routines to pbx.c: ast_add_extension_nolock add_pri_lockopt ast_add_extension2_lockopt find_context add_hint_nolock All of the above routines are static and restricted to be used only within pbx.c, and more specifically within the merge_contexts_and_delete routine. They are pretty much the same as their counterparts except they don't lock contexts or hints. Most of them now do the real work of their name-alike, with optional locking via extra arguments, and are called by their name-alike. The goal was to have the original functions so they would behave exactly as before. Both PJ and I tested these fixes, and the deadlocking problem is no longer encountered. (closes issue #14357) Reported by: pj Patches: 14357.diff uploaded by murf (license 17) Tested by: pj, murf ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@176944 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	46db811169	Merged revisions 176708 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r176708 | jpeeler | 2009-02-17 16:08:00 -0600 (Tue, 17 Feb 2009) | 23 lines Merged revisions 176701 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r176701 | jpeeler | 2009-02-17 15:54:34 -0600 (Tue, 17 Feb 2009) | 17 lines Modify bridging to properly evaluate DTMF after first warning is played The main problem is currently if the Dial flag L is used with a warning sound, DTMF is not evaluated after the first warning sound. To fix this, a flag has been added in ast_generic_bridge for playing the warning which ensures that if a scheduled warning is missed, multiple warrnings are not played back (due to a feature evaluation or waiting for digits). ast_channel_bridge was modified to store the nexteventts in the ast_bridge_config structure as that information was lost every time ast_channel_bridge was reentered, causing a hangup due to incorrect time calculations. (closes issue #14315) Reported by: tim_ringenbach Reviewed on reviewboard: http://reviewboard.digium.com/r/163/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@176710 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Kevin P. Fleming	f3ae0e00a7	Merged revisions 176255 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r176255 | kpfleming | 2009-02-16 15:45:54 -0600 (Mon, 16 Feb 2009) | 13 lines Merged revisions 176216 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r176216 | kpfleming | 2009-02-16 15:10:38 -0600 (Mon, 16 Feb 2009) | 3 lines fix a flaw in the ast_string_field_build() family of API calls; these functions made no attempt to reuse the space already allocated to a field, so every time the field was written it would allocate new space, leading to what appeared to be a memory leak. ........ r176254 | kpfleming | 2009-02-16 15:41:46 -0600 (Mon, 16 Feb 2009) | 3 lines correct a logic error in the last stringfields commit... don't mark additional space as allocated if the string was built using already-allocated space ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@176258 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	1999cdee6c	Merged revisions 176174 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r176174 | mmichelson | 2009-02-16 12:25:57 -0600 (Mon, 16 Feb 2009) | 11 lines Assist proper thread synchronization when stopping the logger thread. I was finding that on my dev box, occasionally attempting to "stop now" in trunk would cause Asterisk to hang. I traced this to the fact that the logger thread was waiting on a condition which had already been signalled. The logger thread also need to be sure to check the value of the close_logger_thread variable. The close_logger_thread variable is only checked when the list of logmessages is empty. This allows for the logger thread to print and free any pending messages before exiting. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@176175 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	96a87efb7f	Merged revisions 175334 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r175334 | tilghman | 2009-02-12 15:25:14 -0600 (Thu, 12 Feb 2009) | 16 lines Merged revisions 175311 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175311 | tilghman | 2009-02-12 15:19:40 -0600 (Thu, 12 Feb 2009) | 9 lines Fix crashes when receiving certain T.38 packets. Also, increase the maximum size of T.38 packets and warn users when they try to set the limits above those maximums. (closes issue #13050) Reported by: schern Patches: 20090212__bug13050.diff.txt uploaded by Corydon76 (license 14) Tested by: schern ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@175347 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	8008dca29d	Fix mistake in merging conflict from 175299. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@175301 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	0a72cfe440	Merged revisions 175298 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r175298 | jpeeler | 2009-02-12 14:48:56 -0600 (Thu, 12 Feb 2009) | 15 lines Merged revisions 175294 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175294 | jpeeler | 2009-02-12 14:34:36 -0600 (Thu, 12 Feb 2009) | 9 lines Fix ParkedCall event information for From field in the case of a blind transfer If the parker information can not be obtained from the peer, try and see if the BLINDTRANSFER channel variable has been set. Previously, a blind transfer to the ParkAndAnnounce app would return nothing for the From. Closes AST-189 ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@175299 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	17df1c9d13	Merged revisions 175188 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r175188 | jpeeler | 2009-02-12 12:00:11 -0600 (Thu, 12 Feb 2009) | 12 lines Merged revisions 175187 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175187 | jpeeler | 2009-02-12 11:57:10 -0600 (Thu, 12 Feb 2009) | 6 lines Fix crash in event of failed attempt to transfer to parking The peer may not necessarily exist, such as in the case of a transfer to ParkAndAnnounce. In this case don't try to play a sound to it. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@175189 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	d79cc1e799	Merged revisions 175125 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r175125 | russell | 2009-02-12 10:57:25 -0600 (Thu, 12 Feb 2009) | 35 lines Merged revisions 175124 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175124 | russell | 2009-02-12 10:51:13 -0600 (Thu, 12 Feb 2009) | 27 lines Don't send DTMF for infinite time if we do not receive an END event. I thought that this was going to end up being a pretty gnarly fix, but it turns out that there was actually already a configuration option in rtp.conf, dtmftimeout, that was intended to handle this situation. However, in between Asterisk 1.2 and Asterisk 1.4, the code that processed the option got lost. So, this commit brings it back to life. The default timeout is 3 seconds. However, it is worth noting that having this be configurable at all is not really the recommended behavior in RFC 2833. From Section 3.5 of RFC 2833: Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless. Three seconds will pretty much _always_ be far more than three packet interarrival times. However, that behavior is not required, so I'm going to leave it with our legacy behavior for now. Code from svn/asterisk/team/russell/issue_14460 (closes issue #14460) Reported by: moliveras ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@175126 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	90ef4eb33e	Merged revisions 175121 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r175121 | mmichelson | 2009-02-12 10:28:06 -0600 (Thu, 12 Feb 2009) | 11 lines Make lock information for ao2_trylock be more useful and gnarly Core show locks information involving an ao2_trylock did not show the function that called ao2_trylock, but would instead show ao2_trylock as the source of the lock. This is not useful when trying to debug locking issues. One bizarre note is that this logic is already in 1.4 but somehow did not get merged to trunk or the 1.6.X branches. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@175122 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	a45ec0c30a	Merged revisions 174945 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r174945 | mmichelson | 2009-02-11 16:41:01 -0600 (Wed, 11 Feb 2009) | 29 lines Fix 'd' option for app_dial and add new option to Answer application The 'd' option would not work for channel types which use RTP to transport DTMF digits. The only way to allow for this to work was to answer the channel if we saw that this option was enabled. I realized that this may cause issues with CDRs, specifically with giving false dispositions and answer times. I therefore modified ast_answer to take another parameter which would tell if the CDR should be marked answered. I also extended this to the Answer application so that the channel may be answered but not CDRified if desired. I also modified app_dictate and app_waitforsilence to only answer the channel if it is not already up, to help not allow for faulty CDR answer times. All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all the changes except for the change to the Answer application will go in since we do not introduce new features into stable branches (closes issue #14164) Reported by: DennisD Patches: 14164.patch uploaded by putnopvut (license 60) Tested by: putnopvut Review: http://reviewboard.digium.com/r/145 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@174946 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	0aaff466b7	Merged revisions 174764 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r174764 | mmichelson | 2009-02-10 15:45:14 -0600 (Tue, 10 Feb 2009) | 21 lines Fix an fd leak that would occur in HTTP AMI sessions The explanation behind this fix is a bit complicated, and I've already typed it up in the code as a huge comment inside of manager.c, so I'll give the abridged version here. We needed a way to separate action-specific data from session-specific data. Unfortunately, the only way to maintain API compatibility and to not have to change every single manager action was to rename the current mansession structure and wrap it inside a new mansession structure which actually contains action- specific data. (closes issue #14364) Reported by: awk Patches: 14364_better.patch uploaded by putnopvut (license 60) Tested by: putnopvut Review: http://reviewboard.digium.com/r/148/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@174765 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Matthew Nicholson	bd217cb067	Merged revisions 174584 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r174584 | mnicholson | 2009-02-10 12:16:31 -0600 (Tue, 10 Feb 2009) | 25 lines Merged revisions 174583 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r174583 | mnicholson | 2009-02-10 11:52:42 -0600 (Tue, 10 Feb 2009) | 18 lines Improve behavior of jitterbuffer when maxjitterbuffer is set. This change improves the way the jitterbuffer handles maxjitterbuffer and dramatically reduces the number of frames dropped when maxjitterbuffer is exceeded. In the previous jitterbuffer, when maxjitterbuffer was exceeded, all new frames were dropped until the jitterbuffer is empty. This change modifies the code to only drop frames until maxjitterbuffer is no longer exceeded. Also, previously when maxjitterbuffer was exceeded, dropped frames were not tracked causing stats for dropped frames to be incorrect, this change also addresses that problem. (closes issue #14044) Patches: bug14044-1.diff uploaded by mnicholson (license 96) Tested by: mnicholson Review: http://reviewboard.digium.com/r/144/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@174596 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	58d71a9470	Merged revisions 173500 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r173500 | jpeeler | 2009-02-04 15:17:53 -0600 (Wed, 04 Feb 2009) | 23 lines Merged revisions 173211 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r173211 | jpeeler | 2009-02-03 15:57:01 -0600 (Tue, 03 Feb 2009) | 17 lines Parking attempts made to one end of a bridge no longer will hang up due to a parking failure. Parking attempts made using either one-touch, or doing either a blind or assisted transfer to the parking extension now keep up the bridge instead of hanging up the attempted parked party. Normal causes for the parking attempt to fail includes the specific specified extension (via PARKINGEXTEN) not being available or if all the parking spaces are currently in use. To avoid having to reverse a masquerade park_space_reserve was made to provide foresight if a parking attempt will succeed and if so reserve the parking space. (closes issue #13494) Reported by: mdu113 Reviewed by Russell: http://reviewboard.digium.com/r/133/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@173546 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	8c1a726973	Merged revisions 173458 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r173458 | tilghman | 2009-02-04 12:48:06 -0600 (Wed, 04 Feb 2009) | 9 lines When using a socket as a FILE *, the stdio functions will sometimes try to do an fseek() on the stream, which is an invalid operation for a socket. Turning off buffering explicitly lets the stdio functions know they cannot do this, thus avoiding a potential error. (closes issue #14400) Reported by: fnordian Patches: tcptls.patch uploaded by fnordian (license 110) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@173460 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	a71ca0b0e3	Merged revisions 173354 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r173354 | mmichelson | 2009-02-04 09:30:12 -0600 (Wed, 04 Feb 2009) | 30 lines Fix a problem where file playback would cause fds to remain open forever The problem came from the fact that a frame read from a format interpreter was not freed. Adding a call to ast_frfree fixed this. The explanation for why this caused the problem is a bit complex, but here goes: There was a problem in all versions of Asterisk where the embedded frame of a filestream structure was referenced after the filestream was freed. This was fixed by adding reference counting to the filestream structure. The refcount would increase every time that a filestream's frame pointer was pointing to an actual frame of data. When the frame was freed, the refcount would decrease. Once the refcount reached 0, the filestream was freed, and as part of the operation, the open files were closed as well. Thus it becomes more clear why a missing ast_frfree would cause a reference leak and cause the files to not be closed. You may ask then if there was a frame leak before this patch. The answer to that is actually no! The filestream code was "smart" enough to know that since the frame we received came from a format interpreter, the frame had no malloced data and thus didn't need to be freed. Now, however, there is cleanup that needs to be done when we finish with the frame, so we do need to call ast_frfree on the frame to be sure that the refcount for the filestream is decremented appropriately. (closes issue #14384) Reported by: fiddur Patches: 14384.patch uploaded by putnopvut (license 60) Tested by: fiddur, putnopvut ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@173355 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	3d71c38287	Merged revisions 173311 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r173311 | tilghman | 2009-02-03 18:43:52 -0600 (Tue, 03 Feb 2009) | 10 lines Ensure that commas placed in the middle of extension character classes do not interfere with correct parsing of the extension. Also, if an unterminated character class DOES make its way into the pbx core (through some other method), ensure that it does not crash Asterisk. (closes issue #14362) Reported by: Nick_Lewis Patches: 20090129__bug14362.diff.txt uploaded by Corydon76 (license 14) Tested by: Corydon76 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@173312 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Terry Wilson	6aa5e4f230	Merged revisions 173067 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r173067 | twilson | 2009-02-02 17:57:25 -0600 (Mon, 02 Feb 2009) | 9 lines Merged revisions 173066 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r173066 | twilson | 2009-02-02 17:48:06 -0600 (Mon, 02 Feb 2009) | 2 lines Fix a feature inheritance bug I added after code review ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@173068 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Terry Wilson	af2b34cb56	Merged revisions 172580 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r172580 | twilson | 2009-01-30 15:29:12 -0600 (Fri, 30 Jan 2009) | 44 lines Merged revisions 172517 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines Fix feature inheritance with builtin features When using builtin features like parking and transfers, the AST_FEATURE_* flags would not be set correctly for all instances when either performing a builtin attended transfer, or parking a call and getting the timeout callback. Also, there was no way on a per-call basis to specify what features someone should have on picking up a parked call (since that doesn't involve the Dial() command). There was a global option for setting whether or not all users who pickup a parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT, AUTOMON, or PARKCALL. This patch: 1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the dialplan or with setvar in channels that support it. This variable can be set to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the equivalent dial options), to set what features should be activated on this channel. The patch moves the setting of the features datastores into the bridging code instead of app_dial to help facilitate this. 2) adds global options parkedcallparking, parkedcallhangup, and parkedcallrecording to be similar to the parkedcalltransfers option for globally setting features. 3) has builtin_atxfer call builtin_parkcall if being transfered to the parking extension since tracking everything through multiple masquerades, etc. is difficult and error-prone 4) attempts to fix all cases of return calls from parking and completed builtin transfers not having the correct permissions (closes issue #14274) Reported by: aragon Patches: fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396) Tested by: aragon, otherwiseguy Review http://reviewboard.digium.com/r/138/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@172635 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	407d3d8861	Merged revisions 172441 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r172441 | tilghman | 2009-01-29 17:15:40 -0600 (Thu, 29 Jan 2009) | 16 lines Merged revisions 172438 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r172438 | tilghman | 2009-01-29 16:54:29 -0600 (Thu, 29 Jan 2009) | 9 lines Lose the CAP_NET_ADMIN at every fork, instead of at startup. Otherwise, if Asterisk runs as a non-root user and the administrator does a 'restart now', Asterisk loses the ability to set QOS on packets. (closes issue #14004) Reported by: nemo Patches: 20090105__bug14004.diff.txt uploaded by Corydon76 (license 14) Tested by: Corydon76 ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@172503 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	491c4a9c68	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: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@172065 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago