https://origsvn.digium.com/svn/asterisk/trunk
................
r262422 | qwell | 2010-05-11 14:57:24 -0500 (Tue, 11 May 2010) | 18 lines
Merged revisions 262421 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r262421 | qwell | 2010-05-11 14:55:42 -0500 (Tue, 11 May 2010) | 11 lines
Use a less silly method for modifying a flex-generated file.
The sed syntax that was used wasn't actually valid, causing some versions to
choke. This is the method that is used in 1.6.x+ for similar changes.
(closes issue #16696)
Reported by: bklang
Patches:
16696-sedfix.diff uploaded by qwell (license 4)
Tested by: qwell
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@262425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r260346 | mmichelson | 2010-04-30 15:11:02 -0500 (Fri, 30 Apr 2010) | 24 lines
Merged revisions 260345 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260345 | mmichelson | 2010-04-30 15:08:15 -0500 (Fri, 30 Apr 2010) | 18 lines
Fix potential crash from race condition due to accessing channel data without the channel locked.
In res_musiconhold.c, there are several places where a channel's
stream's existence is checked prior to calling ast_closestream on it. The issue
here is that in several cases, the channel was not locked while checking the
stream. The result was that if two threads checked the state of the channel's
stream at approximately the same time, then there could be a situation where
both threads attempt to call ast_closestream on the channel's stream. The result
here is that the refcount for the stream would go below 0, resulting in a crash.
I have added proper channel locking to res_musiconhold.c to ensure that
we do not try to check chan->stream without the channel locked. A Digium customer
has been using this patch for several weeks and has not had any crashes since
applying the patch.
ABE-2147
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260373 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r254277 | jpeeler | 2010-03-24 12:15:05 -0500 (Wed, 24 Mar 2010) | 78 lines
Merged revisions 254235 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r254235 | jpeeler | 2010-03-23 19:37:23 -0500 (Tue, 23 Mar 2010) | 72 lines
Ensure that monitor recordings are written to the correct location (again)
This is an extension to 248860. As such the dialplan test has been extended:
; non absolute path, not combined
exten => 5040, 1, monitor(wav,tmp/jeff/monitor_test)
exten => 5040, n, dial(sip/5001)
; absolute path, not combined
exten => 5041, 1, monitor(wav,/tmp/jeff/monitor_test2)
exten => 5041, n, dial(sip/5001)
; no path, not combined
exten => 5042, 1, monitor(wav,monitor_test3)
exten => 5042, n, dial(sip/5001)
; combined: changemonitor from non absolute to no path (leaves tmp/jeff)
exten => 5043, 1, monitor(wav,tmp/jeff/monitor_test4,m)
exten => 5043, n, changemonitor(monitor_test5)
exten => 5043, n, dial(sip/5001)
; combined: changemonitor from no path to non absolute path
exten => 5044, 1, monitor(wav,monitor_test6,m)
exten => 5044, n, changemonitor(tmp/jeff/monitor_test7) ; this wasn't possible before
exten => 5044, n, dial(sip/5001)
; non absolute path, combined
exten => 5045, 1, monitor(wav,tmp/jeff/monitor_test8,m)
exten => 5045, n, dial(sip/5001)
; absolute path, combined
exten => 5046, 1, monitor(wav,/tmp/jeff/monitor_test9,m)
exten => 5046, n, dial(sip/5001)
; no path, combined
exten => 5047, 1, monitor(wav,monitor_test10,m)
exten => 5047, n, dial(sip/5001)
; combined: changemonitor from non absolute to absolute (leaves tmp/jeff)
exten => 5048, 1, monitor(wav,tmp/jeff/monitor_test11,m)
exten => 5048, n, changemonitor(/tmp/jeff/monitor_test12)
exten => 5048, n, dial(sip/5001)
; combined: changemonitor from absolute to non absolute (leaves /tmp/jeff)
exten => 5049, 1, monitor(wav,/tmp/jeff/monitor_test13,m)
exten => 5049, n, changemonitor(tmp/jeff/monitor_test14)
exten => 5049, n, dial(sip/5001)
; combined: changemonitor from no path to absolute
exten => 5050, 1, monitor(wav,monitor_test15,m)
exten => 5050, n, changemonitor(/tmp/jeff/monitor_test16)
exten => 5050, n, dial(sip/5001)
; combined: changemonitor from absolute to no path (leaves /tmp/jeff)
exten => 5051, 1, monitor(wav,/tmp/jeff/monitor_test17,m)
exten => 5051, n, changemonitor(monitor_test18)
exten => 5051, n, dial(sip/5001)
; not combined: changemonitor from non absolute to no path (leaves tmp/jeff)
exten => 5052, 1, monitor(wav,tmp/jeff/monitor_test19)
exten => 5052, n, changemonitor(monitor_test20)
exten => 5052, n, dial(sip/5001)
; not combined: changemonitor from no path to non absolute
exten => 5053, 1, monitor(wav,monitor_test21)
exten => 5053, n, changemonitor(tmp/jeff/monitor_test22)
exten => 5053, n, dial(sip/5001)
; not combined: changemonitor from non absolute to absolute (leaves tmp/jeff)
exten => 5054, 1, monitor(wav,tmp/jeff/monitor_test23)
exten => 5054, n, changemonitor(/tmp/jeff/monitor_test24)
exten => 5054, n, dial(sip/5001)
; not combined: changemonitor from absolute to non absolute (leaves /tmp/jeff)
exten => 5055, 1, monitor(wav,/tmp/jeff/monitor_test24)
exten => 5055, n, changemonitor(tmp/jeff/monitor_test25)
exten => 5055, n, dial(sip/5001)
; not combined: changemonitor from no path to absolute
exten => 5056, 1, monitor(wav,monitor_test26)
exten => 5056, n, changemonitor(/tmp/jeff/monitor_test27)
exten => 5056, n, dial(sip/5001)
; not combined: changemonitor from absolute to no path (leaves /tmp/jeff)
exten => 5057, 1, monitor(wav,/tmp/jeff/monitor_test28)
exten => 5057, n, changemonitor(monitor_test29)
exten => 5057, n, dial(sip/5001)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@254288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r252848 | seanbright | 2010-03-16 15:36:24 -0400 (Tue, 16 Mar 2010) | 10 lines
Include an extra newline after "Aliased CLI command" to get back the prompt.
The other issue mentioned in this bug will be more difficult to resolve since we
have no idea (right now) of knowing if the command that is aliased has been
installed yet.
(issue #16978)
Reported by: jw-asterisk
Tested by: seanbright
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@252850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r248952 | jpeeler | 2010-02-25 17:09:54 -0600 (Thu, 25 Feb 2010) | 24 lines
Merged revisions 248860 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r248860 | jpeeler | 2010-02-25 15:22:06 -0600 (Thu, 25 Feb 2010) | 18 lines
Ensure that monitor recordings are written to the correct location (again)
This is an extension to 248757. As such the dialplan test has been extended:
exten => 5040, 1, monitor(wav,tmp/jeff/monitor_test,b)
exten => 5040, n, dial(sip/5001)
exten => 5041, 1, monitor(wav,/tmp/jeff/monitor_test2,b)
exten => 5041, n, dial(sip/5001)
exten => 5042, 1, monitor(wav,monitor_test3,b)
exten => 5042, n, dial(sip/5001)
exten => 5043, 1, monitor(wav,tmp/jeff/monitor_test3,m)
exten => 5043, n, changemonitor(monitor_test4)
exten => 5043, n, dial(sip/5001)
exten => 5044, 1, monitor(wav,monitor_test4,m)
exten => 5044, n, changemonitor(tmp/jeff/monitor_test5) ; this looks to fail by design and emits a warning
exten => 5044, n, dial(sip/5001)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@248955 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r248793 | jpeeler | 2010-02-25 12:37:56 -0600 (Thu, 25 Feb 2010) | 22 lines
Merged revisions 248757 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r248757 | jpeeler | 2010-02-25 12:06:54 -0600 (Thu, 25 Feb 2010) | 15 lines
Ensure that monitor recordings are written to the correct location.
Recordings should be placed in the monitor directory when a non-absolute path
is used.
Exact dialplan used for testing:
exten => 5040, 1, monitor(wav,tmp/jeff/monitor_test,b)
exten => 5040, n, dial(sip/5001)
exten => 5041, 1, monitor(wav,/tmp/jeff/monitor_test2,b)
exten => 5041, n, dial(sip/5001)
exten => 5042, 1, monitor(wav,monitor_test3,b)
exten => 5042, n, dial(sip/5001)
ABE-2101
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@248797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r246030 | tilghman | 2010-02-10 10:01:28 -0600 (Wed, 10 Feb 2010) | 12 lines
Solaris doesn't like outputting a NULL to a %s in format strings.
Detect all platforms that don't like that, either, and ensure that when documentation is
missing, we pass a non-NULL pointer when outputting the corresponding documentation.
(closes issue #16689)
Reported by: bklang
Patches:
20100209__issue16689__with_tests.diff.txt uploaded by tilghman (license 14)
Review: https://reviewboard.asterisk.org/r/497/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@246199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r242521 | tilghman | 2010-01-24 00:40:31 -0600 (Sun, 24 Jan 2010) | 15 lines
Merged revisions 242520 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r242520 | tilghman | 2010-01-24 00:33:01 -0600 (Sun, 24 Jan 2010) | 8 lines
Only rebuild bison and flex source files on demand, if bison and flex are detected by the configure script.
Changed after discussion on the -dev list about possible unnecessary build
failures, due to checkouts/untars causing these special source files to
possibly be newer than their resulting C files. This should additionally
ensure that nobody need learn about extra Makefile arguments to ensure the
proper files get rebuilt when changes are made to these special source files.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@242522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r237406 | tilghman | 2010-01-04 12:28:28 -0600 (Mon, 04 Jan 2010) | 23 lines
Merged revisions 237405 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r237405 | tilghman | 2010-01-04 12:19:00 -0600 (Mon, 04 Jan 2010) | 16 lines
Add a flag to disable the Background behavior, for AGI users.
This is in a section of code that relates to two other issues, namely
issue #14011 and issue #14940), one of which was the behavior of
Background when called with a context argument that matched the current
context. This fix broke FreePBX, however, in a post-Dial situation.
Needless to say, this is an extremely difficult collision of several
different issues. While the use of an exception flag is ugly, fixing all
of the issues linked is rather difficult (although if someone would like
to propose a better solution, we're happy to entertain that suggestion).
(closes issue #16434)
Reported by: rickead2000
Patches:
20091217__issue16434.diff.txt uploaded by tilghman (license 14)
20091222__issue16434__1.6.1.diff.txt uploaded by tilghman (license 14)
Tested by: rickead2000
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@237409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r235941 | jpeeler | 2009-12-21 13:54:20 -0600 (Mon, 21 Dec 2009) | 20 lines
Merged revisions 235940 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r235940 | jpeeler | 2009-12-21 13:43:41 -0600 (Mon, 21 Dec 2009) | 13 lines
Change Monitor to not assume file to write to does not contain pathing.
227944 changed the fname_base argument to always append the configured monitor
path. This change was necessary to properly compare files for uniqueness.
If a full path is given though, nothing needs to be appended and that is
handled correctly now.
(closes issue #16377)
(closes issue #16376)
Reported by: bcnit
Patches:
res_monitor.c-issue16376-1.patch uploaded by dant (license 670)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@235944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r232660 | tilghman | 2009-12-02 18:08:55 -0600 (Wed, 02 Dec 2009) | 19 lines
Fix multiple issues with musiconhold, which led to classes not getting destroyed properly.
* Classes are now tracked past removal from the core container, and module
removal is actively prevented until all references are freed.
* A hanging reference stored in the channel has been removed. This could have
caused a mismatch and the music state not properly cleared, if two or more
reloads occurred between MOH being stopped and MOH being restarted.
* In certain circumstances, duplicate classes were possible.
* A race existed at reload time between a process being killed and the thread
responsible for reading from the related pipe respawning that process.
* Several reference counts have also been corrected. At least one could have
caused deleted classes to stick around forever, consuming resources. This
originally manifested as MOH external processes that were not killed at
reload time.
(closes issue #16279, closes issue #16207)
Reported by: parisioa, dcabot
Patches:
20091202__issue16279__2.diff.txt uploaded by tilghman (license 14)
Tested by: parisioa, tilghman
........
r232661 | tilghman | 2009-12-02 18:09:36 -0600 (Wed, 02 Dec 2009) | 2 lines
Remove debugging line
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@232675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r229093 | dvossel | 2009-11-10 09:27:45 -0600 (Tue, 10 Nov 2009) | 11 lines
fixes pgsql double free of threadstorage
A thread storage variable was being freed incorrectly, which
resulted in a double free if two queries were made in the same thread.
(closes issue #16011)
Reported by: cristiandimache
Patches:
issue16011.diff uploaded by dvossel (license 671)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@229094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r227945 | jpeeler | 2009-11-04 17:50:59 -0600 (Wed, 04 Nov 2009) | 21 lines
Merged revisions 227944 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r227944 | jpeeler | 2009-11-04 17:47:08 -0600 (Wed, 04 Nov 2009) | 14 lines
Fix incorrect filename comparsion after monitor file change
The logic to detect if a requested file is indeed a different file from the
current file was incorrect. The main issue being confusion of the use of
filename_base which was previously set without pathing information and then
compared to another full path. Robust file comparison logic has been added
to properly check if two files are the same even if symlinks are used.
(closes issue #15313)
Reported by: caspy
Patches:
20091103__issue15313__1.4.diff.txt uploaded by jpeeler (license 325)
but mostly tilghman's work
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@227947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r222309 | tilghman | 2009-10-06 14:31:39 -0500 (Tue, 06 Oct 2009) | 10 lines
Change schema query to involve the use of an optional schema parameter.
This change is done in such a way as to allow the driver to continue to
function with older databases which don't have these features.
(closes issue #16000)
Reported by: jamicque
Patches:
20091002__issue16000.diff.txt uploaded by tilghman (license 14)
20091002__issue16000__1.6.1.diff.txt uploaded by tilghman (license 14)
Tested by: jamicque
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r222273 | tilghman | 2009-10-06 14:17:11 -0500 (Tue, 06 Oct 2009) | 5 lines
When we call a gosub routine, the variables should be scoped to avoid contaminating the caller.
This affected the ~~EXTEN~~ hack, where a subroutine might have changed the
value before it was used in the caller.
Patch by myself, tested by ebroad on #asterisk
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r222176 | kpfleming | 2009-10-05 20:24:24 -0500 (Mon, 05 Oct 2009) | 27 lines
Recorded merge of revisions 222152 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222152 | kpfleming | 2009-10-05 20:16:36 -0500 (Mon, 05 Oct 2009) | 20 lines
Fix ao2_iterator API to hold references to containers being iterated.
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r207680 | kpfleming | 2009-07-21 08:28:04 -0500 (Tue, 21 Jul 2009) | 18 lines
Merged revisions 207647 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207647 | kpfleming | 2009-07-21 08:04:44 -0500 (Tue, 21 Jul 2009) | 12 lines
Ensure that user-provided CFLAGS and LDFLAGS are honored.
This commit changes the build system so that user-provided flags (in ASTCFLAGS
and ASTLDFLAGS) are supplied to the compiler/linker *after* all flags provided
by the build system itself, so that the user can effectively override the
build system's flags if desired. In addition, ASTCFLAGS and ASTLDFLAGS can now
be provided *either* in the environment before running 'make', or as variable
assignments on the 'make' command line. As a result, the use of COPTS and LDOPTS
is no longer necessary, so they are no longer documented, but are still supported
so as not to break existing build systems that supply them when building Asterisk.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@207685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r205120 | russell | 2009-07-08 10:17:19 -0500 (Wed, 08 Jul 2009) | 16 lines
Move OpenSSL initialization to a single place, make library usage thread-safe.
While doing some reading about OpenSSL, I noticed a couple of things that
needed to be improved with our usage of OpenSSL.
1) We had initialization of the library done in multiple modules. This has now
been moved to a core function that gets executed during Asterisk startup.
We already link OpenSSL into the core for TCP/TLS functionality, so this
was the most logical place to do it.
2) OpenSSL is not thread-safe by default. However, making it thread safe is
very easy. We just have to provide a couple of callbacks. One callback
returns a thread ID. The other handles locking. For more information,
start with the "Is OpenSSL thread-safe?" question on the FAQ page of
openssl.org.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@205148 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r201610 | russell | 2009-06-18 10:27:10 -0500 (Thu, 18 Jun 2009) | 36 lines
Merged revisions 201600 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r201600 | russell | 2009-06-18 10:24:31 -0500 (Thu, 18 Jun 2009) | 29 lines
Fix memory corruption and leakage related reloads of non files mode MoH classes.
For Music on Hold classes that are not files mode, meaning that we are executing
an application that will feed us audio data, we use a thread to monitor the
external application and read audio from it. This thread also makes use of the
MoH class object. In the MoH class destructor, we used pthread_cancel() to ask
the thread to exit. Unfortunately, the code did not wait to ensure that the
thread actually went away. What needed to be done is a pthread_join() to ensure
that the thread fully cleans up before we proceed. By adding this one line, we
resolve two significant problems:
1) Since the thread was never joined, it never fully goes away. So, on every
reload of non-files mode MoH, an unused thread was sticking around.
2) There was a race condition here where the application monitoring thread
could still try to access the MoH class, even though the thread executing
the MoH reload has already destroyed it.
(issue #15109)
Reported by: jvandal
(issue #15123)
Reported by: axisinternet
(issue #15195)
Reported by: amorsen
(issue AST-208)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@201614 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r199743 | dvossel | 2009-06-09 11:22:04 -0500 (Tue, 09 Jun 2009) | 11 lines
module load priority
This patch adds the option to give a module a load priority. The value represents the order in which a module's load() function is initialized. The lower the value, the higher the priority. The value is only checked if the AST_MODFLAG_LOAD_ORDER flag is set. If the AST_MODFLAG_LOAD_ORDER flag is not set, the value will never be read and the module will be given the lowest possible priority
on load. Since some modules are reliant on a timing interface, the timing modules have been given a high load priorty.
(closes issue #15191)
Reported by: alecdavis
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/262/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@199744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r198375 | seanbright | 2009-05-30 16:11:33 -0400 (Sat, 30 May 2009) | 13 lines
Properly terminate the receive buffer before sending to iksemel.
aji_io_recv takes the maximum number of bytes to read (instead of the total
buffer size), so we have to subtract 1 from our buffer size. Without this, when
we receive packets that are larger than our buffer, iksemel will choke and
things get wonky.
(closes issue #15232)
Reported by: lp0
Patches:
05302009_res_jabber.c.patch uploaded by seanbright (license 71)
Tested by: seanbright, lp0
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@198397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r198146 | russell | 2009-05-29 15:06:59 -0500 (Fri, 29 May 2009) | 38 lines
Resolve issues with choppy sound when using res_timing_pthread.
The situation that caused this problem was when continuous mode was being
turned on and off while a rate was set for a timing interface. A very easy
way to replicate this bug was to do a Playback() from behind a Local channel.
In this scenario, a rate gets set on the channel for doing file playback.
At the same time, continuous mode gets turned on and off about every 20 ms
as frames get queued on to the PBX side channel from the other side of the
Local channel.
Essentially, this module treated continuous mode and a set rate as mutually
exclusive states for the timer to be in. When I dug deep enough, I observed
the following pattern:
1) Set timer to tick every 20 ms.
2) Wait almost 20 ms ...
3) Continuous mode gets turned on for a queued up frame
4) Continuous mode gets turned off
5) The timer goes back to its tick per 20 ms. state but starts counting
at 0 ms.
6) Goto step 2.
Sometimes, res_timing_pthread would make it 20 ms and produce a timer tick,
but not most of the time. This is what produced the choppy sound (or sometimes
no sound at all).
Now, the module treats continuous mode and a set rate as completely independent
timer modes. They can be enabled and disabled independently of each other and
things work as expected.
(closes issue #14412)
Reported by: dome
Patches:
issue14412.diff.txt uploaded by russell (license 2)
issue14412-1.6.1.0.diff.txt uploaded by russell (license 2)
Tested by: DennisD, russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@198148 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r196843 | russell | 2009-05-26 13:20:57 -0500 (Tue, 26 May 2009) | 16 lines
Merged revisions 196826 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r196826 | russell | 2009-05-26 13:14:36 -0500 (Tue, 26 May 2009) | 9 lines
Resolve a file handle leak.
The frames here should have always been freed. However, out of luck, there was
never any memory leaked. However, after file streams became reference counted,
this code would leak the file stream for the file being read.
(closes issue #15181)
Reported by: jkroon
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@196870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r193718 | russell | 2009-05-11 17:04:40 -0500 (Mon, 11 May 2009) | 12 lines
Fix some timer state corruption.
In res_timer_timerfd, handle the case that set_rate gets called while a timer
is still in continuous mode. In this case, we want to remember the configured
rate, but not actually set it until continuous mode has been disabled.
Thanks to dvossel for finding and helping to debug the problem.
(closes issue #15080)
Reported by: dvossel
Tested by: dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@193719 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r190663 | russell | 2009-04-27 14:08:12 -0500 (Mon, 27 Apr 2009) | 22 lines
Merged revisions 190661-190662 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r190661 | russell | 2009-04-27 14:00:54 -0500 (Mon, 27 Apr 2009) | 9 lines
Resolve a crash in res_smdi when used with chan_dahdi.
When chan_dahdi goes to get an SMDI message, it provides no search criteria.
It just grabs the next message that arrives. This code was written with the
SMDI dialplan functions in mind, since that is now the preferred method of
using SMDI. However, this broke support of it being used from chan_dahdi.
(closes AST-212)
........
r190662 | russell | 2009-04-27 14:03:59 -0500 (Mon, 27 Apr 2009) | 2 lines
Fix a typo from 190661.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@190666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r189464 | seanbright | 2009-04-20 17:09:59 -0400 (Mon, 20 Apr 2009) | 20 lines
Merged revisions 189462 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r189462 | seanbright | 2009-04-20 16:58:39 -0400 (Mon, 20 Apr 2009) | 13 lines
Properly handle @s within hints in AEL.
AEL was not handling the case of a device hint containing an @ symbol, which
caused parking hints (e.g. hint(park:exten@context)) to error out the parser.
This patch makes AEL treat the @ the same way it treats colon and ampersand
now, meaning the characters are included in verbatim.
(closes issue #14941)
Reported by: bpgoldsb
Patches:
bug14941.patch uploaded by seanbright (license 71)
Tested by: bpgoldsb
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@189533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r187421 | mmichelson | 2009-04-09 12:30:39 -0500 (Thu, 09 Apr 2009) | 21 lines
Fix a crash in res_musiconhold when using cached realtime moh.
The moh_register function links an mohclass and then immediately
unrefs the class since the container now has a reference. The problem
with using realtime music on hold is that the class is allocated,
registered, and started in one fell swoop. The refcounting logic
resulted in the count being off by one. The same problem did not
happen when using a static config because the allocation and registration
of an mohclass is a separate operation from starting moh. This also did
not affect non-cached realtime moh because the classes are not registered
at all.
I also have modified res_musiconhold to use the _t_ variants of the ao2_
functions so that more info can be gleaned when attempting to trace the
refcounts. I found this to be incredibly helpful for debugging this issue
and there's no good reason to remove it.
(closes issue #14661)
Reported by: sum
........
r187424 | mmichelson | 2009-04-09 12:34:39 -0500 (Thu, 09 Apr 2009) | 3 lines
Use safe macro practices even though they really aren't necessary.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@187496 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r187046 | mmichelson | 2009-04-08 11:52:20 -0500 (Wed, 08 Apr 2009) | 16 lines
Merged revisions 187045 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r187045 | mmichelson | 2009-04-08 11:52:03 -0500 (Wed, 08 Apr 2009) | 10 lines
Fix a small logical error when loading moh classes.
We were unconditionally incrementing the number of mohclasses
registered. However, we should actually only increment if the
call to moh_register was successful.
While this probably has never caused problems, I noticed it
and decided to fix it anyway.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@187049 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184673 | file | 2009-03-27 12:46:46 -0300 (Fri, 27 Mar 2009) | 7 lines
Fix speech structure leak in the AGI speech recognition integration.
The AGI dialplan applications did not destroy the speech structure automatically
if it was not destroyed by the running AGI script. They will now do this.
(issue LUMENVOX-15)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@184676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184339 | russell | 2009-03-25 16:57:19 -0500 (Wed, 25 Mar 2009) | 35 lines
Improve performance of the ast_event cache functionality.
This code comes from svn/asterisk/team/russell/event_performance/.
Here is a summary of the changes that have been made, in order of both
invasiveness and performance impact, from smallest to largest.
1) Asterisk 1.6.1 introduces some additional logic to be able to handle
distributed device state. This functionality comes at a cost.
One relatively minor change in this patch is that the extra processing
required for distributed device state is now completely bypassed if
it's not needed.
2) One of the things that I noticed when profiling this code was that a
_lot_ of time was spent doing string comparisons. I changed the way
strings are represented in an event to include a hash value at the front.
So, before doing a string comparison, we do an integer comparison on the
hash.
3) Finally, the code that handles the event cache has been re-written.
I tried to do this in a such a way that it had minimal impact on the API.
I did have to change one API call, though - ast_event_queue_and_cache().
However, the way it works now is nicer, IMO. Each type of event that
can be cached (MWI, device state) has its own hash table and rules for
hashing and comparing objects. This by far made the biggest impact on
performance.
For additional details regarding this code and how it was tested, please see the
review request.
(closes issue #14738)
Reported by: russell
Review: http://reviewboard.digium.com/r/205/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@184343 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r183766 | mmichelson | 2009-03-23 13:58:03 -0500 (Mon, 23 Mar 2009) | 13 lines
Merged revisions 183700 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183700 | mmichelson | 2009-03-23 12:59:28 -0500 (Mon, 23 Mar 2009) | 7 lines
Fix a memory leak in res_monitor.c
The only way that this leak would occur is if Monitor were started
using the Manager interface and no File: header were given. Discovered
while reviewing the ast_channel_ao2 review request.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@183769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r182847 | russell | 2009-03-17 21:28:55 -0500 (Tue, 17 Mar 2009) | 52 lines
Merged revisions 182810 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines
Fix cases where the internal poll() was not being used when it needed to be.
We have seen a number of problems caused by poll() not working properly on
Mac OSX. If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues. In Asterisk, we've
had poll.c which implements poll() using select() internally. However, we
were still getting reports of problems.
vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.
The changes are:
1) Remove logic for when internal poll should be used from the Makefile.
Instead, put it in the configure script. The logic in the configure
script is the same as it was in the Makefile. Ideally, we would have
a functionality test for the problem, but that's not actually possible,
since we would have to be able to run an application on the _target_
system to test poll() behavior.
2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
is not defined.
3) Change uses of poll() throughout the source tree to ast_poll(). I feel
that it is good practice to give the API call a new name when we are
changing its behavior and not using the system version directly in all cases.
So, normally, ast_poll() is just redefined to poll(). On systems where
AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().
4) Change poll() in main/poll.c to be ast_internal_poll().
It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before). So, for example, out of tree modules that are
using poll() will not stop working or anything. However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.
(closes issue #13404)
Reported by: agalbraith
Tested by: russell, vadim
http://reviewboard.digium.com/r/198/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@182947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181659 | file | 2009-03-12 13:50:37 -0300 (Thu, 12 Mar 2009) | 8 lines
Fix another scenario where depending on configuration the stream would not get read.
For custom commands we don't know whether the audio is coming from a stream or not
so we are going to have to read the data despite no channels.
(closes issue #14416)
Reported by: caspy
........
r181660 | file | 2009-03-12 13:52:45 -0300 (Thu, 12 Mar 2009) | 2 lines
Fix logic flaw in previous commit.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181661 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181655 | file | 2009-03-12 13:29:19 -0300 (Thu, 12 Mar 2009) | 10 lines
Fix issue with streaming MOH failing if nobody is listening.
When a music class is setup to actually provide music on hold
from a stream we need to constantly read audio from it since it
will constantly be providing audio. This is now done despite there
being no channels listening to it.
(closes issue #14416)
Reported by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181656 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This document specifies the timing modules available in Asterisk beginning
with Asterisk 1.6.1. The document goes into detail about the differences
between each and gives a general overview of what timing is used for in
Asterisk. There is also a section which can be used to help customize
your setup or to troubleshoot timing issues you may have.
I also added messages to the DAHDI timing test used in res_timing_dahdi.c
that points to this new documentation if people experience problems.
Big thanks to all who contributed comments on this.
(closes issue #14490)
Reported by: mmichelson
Patches:
timing.txt uploaded by mmichelson (license 60)
Review: http://reviewboard.digium.com/r/164/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179937 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Add module use count handling so that timing modules can be unloaded.
2) Implement unload_module() functions for the timing interface modules.
3) Allow multiple timing modules to be loaded, and use the one with the
highest priority value.
4) Report which timing module is being use in the "timing test" CLI command.
(closes issue #14489)
Reported by: russell
Review: http://reviewboard.digium.com/r/162/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch includes a number of changes to the indications API. The primary
motivation for this work was to improve stability. The object management
in this API was significantly flawed, and a number of trivial situations could
cause crashes.
The changes included are:
1) Remove the module res_indications. This included the critical functionality
that actually loaded the indications configuration. I have seen many people
have Asterisk problems because they accidentally did not have an
indications.conf present and loaded. Now, this code is in the core,
and Asterisk will fail to start without indications configuration.
There was one part of res_indications, the dialplan applications, which did
belong in a module, and have been moved to a new module, app_playtones.
2) Object management has been significantly changed. Tone zones are now
managed using astobj2, and it is no longer possible to crash Asterisk by
issuing a reload that destroys tone zones while they are in use.
3) The API documentation has been filled out.
4) The API has been updated to follow our naming conventions.
5) Various bits of code throughout the tree have been updated to account
for the API update.
6) Configuration parsing has been mostly re-written.
7) "Code cleanup"
The code is from svn/asterisk/team/russell/indications/.
Review: http://reviewboard.digium.com/r/149/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r174218 | file | 2009-02-09 10:48:21 -0400 (Mon, 09 Feb 2009) | 4 lines
Don't overwrite our pointer to the music class when music on hold stops. We will use this if it starts again to see if we can resume the music where it left off.
(closes issue #14407)
Reported by: mostyn
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
along the way fix some minor coding style issues in strings.h and add some attribute_pure annotations to functions in the ast_str API
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This sequence of events posed a problem
timerfd_timer_open
timerfd_timer_enable_continuous
timerfd_timer_set_rate
timerfd_timer_disable_continuous
The reason was that the timing module was written under the assumption
that timerfd_timer_set_rate would not be called between enabling and
disabling continuous mode. What happened in this situation was that
timerfd_timer_enable_continuous saved off our previously set timer (in this
situation a 0 timer, meaning it never runs out). Then timerfd_timer_disable_continuous
would restore this 0 timer, even though it logically should set the timer to be whatever
was set in timerfd_timer_set_rate.
Now the behavior in timerfd_timer_set_rate is to overwrite the saved timer that may
or may not have been set in timerfd_timer_enable_continuous. Even if
timerfd_timer_enable_continuous has not been previously called, this will not harm the
operation.
Thanks to Terry Wilson for discovering the problem and giving me a really great debug
capture that pointed out the problem clearly
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168898 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168745 | murf | 2009-01-15 17:19:12 -0700 (Thu, 15 Jan 2009) | 14 lines
This patch fixes a problem where a goto (or jump, in this case)
fails a consistency check because it can't find a matching
extension. The problem was a missing instruction to end
the range notation in the code where it converts the pattern
into a regex and uses the regex code to determine the match.
I tested using the AEL code the user supplied, and now,
the consistency check passes.
(closes issue #14141)
Reported by: dimas
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168746 65c4cc65-6c06-0410-ace0-fbb531ad65f3