aboutsummaryrefslogtreecommitdiffstats
path: root/main/pbx.c
AgeCommit message (Collapse)AuthorFilesLines
2009-11-11Merged revisions 229499 via svnmerge from dbrooks1-4/+5
https://origsvn.digium.com/svn/asterisk/trunk ................ r229499 | dbrooks | 2009-11-11 13:48:18 -0600 (Wed, 11 Nov 2009) | 15 lines Merged revisions 229498 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r229498 | dbrooks | 2009-11-11 13:46:19 -0600 (Wed, 11 Nov 2009) | 8 lines Solaris doesn't like NULL going to ast_log Solaris will crash if NULL is passed to ast_log. This simple patch simply uses S_OR to get around this. (closes issue #15392) Reported by: yrashk ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@229500 f38db490-d61c-443f-a65b-d21fe96a405b
2009-11-10Merged revisions 229361 via svnmerge from tilghman1-18/+36
https://origsvn.digium.com/svn/asterisk/trunk ................ r229361 | tilghman | 2009-11-10 16:14:22 -0600 (Tue, 10 Nov 2009) | 19 lines Merged revisions 229360 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r229360 | tilghman | 2009-11-10 16:09:16 -0600 (Tue, 10 Nov 2009) | 12 lines If two pattern classes start with the same digit and have the same number of characters, they will compare equal. The example given in the issue report is that of [234] and [246], which have these characteristics, yet they are clearly not equivalent. The code still uses these two characteristics, yet when the two scores compare equal, an additional check will be done to compare all characters within the class to verify equality. (closes issue #15421) Reported by: jsmith Patches: 20091109__issue15421__2.diff.txt uploaded by tilghman (license 14) Tested by: jsmith, thedavidfactor ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@229363 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-22Merged revisions 225360 via svnmerge from tilghman1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r225360 | tilghman | 2009-10-22 12:11:23 -0500 (Thu, 22 Oct 2009) | 11 lines Merged revisions 225105 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r225105 | tilghman | 2009-10-21 11:02:12 -0500 (Wed, 21 Oct 2009) | 4 lines Fix documentation for ast_softhangup() and correct the misuse thereof. (closes issue #16103) Reported by: majorbloodnok ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@225361 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-07Properly initialize ast_devstate_aggregate so we don't crash sporadically.seanbright1-0/+2
This looks like it was just missed during a merge. (closes issue #15841) Reported by: amorsen Patches: ast_devstate_aggregate_init-in-ast_extension_state2.patch uploaded by amorsen (license 676) Tested by: amorsen (closes issue #15852) Reported by: amorsen Tested by: amorsen, farisraouf git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@222605 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-24Merged revisions 220289 via svnmerge from tilghman1-2/+0
https://origsvn.digium.com/svn/asterisk/trunk ................ r220289 | tilghman | 2009-09-24 14:41:02 -0500 (Thu, 24 Sep 2009) | 13 lines Merged revisions 220288 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r220288 | tilghman | 2009-09-24 14:39:41 -0500 (Thu, 24 Sep 2009) | 6 lines Implicitly sending a progress signal breaks some applications. Call Progress() in your dialplan if you explicitly want progress to be sent. (Reverts change 216430, closes issue #15957) Reported by: Pavel Troller on the Asterisk-Dev mailing list http://lists.digium.com/pipermail/asterisk-dev/2009-September/039897.html ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@220290 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-16Merged revisions 218868 via svnmerge from dbrooks1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r218868 | dbrooks | 2009-09-16 13:06:42 -0500 (Wed, 16 Sep 2009) | 20 lines Merged revisions 218867 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r218867 | dbrooks | 2009-09-16 13:00:45 -0500 (Wed, 16 Sep 2009) | 13 lines Fixes CID pattern matching behavior to mirror that of extension pattern matching. Pattern matching for extensions uses a type of scoring system, giving values for specificity to each character in the pattern. Unfortunately, this is done character by character, in order. This does lead to some less specific patterns being first in line for matching, but it will usually get the job done. This patch merely brings CID matching to the same level as extension matching. This patch does not attempt to tackle the problem shared by extension matching. (closes issue #14708) Reported by: klaus3000 ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@218869 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-07Merged revisions 216438 via svnmerge from oej1-0/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r216438 | oej | 2009-09-04 16:02:34 +0200 (Fre, 04 Sep 2009) | 35 lines Merged revisions 216430 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines Make apps send PROGRESS control frame for early media and fix too early media issue in SIP The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI links *before* any call progress. The SIP channel receives these frames and by default signals 183 Session progress and starts sending media. This will cause phones to play silence and ignore the later 180 ringing message. A bad user experience. The fix is twofold: - We discovered that asterisk apps that support early media ("noanswer") did not send any PROGRESS frame to indicate early media. Fixed. - We introduce a setting in chan_sip so that users can disable any relay of media frames before the outbound channel actually indicates any sort of call progress. In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions of Asterisk, this will be enabled. We don't assume that it will change your Asterisk phone experience - only for the better. We encourage third-party application developers to make sure that if they have applications that wants to send early media, add a PROGRESS control frame transmission to make sure that all channel drivers actually will start sending early media. This has not been the default in Asterisk previous to this patch, so if you got inspiration from our code, you need to update accordingly. Sorry for the trouble and thanks for your support. This code has been running for a few months in a large scale installation (over 250 servers with PRI and/or BRI links to old PBX systems). That's no proof that this is an excellent patch, but, well, it's tested :-) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@216645 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-04Merged revisions 216547 via svnmerge from tilghman1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r216547 | tilghman | 2009-09-04 12:31:44 -0500 (Fri, 04 Sep 2009) | 3 lines Enable turning off the application delimiter warning with the 'dontwarn' option. Suggested on the -dev list, and implemented in an alternate way by me. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@216548 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-25Merged revisions 213971 via svnmerge from tilghman1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r213971 | tilghman | 2009-08-25 01:35:37 -0500 (Tue, 25 Aug 2009) | 14 lines Merged revisions 213970 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r213970 | tilghman | 2009-08-25 01:34:44 -0500 (Tue, 25 Aug 2009) | 7 lines Improve error message by informing user exactly which function is missing a parethesis. (closes issue #15242) Reported by: Nick_Lewis Patches: pbx.c-funcparenthesis.patch2 uploaded by dbrooks (license 790) pbx.c-funcparenthesis-1.4.diff uploaded by loloski (license 68) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@213972 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-10AST-2009-005tilghman1-6/+6
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@211551 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-08Merged revisions 205412 via svnmerge from dvossel1-0/+26
https://origsvn.digium.com/svn/asterisk/trunk ................ r205412 | dvossel | 2009-07-08 17:15:06 -0500 (Wed, 08 Jul 2009) | 12 lines Merged revisions 205409 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r205409 | dvossel | 2009-07-08 16:35:12 -0500 (Wed, 08 Jul 2009) | 6 lines moving ast_devstate_to_extenstate to pbx.c from devicestate.c ast_devstate_to_extenstate belongs in pbx.c. This change fixes a compile time error with chan_vpb as well. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@205415 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-02Merged revisions 204710 via svnmerge from dvossel1-61/+36
https://origsvn.digium.com/svn/asterisk/trunk ................ r204710 | dvossel | 2009-07-02 11:03:44 -0500 (Thu, 02 Jul 2009) | 21 lines Merged revisions 204681 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r204681 | dvossel | 2009-07-02 10:05:57 -0500 (Thu, 02 Jul 2009) | 14 lines Improved mapping of extension states from combined device states. This fixes a few issues with incorrect extension states and adds a cli command, core show device2extenstate, to display all possible state mappings. (closes issue #15413) Reported by: legart Patches: exten_helper.diff uploaded by dvossel (license 671) Tested by: dvossel, legart, amilcar Review: https://reviewboard.asterisk.org/r/301/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@204754 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-10Fixes the argument order in definition of new_find_extension().dbrooks1-1/+1
In the definition of new_find_extension(), the arguments 'callerid' and 'label' were swapped. The prototype declaration and all calls to the function are ordered 'callerid' then 'label', but the function itself was ordered 'label' then 'callerid'. (closes issue #15303) Reported by: JimDickenson git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@199994 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-05Merged revisions 199298 via svnmerge from dvossel1-19/+12
https://origsvn.digium.com/svn/asterisk/trunk ................ r199298 | dvossel | 2009-06-05 16:21:22 -0500 (Fri, 05 Jun 2009) | 21 lines Merged revisions 199297 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r199297 | dvossel | 2009-06-05 16:19:56 -0500 (Fri, 05 Jun 2009) | 14 lines Fixes issue with hints giving unexpected results. Hints with two or more devices that include ONHOLD gave unexpected results. (closes issue #15057) Reported by: p_lindheimer Patches: onhold_trunk.diff uploaded by dvossel (license 671) pbx.c.1.4.patch uploaded by p (license 558) devicestate.c.trunk.patch uploaded by p (license 671) Tested by: p_lindheimer, dvossel Review: https://reviewboard.asterisk.org/r/254/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@199301 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-18Merged revisions 195162 via svnmerge from eliel1-0/+3
https://origsvn.digium.com/svn/asterisk/trunk ........ r195162 | eliel | 2009-05-18 10:45:23 -0400 (Mon, 18 May 2009) | 9 lines Warn about the use of the application WaitExten() within a Macro(). Update applications documentation to warn the user about the use of the WaitExten() application within a Macro(). Recommend the use of Read() instead. (closes issue #14444) Reported by: ewieling ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@195177 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-13Merged revisions 194138 via svnmerge from tilghman1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r194138 | tilghman | 2009-05-12 19:52:49 -0500 (Tue, 12 May 2009) | 14 lines Merged revisions 194137 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r194137 | tilghman | 2009-05-12 19:52:03 -0500 (Tue, 12 May 2009) | 7 lines Fix logic for how to proceed with a single digit extension. (closes issue #15091) Reported by: andrew Patches: 20090512__issue15091.diff.txt uploaded by tilghman (license 14) Tested by: andrew ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@194139 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-07Merged revisions 193120 via svnmerge from tilghman1-2/+17
https://origsvn.digium.com/svn/asterisk/trunk ................ r193120 | tilghman | 2009-05-07 18:42:28 -0500 (Thu, 07 May 2009) | 26 lines Merged revisions 193119 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r193119 | tilghman | 2009-05-07 18:41:11 -0500 (Thu, 07 May 2009) | 19 lines Fix Background within a Macro for FreePBX. If the single digit DTMF is an extension in the specified context, then go there and signal no DTMF. Otherwise, we should exit with that DTMF. If we're in Macro, we'll exit and seek that DTMF as the beginning of an extension in the Macro's calling context. If we're not in Macro, then we'll simply seek that extension in the calling context. Previously, someone complained about the behavior as it related to the interior of a Gosub routine, and the fix (#14011) inadvertently broke FreePBX (#14940). This change should fix both of these situations, but with the possible incompatibility that if a single digit extension does not exist (but a longer extension COULD have matched), it would have previously gone immediately to the "i" extension, but will now need to wait for a timeout. (closes issue #14940) Reported by: p_lindheimer Patches: 20090420__bug14940.diff.txt uploaded by tilghman (license 14) Tested by: p_lindheimer ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@193121 f38db490-d61c-443f-a65b-d21fe96a405b
2009-04-27Merged revisions 190726 via svnmerge from tilghman1-1/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r190726 | tilghman | 2009-04-27 14:34:48 -0500 (Mon, 27 Apr 2009) | 4 lines Don't warn on pipe in the System call. (closes issue #14979) Reported by: pj ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@190727 f38db490-d61c-443f-a65b-d21fe96a405b
2009-04-23Merged revisions 190352 via svnmerge from tilghman1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r190352 | tilghman | 2009-04-23 15:42:11 -0500 (Thu, 23 Apr 2009) | 7 lines Labels are sometimes (most of the time?) NULL for extensions. (closes issue #14895) Reported by: chris-mac Patches: 20090423__bug14895__2.diff.txt uploaded by tilghman (license 14) Tested by: lmadsen ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@190353 f38db490-d61c-443f-a65b-d21fe96a405b
2009-04-17Merged revisions 189010 via svnmerge from mnicholson1-1/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r189010 | mnicholson | 2009-04-17 10:44:18 -0500 (Fri, 17 Apr 2009) | 12 lines Merged revisions 189009 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r189009 | mnicholson | 2009-04-17 10:43:09 -0500 (Fri, 17 Apr 2009) | 5 lines Make Busy() application set the CDR disposition to BUSY. (closes issue #14306) Reported by: cristiandimache ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@189070 f38db490-d61c-443f-a65b-d21fe96a405b
2009-04-14Merged revisions 188210 via svnmerge from tilghman1-0/+5
https://origsvn.digium.com/svn/asterisk/trunk ........ r188210 | tilghman | 2009-04-14 00:45:13 -0500 (Tue, 14 Apr 2009) | 2 lines As suggested by Russell, warn users when their dialplan arguments contain pipes, but not commas. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@188211 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-20Merged revisions 177787 via svnmerge from tilghman1-10/+10
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@177788 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-18Merged revisions 176943 via svnmerge from murf1-16/+70
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@176944 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-11Merged revisions 174945 via svnmerge from mmichelson1-1/+1
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@174946 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-04Merged revisions 173311 via svnmerge from tilghman1-0/+3
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@173312 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-28Merged revisions 172063 via svnmerge from murf1-0/+3
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.0@172065 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-22Merged revisions 170051 via svnmerge from file1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r170051 | file | 2009-01-22 11:14:50 -0400 (Thu, 22 Jan 2009) | 13 lines Merged revisions 170050 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170050 | file | 2009-01-22 11:13:56 -0400 (Thu, 22 Jan 2009) | 6 lines Do a string comparison instead of pointer comparison since some people specify the context they are actually in as an argument to get around some funkiness. (closes issue #14011) Reported by: dveiga Patches: pbx.c.patch uploaded by dveiga (license 665) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@170052 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-21Merged revisions 169869 via svnmerge from file1-0/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r169869 | file | 2009-01-21 19:25:27 -0400 (Wed, 21 Jan 2009) | 11 lines Merged revisions 169867 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r169867 | file | 2009-01-21 19:20:47 -0400 (Wed, 21 Jan 2009) | 4 lines Read lock the contexts to maintain the locking order when we are notified that the state of a device has changed. (closes issue #13839) Reported by: mcallist ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@169870 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-13Merged revisions 168562 via svnmerge from russell1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r168562 | russell | 2009-01-13 13:22:13 -0600 (Tue, 13 Jan 2009) | 10 lines Merged revisions 168561 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r168561 | russell | 2009-01-13 13:13:05 -0600 (Tue, 13 Jan 2009) | 2 lines Revert unnecessary indications API change from rev 122314 ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@168564 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-24Merged revisions 166665 via svnmerge from murf1-4/+0
https://origsvn.digium.com/svn/asterisk/trunk Due to non-symmetrical updating, I had some fairly interesting conflicts to straighten out in this release. The changes were such that I was compelled to run thru all the same tests as trunk, which turned up some problems, which I fixed. ................ r166665 | murf | 2008-12-23 11:13:49 -0700 (Tue, 23 Dec 2008) | 153 lines Merged revisions 166093 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 In order to merge this 1.4 patch into trunk, I had to resolve some conflicts and wait for Russell to make some changes to res_agi. I re-ran all the tests; 39 calls in all, and made fairly careful notes and comparisons: I don't want this to blow up some aspect of asterisk; I completely removed the KEEPALIVE from the pbx.h decls. The first 3 scenarios involving feature park; feature xfer to 700; hookflash park to Park() app call all behave the same, don't appear to leave hung channels, and no crashes. ........ r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines This merges the masqpark branch into 1.4 These changes eliminate the need for (and use of) the KEEPALIVE return code in res_features.c; There are other places that use this result code for similar purposes at a higher level, these appear to be left alone in 1.4, but attacked in trunk. The reason these changes are being made in 1.4, is that parking ends a channel's life, in some situations, and the code in the bridge (and some other places), was not checking the result code properly, and dereferencing the channel pointer, which could lead to memory corruption and crashes. Calling the masq_park function eliminates this danger in higher levels. A series of previous commits have replaced some parking calls with masq_park, but this patch puts them ALL to rest, (except one, purposely left alone because a masquerade is done anyway), and gets rid of the code that tests the KEEPALIVE result, and the NOHANGUP_PEER result codes. While bug 13820 inspired this work, this patch does not solve all the problems mentioned there. I have tested this patch (again) to make sure I have not introduced regressions. Crashes that occurred when a parked party hung up while the parking party was listening to the numbers of the parking stall being assigned, is eliminated. These are the cases where parking code may be activated: 1. Feature one touch (eg. *3) 2. Feature blind xfer to parking lot (eg ##700) 3. Run Park() app from dialplan (eg sip xfer to 700) (eg. dahdi hookflash xfer to 700) 4. Run Park via manager. The interesting testing cases for parking are: I. A calls B, A parks B a. B hangs up while A is getting the numbers announced. b. B hangs up after A gets the announcement, but before the parking time expires c. B waits, time expires, A is redialed, A answers, B and A are connected, after which, B hangs up. d. C picks up B while still in parking lot. II. A calls B, B parks A a. A hangs up while B is getting the numbers announced. b. A hangs up after B gets the announcement, but before the parking time expires c. A waits, time expires, B is redialed, B answers, A and B are connected, after which, A hangs up. d. C picks up A while still in parking lot. Testing this throroughly involves acting all the permutations of I and II, in situations 1,2,3, and 4. Since I added a few more changes (ALL references to KEEPALIVE in the bridge code eliimated (I missed one earlier), I retested most of the above cases, and no crashes. H-extension weirdness. Current h-extension execution is not completely correct for several of the cases. For the case where A calls B, and A parks B, the 'h' exten is run on A's channel as soon as the park is accomplished. This is expected behavior. But when A calls B, and B parks A, this will be current behavior: After B parks A, B is hung up by the system, and the 'h' (hangup) exten gets run, but the channel mentioned will be a derivative of A's... Thus, if A is DAHDI/1, and B is DAHDI/2, the h-extension will be run on channel Parked/DAHDI/1-1<ZOMBIE>, and the start/answer/end info will be those relating to Channel A. And, in the case where A is reconnected to B after the park time expires, when both parties hang up after the joyful reunion, no h-exten will be run at all. In the case where C picks up A from the parking lot, when either A or C hang up, the h-exten will be run for the C channel. CDR's are a separate issue, and not addressed here. As to WHY this strange behavior occurs, the answer lies in the procedure followed to accomplish handing over the channel to the parking manager thread. This procedure is called masquerading. In the process, a duplicate copy of the channel is created, and most of the active data is given to the new copy. The original channel gets its name changed to XXX<ZOMBIE> and keeps the PBX information for the sake of the original thread (preserving its role as a call originator, if it had this role to begin with), while the new channel is without this info and becomes a call target (a "peer"). In this case, the parking lot manager thread is handed the new (masqueraded) channel. It will not run an h-exten on the channel if it hangs up while in the parking lot. The h exten will be run on the original channel instead, in the original thread, after the bridge completes. See bug 13820 for our intentions as to how to clean up the h exten behavior. Review: http://reviewboard.digium.com/r/29/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@166729 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-18Merged revisions 165723 via svnmerge from russell1-22/+27
https://origsvn.digium.com/svn/asterisk/trunk ........ r165723 | russell | 2008-12-18 13:33:42 -0600 (Thu, 18 Dec 2008) | 14 lines Remove the need for AST_PBX_KEEPALIVE with the GoSub option from Dial. This is part of an effort to completely remove AST_PBX_KEEPALIVE and other similar return codes from the source. While this usage was perfectly safe, there are others that are problematic. Since we know ahead of time that we do not want to PBX to destroy the channel, the PBX API has been changed so that information can be provided as an argument, instead, thus removing the need for the KEEPALIVE return value. Further changes to get rid of KEEPALIVE and related code is being done by murf. There is a patch up for that on review 29. Review: http://reviewboard.digium.com/r/98/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@165726 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-16Merged revisions 164801 via svnmerge from murf1-6/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r164801 | murf | 2008-12-16 13:04:46 -0700 (Tue, 16 Dec 2008) | 36 lines (closes issue #14076) Reported by: toc Tested by: murf OK, Well this issue has had its share of flip-flopping. I found the following: 1. the code in question, in ext_cmp1 in pbx.c, would not allow two extensions that vary only by any dashes contained within them, to be defined in the same context. 2. for input dialstrings, dashes are NOT ignored. So, skipping them when sorting patterns seemed a bit silly. Thus, you might declare ext 891 in a context, but if you try dialing 8-9-1, it will NOT match 891. So, I proposed to remove the code from ext_cmp1 to skip the spaces and dashes. Just kept us from declaring 891 and 8-9-1 in the same context, forcing users to generate otherwise uselessly obfuscated dialplan code to get the same effect. Then, I tried out 1.4, and found that: 1. you can declare 891 and 8-9-1 in the same context! 2. You can't define 891, and have 8-9-1 match it! Nor can you define 8-9-1, and have 891 match it! So, it appears that my proposal simply restores the pbx to behaving as it did in 1.4. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@164803 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-16Merged revisions 164648 via svnmerge from murf1-1/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r164648 | murf | 2008-12-16 08:31:54 -0700 (Tue, 16 Dec 2008) | 13 lines Merged revisions 164634 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r164634 | murf | 2008-12-16 08:15:58 -0700 (Tue, 16 Dec 2008) | 5 lines I added a sentence to clarify why - and ' ' are ignored in patterns as per bug 14076. Leif says he'll put some stuff about it in the extensions.conf sample, etc. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@164654 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Merged revisions 162266 via svnmerge from mmichelson1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r162266 | mmichelson | 2008-12-09 14:30:07 -0600 (Tue, 09 Dec 2008) | 14 lines Merged revisions 162265 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r162265 | mmichelson | 2008-12-09 14:28:44 -0600 (Tue, 09 Dec 2008) | 6 lines If we fail to start a thread for the pbx to run in, we need to be sure to decrease the number of active calls on the system. This fix may relate to ABE-1713, but it is not certain yet. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@162268 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-05Merged revisions 161288 via svnmerge from russell1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r161288 | russell | 2008-12-05 08:16:24 -0600 (Fri, 05 Dec 2008) | 10 lines Merged revisions 161287 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r161287 | russell | 2008-12-05 08:12:14 -0600 (Fri, 05 Dec 2008) | 2 lines Fix a NULL format string warning found by buildbot. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@161289 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-02Merged revisions ↵tilghman1-1/+1
152969,153122,154264,154268,154366,155399,155863,156166,156295,156690,156756,158066,158082,158540,158602,159276 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r152969 | tilghman | 2008-10-30 15:35:46 -0500 (Thu, 30 Oct 2008) | 10 lines Merged revisions 152958 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r152958 | tilghman | 2008-10-30 15:33:28 -0500 (Thu, 30 Oct 2008) | 3 lines Cannot join detached threads. See http://www.opengroup.org/onlinepubs/000095399/functions/pthread_join.html (Closes issue #13400) ........ ................ r153122 | tilghman | 2008-10-31 11:35:21 -0500 (Fri, 31 Oct 2008) | 10 lines Merged revisions 153114 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r153114 | tilghman | 2008-10-31 11:30:32 -0500 (Fri, 31 Oct 2008) | 3 lines Turn off qualify on uncached realtime peers. (Closes issue #13383) ........ ................ r154264 | tilghman | 2008-11-04 12:59:48 -0600 (Tue, 04 Nov 2008) | 10 lines Recorded merge of revisions 154263 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r154263 | tilghman | 2008-11-04 12:58:05 -0600 (Tue, 04 Nov 2008) | 3 lines Make the monitor thread non-detached, so it can be joined (suggested by Russell on -dev list). ........ ................ r154268 | rmudgett | 2008-11-04 13:07:26 -0600 (Tue, 04 Nov 2008) | 11 lines Merged revisions 154266 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r154266 | rmudgett | 2008-11-04 13:01:08 -0600 (Tue, 04 Nov 2008) | 4 lines JIRA ABE-1703 mISDN sets the channel to the wrong state when it receives the indication AST_CONTROL_RINGING. ........ ................ r154366 | tilghman | 2008-11-04 14:51:18 -0600 (Tue, 04 Nov 2008) | 16 lines Merged revisions 154365 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r154365 | tilghman | 2008-11-04 14:49:33 -0600 (Tue, 04 Nov 2008) | 9 lines On busy systems, it's possible for the values checked within a single line of code to change, unless the structure is locked to ensure a consistent state. (closes issue #13717) Reported by: kowalma Patches: 20081102__bug13717.diff.txt uploaded by Corydon76 (license 14) Tested by: kowalma ........ ................ r155399 | tilghman | 2008-11-07 16:28:58 -0600 (Fri, 07 Nov 2008) | 14 lines Merged revisions 155398 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r155398 | tilghman | 2008-11-07 16:27:32 -0600 (Fri, 07 Nov 2008) | 7 lines Clarify error message. (closes issue #13809) Reported by: denke Patches: 20081104__bug13809.diff.txt uploaded by Corydon76 (license 14) Tested by: denke ........ ................ r155863 | mmichelson | 2008-11-10 15:14:44 -0600 (Mon, 10 Nov 2008) | 22 lines Merged revisions 155861 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r155861 | mmichelson | 2008-11-10 15:07:39 -0600 (Mon, 10 Nov 2008) | 14 lines Channel drivers assume that when their indicate callback is invoked, that the channel on which the callback was called is locked. This patch corrects an instance in chan_agent where a channel's indicate callback is called directly without first locking the channel. This was leading to some observed locking issues in chan_local, but considering that all channel drivers operate under the same expectations, the generic fix in chan_agent is the right way to go. AST-126 ........ ................ r156166 | russell | 2008-11-12 11:38:20 -0600 (Wed, 12 Nov 2008) | 15 lines Merged revisions 156164 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r156164 | russell | 2008-11-12 11:29:52 -0600 (Wed, 12 Nov 2008) | 7 lines Move the sanity check that makes sure "always fork" is not set along with the console option to be after the code that reads options from asterisk.conf. This resolves a situation where Asterisk can start taking up 100% when misconfigured. (Thanks to Bryce Porter (x86 on IRC) for letting me log in to his system to figure out what was causing the 100% CPU problem.) ........ ................ r156295 | tilghman | 2008-11-12 13:28:22 -0600 (Wed, 12 Nov 2008) | 13 lines Merged revisions 156294 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r156294 | tilghman | 2008-11-12 13:26:45 -0600 (Wed, 12 Nov 2008) | 6 lines If the SLA thread is not started, then reload causes a memory leak. (closes issue #13889) Reported by: eliel Patches: app_meetme.c.patch uploaded by eliel (license 64) ........ ................ r156690 | tilghman | 2008-11-13 15:30:41 -0600 (Thu, 13 Nov 2008) | 14 lines Merged revisions 156688 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r156688 | tilghman | 2008-11-13 15:24:00 -0600 (Thu, 13 Nov 2008) | 7 lines Provide more space for all the data which can appear in an originating channel name. (closes issue #13398) Reported by: bamby Patches: manager.c.diff uploaded by bamby (license 430) ........ ................ r156756 | tilghman | 2008-11-13 18:43:13 -0600 (Thu, 13 Nov 2008) | 13 lines Merged revisions 156755 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r156755 | tilghman | 2008-11-13 18:41:37 -0600 (Thu, 13 Nov 2008) | 6 lines ast_waitfordigit() requires that the channel be up, for no good logical reason. This prevents While/EndWhile from working within the "h" extension. Reported by: jgalarneau (for ABE C.2) Fixed by: me ........ ................ r158066 | mmichelson | 2008-11-20 11:39:06 -0600 (Thu, 20 Nov 2008) | 20 lines Merged revisions 158053 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r158053 | mmichelson | 2008-11-20 11:33:06 -0600 (Thu, 20 Nov 2008) | 12 lines Make sure to set the hangup cause on the calling channel in the case that ast_call() fails. For incoming SIP channels, this was causing us to send a 603 instead of a 486 when the call-limit was reached on the destination channel. (closes issue #13867) Reported by: still_nsk Patches: 13867.diff uploaded by putnopvut (license 60) Tested by: blitzrage ........ ................ r158082 | mmichelson | 2008-11-20 11:54:31 -0600 (Thu, 20 Nov 2008) | 24 lines Merged revisions 158071 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r158071 | mmichelson | 2008-11-20 11:48:42 -0600 (Thu, 20 Nov 2008) | 16 lines We don't handle 4XX responses to BYE well. According to section 15 of RFC 3261, we should terminate a dialog if we receive a 481 or 408 in response to our BYE. Since I am aware of at least one phone manufacturer who may sometimes send a 404 as well, I am being liberal and saying that any 4XX response to a BYE should result in a terminated dialog. (closes issue #12994) Reported by: pabelanger Patches: 12994.patch uploaded by putnopvut (license 60) Closes AST-129 ........ ................ r158540 | russell | 2008-11-21 16:12:37 -0600 (Fri, 21 Nov 2008) | 10 lines Merged revisions 158539 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r158539 | russell | 2008-11-21 16:05:55 -0600 (Fri, 21 Nov 2008) | 2 lines When compiling with DEBUG_THREADS, report the real file/func/line for ao2_lock/ao2_unlock ........ ................ r158602 | tilghman | 2008-11-21 17:14:11 -0600 (Fri, 21 Nov 2008) | 12 lines Merged revisions 158600 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r158600 | tilghman | 2008-11-21 17:07:46 -0600 (Fri, 21 Nov 2008) | 5 lines The passed extension may not be the same in the list as the current entry, because we strip spaces when copying the extension into the structure. Therefore, use the copied item to place the item into the list. (found by lmadsen on -dev, fixed by me) ........ ................ r159276 | tilghman | 2008-11-25 15:57:59 -0600 (Tue, 25 Nov 2008) | 14 lines Merged revisions 159269 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r159269 | tilghman | 2008-11-25 15:56:48 -0600 (Tue, 25 Nov 2008) | 7 lines Don't try to send a response on a NULL pvt. (closes issue #13919) Reported by: barthpbx Patches: chan_iax2.c.patch uploaded by eliel (license 64) Tested by: barthpbx ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@160389 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-02Merged revisions 160208 via svnmerge from tilghman1-2/+7
https://origsvn.digium.com/svn/asterisk/trunk ................ r160208 | tilghman | 2008-12-01 18:37:21 -0600 (Mon, 01 Dec 2008) | 10 lines Merged revisions 160207 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r160207 | tilghman | 2008-12-01 18:25:16 -0600 (Mon, 01 Dec 2008) | 3 lines Ensure that Asterisk builds with --enable-dev-mode, even on the latest gcc and glibc. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@160228 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-12Merged revisions 156299 via svnmerge from murf1-3/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r156299 | murf | 2008-11-12 12:47:29 -0700 (Wed, 12 Nov 2008) | 26 lines Merged revisions 156297 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r156297 | murf | 2008-11-12 12:36:16 -0700 (Wed, 12 Nov 2008) | 18 lines It turns out that the 0x0XX00 codes being returned for N, X, and Z are off by one, as per conversation with jsmith on #asterisk-dev; he was teaching a class and disconcerted that this published rule was not being followed, with patterns _NXX, _[1-8]22 and _[2-9]22... and NXX was winning, but [1-8] should have been. This change, tested on these 3 patterns now picks the proper one. However, this change may surprise users who set up dialplans based on previous behavior, which has been there for what, 2 and half years or so now. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@156319 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-09Merged revisions 147807 via svnmerge from murf1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r147807 | murf | 2008-10-09 08:17:33 -0600 (Thu, 09 Oct 2008) | 15 lines (closes issue #13557) Reported by: nickpeirson Patches: pbx.c.patch uploaded by nickpeirson (license 579) replace_bzero+bcopy.patch uploaded by nickpeirson (license 579) Tested by: nickpeirson, murf 1. replaced all refs to bzero and bcopy to memset and memmove instead. 2. added a note to the CODING-GUIDELINES 3. add two macros to asterisk.h to prevent bzero, bcopy from creeping back into the source 4. removed bzero from configure, configure.ac, autoconfig.h.in ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@147809 f38db490-d61c-443f-a65b-d21fe96a405b
2008-09-26Merged revisions 144678 via svnmerge from murf1-0/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r144678 | murf | 2008-09-26 11:50:35 -0600 (Fri, 26 Sep 2008) | 20 lines Merged revisions 144677 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r144677 | murf | 2008-09-26 11:47:13 -0600 (Fri, 26 Sep 2008) | 12 lines (closes issue #13563) Reported by: mnicholson Patches: found1.diff uploaded by mnicholson (license 96) This patch was mainly meant to apply to trunk and 1.6.x, but I'm applying it to 1.4 also, which should be a perfectly harmless fix to the vast majority of users who are not using external switches, but the few who might be affected will not have to go to the pain of filing a bug report. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@144679 f38db490-d61c-443f-a65b-d21fe96a405b
2008-09-25Merged revisions 144569 via svnmerge from murf1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r144569 | murf | 2008-09-25 16:21:28 -0600 (Thu, 25 Sep 2008) | 14 lines (closes issue #13557) Reported by: nickpeirson The user attached a patch, but the license is not yet recorded. I took the liberty of finding and replacing ALL index() calls with strchr() calls, and that involves more than just main/pbx.c; chan_oss, app_playback, func_cut also had calls to index(), and I changed them out. 1.4 had no references to index() at all. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@144570 f38db490-d61c-443f-a65b-d21fe96a405b
2008-09-12Merged revisions 142676 via svnmerge from murf1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r142676 | murf | 2008-09-11 22:50:48 -0600 (Thu, 11 Sep 2008) | 40 lines Merged revisions 142675 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines Tested by: sergee, murf, chris-mac, andrew, KNK This is a "second attempt" to restore the previous "endbeforeh" behavior in 1.4 and up. In order to capture information concerning all the legs of transfers in all their infinite combinations, I was forced to this particular solution by a chain of logical necessities, the first being that I was not allowed to rewrite the CDR mechanism from the ground up! This change basically leaves the original machinery alone, which allows IVR and local channel type situations to generate CDR's as normal, but a channel flag can be set to suppress the normal running of the h exten. That flag would be set by the code that runs the h exten from the ast_bridge_call routine, to prevent the h exten from being run twice. Also, a flag in the ast_bridge_config struct passed into ast_bridge_call can be used to suppress the running of the h exten in that routine. This would happen, for instance, if you use the 'g' option in the Dial app. Running this routine 'early' allows not only the CDR() func to be used in the h extension for reading CDR variables, but also allows them to be modified before the CDR is posted to the backends. While I dearly hope that this patch overcomes all problems, and introduces no new problems, reality suggests that surely someone will have problems. In this case, please re-open 13251 (or 13289), and we'll see if we can't fix any remaining issues. ** trunk note: some code to suppress the h exten being run from app_queue was added; for the 'continue' option available only in trunk/1.6.x. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@142677 f38db490-d61c-443f-a65b-d21fe96a405b
2008-09-08Merged revisions 141807 via svnmerge from russell1-9/+15
https://origsvn.digium.com/svn/asterisk/trunk ................ r141807 | russell | 2008-09-08 16:05:01 -0500 (Mon, 08 Sep 2008) | 15 lines Merged revisions 141806 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141806 | russell | 2008-09-08 16:02:36 -0500 (Mon, 08 Sep 2008) | 7 lines When doing an async goto, detect if the channel is already in the middle of a masquerade. This can happen when chan_local is trying to optimize itself out. If this happens, fail the async goto instead of bursting into flames. (closes issue #13435) Reported by: geoff2010 ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@141808 f38db490-d61c-443f-a65b-d21fe96a405b
2008-09-03Merged revisions 140691 via svnmerge from murf1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r140691 | murf | 2008-09-02 16:50:59 -0600 (Tue, 02 Sep 2008) | 22 lines Merged revisions 140670 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r140670 | murf | 2008-09-02 16:15:57 -0600 (Tue, 02 Sep 2008) | 14 lines (closes issue #13409) Reported by: tomaso Patches: asterisk-1.6.0-rc2-cdrmemleak.patch uploaded by tomaso (license 564) I basically spent the day, verifying that this patch solves the problem, and doesn't hurt in non-problem cases. Why valgrind did not plainly reveal this leak absolutely mystifies and stuns me. Many, many thanks to tomaso for finding and providing the fix. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@140825 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-25Merged revisions 139770 via svnmerge from murf1-4/+0
https://origsvn.digium.com/svn/asterisk/trunk ................ r139770 | murf | 2008-08-25 09:54:18 -0600 (Mon, 25 Aug 2008) | 17 lines Merged revisions 139764 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r139764 | murf | 2008-08-25 09:33:14 -0600 (Mon, 25 Aug 2008) | 9 lines This patch reverts the changes made via 139347, and 139635, as users are seeing adverse difference. I will un-close 13251. Back to the drawing board/ concept/ beginning/ whatever! ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@139774 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-22Merged revisions 139627 via svnmerge from murf1-0/+4
https://origsvn.digium.com/svn/asterisk/trunk ................ r139627 | murf | 2008-08-22 16:03:13 -0600 (Fri, 22 Aug 2008) | 59 lines Merged revisions 139347 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r139347 | murf | 2008-08-21 17:03:50 -0600 (Thu, 21 Aug 2008) | 47 lines (closes issue #13251) Reported by: sergee Tested by: murf THis is a bold move for a static release fix, but I wouldn't have made it if I didn't feel confident (at least a *bit* confident) that it wouldn't mess everyone up. The reasoning goes something like this: 1. We simply cannot do anything with CDR's at the current point (in pbx.c, after the __ast_pbx_run loop). It's way too late to have any affect on the CDRs. The CDR is already posted and gone, and the remnants have been cleared. 2. I was very much afraid that moving the running of the 'h' extension down into the bridge code (where it would be now practical to do it), would result in a lot more calls to the 'h' exten, so I implemented it as another exten under another name, but found, to my pleasant surprise, that there was a 1:1 correspondence to the running of the 'h' exten in the pbx_run loop, and the new spot at the end of the bridge. So, I ifdef'd out the current 'h' loop, and moved it into the bridge code. The only difference I can see is the stuff about the AST_PBX_KEEPALIVE, and hopefully, if this is still an important decision point, I can replicate it if there are complaints. To be perfectly honest, the KEEPALIVE situation is not totally clear to me, and how it relates to a post-bridge situation is less clear. I suspect the users will point out everything in total clarity if this steps on anyone's toes! 3. I temporarily swap the bridge_cdr into the channel before running the 'h' exten, which makes it possible for users to edit the cdr before it goes out the door. And, of course, with the endbeforehexten config var set, the users can also get at the billsec/duration vals. After the h exten finishes, the cdr is swapped back and processing continues as normal. Please, all who deal with CDR's, please test this version of Asterisk, and file bug reports as appropriate! ........ I also made a little fix to the app_dial's 'e' option, that is related to my updates. ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@139628 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-19Merged revisions 138815 via svnmerge from murf1-1/+7
https://origsvn.digium.com/svn/asterisk/trunk ........ r138815 | murf | 2008-08-19 09:59:12 -0600 (Tue, 19 Aug 2008) | 19 lines These changes are in regards to bug 13249, where users are being surprised by the changes made to the Set app in trunk/1.6.x, as they come from the 1.4 world. They are only bitten if they write their AEL dialplan in the 1.4 world, and then carry it over to a trunk/1.6.x installation where a "make samples" was executed, or where they hand-edited the asterisk.conf file and added the [compat] category with app_set = 1.6 (or higher). (this commit does not totally solve 13249, at least not yet) The change involves issueing a single warning while the AEL file is loading, if: 1. app_set is present in the config file, and set to 1.6 or higher. 2. there are double quotes in an assignment statement (eg x = "hi there";) 3. the warning was not already issued. The standalone app, aelparse, does not (yet) issue this warning. I'd have to have it read in the asterisk.conf file, and that's a bit of hassle. I'll add it if users request it, tho. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@138846 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-15Merged revisions 138206 via svnmerge from tilghman1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r138206 | tilghman | 2008-08-15 15:35:24 -0500 (Fri, 15 Aug 2008) | 4 lines Remove deprecated syntax from sample config file (closes issue #13314) Reported by: kue ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@138207 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-07Merged revisions 136635 via svnmerge from mmichelson1-0/+4
https://origsvn.digium.com/svn/asterisk/trunk ........ r136635 | mmichelson | 2008-08-07 14:58:32 -0500 (Thu, 07 Aug 2008) | 5 lines Don't allow Answer() to accept a negative argument. Negative argument means an infinite delay and we don't want that. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@136636 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-02Merged revisions 135265 via svnmerge from murf1-0/+5
https://origsvn.digium.com/svn/asterisk/trunk ........ r135265 | murf | 2008-08-01 22:51:29 -0600 (Fri, 01 Aug 2008) | 31 lines (closes issue #13202) Reported by: falves11 Tested by: murf falves11 == The changes I introduce here seem to clear up the problem for me. However, if they do not for you, please reopen this bug, and we'll keep digging. The root of this problem seems to be a subtle memory corruption introduced when creating an extension with an empty extension name. While valgrind cannot detect it outside of DEBUG_MALLOC mode, when compiled with DEBUG_MALLOC, this is certain death. The code in main/features.c is a puzzle to me. On the initial module load, the code is attempting to add the parking extension before the features.conf file has even been opened! I just wrapped the offending call with an if() that will not try to add the extension if the extension name is empty. THis seems to solve the corruption, and let the "memory show allocations" work as one would expect. But, really, adding an extension with an empty name is a seriously bad thing to allow, as it will mess up all the pattern matching algorithms, etc. So, I added a statement to the add_extension2 code to return a -1 if this is attempted. in 1.6.0, the changes to only main/pbx.c were applicable, as apparently the code added to main/features by jpeeler were not included in 1.6.0. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@135266 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-21 16:08:12 +0000