https://origsvn.digium.com/svn/asterisk/trunk
........
r113836 | mmichelson | 2008-04-09 12:48:33 -0500 (Wed, 09 Apr 2008) | 14 lines
There was a subtle logical difference between 1.4 and trunk with regards to how timeouts
were handled. In 1.4, if the absolute timeout were reached on a call, no matter what
the return value of ast_spawn_extension was, the pbx would attempt to go to the 'T'
extension or hangup otherwise. The rearrangement of this function in trunk made this check
only happen in the case that ast_spawn_extension returned 0. If ast_spawn_extension returned
1, then the fact that the timeout expired resulted in a no-op, and would cause an infinite
loop to occur in __ast_pbx_run. This change fixes this problem. Now timeouts will
behave as they did in 1.4
(closes issue #11550)
Reported by: pj
Tested by: putnopvut
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113837 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113297 | file | 2008-04-08 12:05:35 -0300 (Tue, 08 Apr 2008) | 12 lines
Merged revisions 113296 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113296 | file | 2008-04-08 12:03:43 -0300 (Tue, 08 Apr 2008) | 4 lines
If audio suddenly gets fed into one side of a channel after a lapse of frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute.
(closes issue #12296)
Reported by: jvandal
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113066 | mmichelson | 2008-04-07 11:12:30 -0500 (Mon, 07 Apr 2008) | 21 lines
Merged revisions 113065 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113065 | mmichelson | 2008-04-07 11:08:45 -0500 (Mon, 07 Apr 2008) | 13 lines
This fix prevents a deadlock that was experienced in chan_local. There was
deadlock prevention in place in chan_local, but it would not work in a specific
case because the channel was recursively locked. By unlocking the channel prior
to calling the generator's generate callback in ast_read_generator_actions(), we
prevent the recursive locking, and therefore the deadlock.
(closes issue #12307)
Reported by: callguy
Patches:
12307.patch uploaded by putnopvut (license 60)
Tested by: callguy
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r112653 | dhubbard | 2008-04-03 17:13:11 -0500 (Thu, 03 Apr 2008) | 1 line
add a Zaptel timer check to verify the timer is responding when Zaptel support is compiled into Asterisk and Zaptel drivers are loaded. This will help people not waste their valuable time debugging side effects.
........
r112656 | dhubbard | 2008-04-03 17:19:43 -0500 (Thu, 03 Apr 2008) | 1 line
satisfy buildbot
........
r112714 | dhubbard | 2008-04-03 19:57:33 -0500 (Thu, 03 Apr 2008) | 1 line
sleep long enough for the zaptel timer error message to display before exit
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@112715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r112469 | mmichelson | 2008-04-02 12:36:49 -0500 (Wed, 02 Apr 2008) | 21 lines
Merged revisions 112468 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r112468 | mmichelson | 2008-04-02 12:36:04 -0500 (Wed, 02 Apr 2008) | 13 lines
Fix a race condition in the manager. It is possible that a new manager event
could be appended during a brief time when the manager is not waiting for input.
If an event comes during this period, we need to set an indicator that there is an
event pending so that the manager doesn't attempt to wait forever for an event that
already happened.
(closes issue #12354)
Reported by: bamby
Patches:
manager_race_condition.diff uploaded by bamby (license 430)
(comments added by me)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@112470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r112289 | murf | 2008-04-01 14:02:19 -0600 (Tue, 01 Apr 2008) | 21 lines
(closes issue #12298)
Reported by: falves11
Patches:
12298.patch1 uploaded by murf (license 17)
Tested by: murf
I have hopes that the changes made over the last few days will
finalize and solidify this code. While there are bound to be
small tweaks still needed, I feel that the job (at last) is
somewhat completed. Finally, I had a chance to comprehend how
the scoring of extension patterns was done in the previous
version, and I've come very close to using the exact same
criteria in the new pattern matching code. The left-right
sorting is now replicated in the trie structure itself, such
that the first match found will the 'best' match. Compared
the results against 1.4 for several extensions. Replicated
falves11's setup and it works. Used some devious patterns
provided by jsmith, supplemented with a few of my own.
Looks good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@112299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r111908 | russell | 2008-03-28 17:45:43 -0500 (Fri, 28 Mar 2008) | 3 lines
Note a minor race condition that I noticed while reviewing Jeff's changes
to this code.
........
r111909 | russell | 2008-03-28 17:50:46 -0500 (Fri, 28 Mar 2008) | 3 lines
Make some notes about common usage of pbx_builtin_getvar_helper() that is not
thread-safe.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@111910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r111410 | murf | 2008-03-27 07:29:41 -0600 (Thu, 27 Mar 2008) | 17 lines
Merged revisions 111391 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111391 | murf | 2008-03-27 07:03:28 -0600 (Thu, 27 Mar 2008) | 9 lines
These small documentation updates made in response to a query in
asterisk-users, where a user was using Playback, but needed the
features of Background, and had no idea that Background existed,
or that it might provide the features he needed. I thought the
best way to avert these kinds of queries was to provide "See Also"
references in all three of "Background", "Playback", "WaitExten".
Perhaps a project to do this with all related apps is in order.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@111411 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r111246 | qwell | 2008-03-26 18:27:33 -0500 (Wed, 26 Mar 2008) | 17 lines
Merged revisions 111245 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111245 | qwell | 2008-03-26 18:26:33 -0500 (Wed, 26 Mar 2008) | 9 lines
Remove excessive smoother optimization that was causing audio glitches (small "pops")
after (about 200ms later) an "incorrectly" sized frame was received.
While it would be very nice to keep this as optimized as possible, it makes no sense
for the smoother to be dropping random bits of audio like this. Isn't that the
whole point of a smoother?
Closes issue #12093.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@111247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r110831 | mmichelson | 2008-03-25 19:02:31 -0500 (Tue, 25 Mar 2008) | 6 lines
This ensures that the manager interface is not enabled by default. Prior to this
change, it was possible to start Asterisk with the manager interface enabled, then
either comment out the enabled option or make manager.conf unopenable and the manager
interface would still be enabled.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@110832 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r110629 | file | 2008-03-25 11:39:45 -0300 (Tue, 25 Mar 2008) | 12 lines
Merged revisions 110628 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110628 | file | 2008-03-25 11:37:35 -0300 (Tue, 25 Mar 2008) | 4 lines
Add an option (transmit_silence) which transmits silence during both Record() and DTMF generation. The reason this is an option is that in order to transmit silence we have to setup a translation path. This may not be needed/wanted in all cases.
(closes issue #10058)
Reported by: tracinet
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@110630 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r110396 | russell | 2008-03-20 18:14:13 -0500 (Thu, 20 Mar 2008) | 17 lines
Merged revisions 110395 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110395 | russell | 2008-03-20 18:13:56 -0500 (Thu, 20 Mar 2008) | 9 lines
Shorten the ast_waitfor() timeout from 500 ms to 50 ms in the autoservice thread.
This really should not make a difference except in very rare cases. That case would
be that all of the channels in autoservice are not generating any frames. In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.
(closes issue #12266, reported by dimas)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@110397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r110303 | russell | 2008-03-20 15:08:26 -0500 (Thu, 20 Mar 2008) | 8 lines
Fix a bug when using zaptel timing for playing back files that have a sample rate
other than 8 kHz. The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame. However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.
(another part of issue #12164, reported by milazzo and jsmith, patch by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@110304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r110268 | russell | 2008-03-20 12:41:22 -0500 (Thu, 20 Mar 2008) | 27 lines
Add some fixes that I made in regards to wideband codec handling to get
G.722 music on hold working for me.
(issue #12164, reported by milazzo and jsmith, patches by me)
res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
ast_write(). The reason that this was a bug is that the G.722 frame
originally says it has 320 samples in it (which is correct). However,
when the frame is written to a channel that uses RTP, main/rtp.c modifies
the frame to cut the number of samples in half before it sends it on
the wire. This is to account for the stupid incorrect G.722 spec that
makes it so we have to lie about the number of samples with RTP. I should
probably go and re-work the RTP code so it doesn't modify the frame so
that a bug like this won't happen in the future. However, this change to
MOH is harmless.
main/channel.c:
- I made two fixes in regards to generator timing. Generators use samples
for timing. However, this code assumed 8 kHz samples. In one case, it was
a hard coded 160 samples, that is now written as the sample rate / 50. The
other place was dealing with timing a generator based on frames coming from
the other direction. However, that would have only worked if the sample
rates for the formats in both directions were the same. The code now takes
into account that the sample rates may differ, and scales the generator
samples accordingly.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@110269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r110020 | file | 2008-03-19 15:25:33 -0300 (Wed, 19 Mar 2008) | 14 lines
Merged revisions 110019 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110019 | file | 2008-03-19 15:20:28 -0300 (Wed, 19 Mar 2008) | 6 lines
Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames.
(closes issue #11429)
Reported by: sperreault
Patches:
11429-frametype.diff uploaded by qwell (license 4)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@110021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r109942 | murf | 2008-03-19 10:24:51 -0600 (Wed, 19 Mar 2008) | 80 lines
Merged revisions 109908 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r109908 | murf | 2008-03-19 09:41:13 -0600 (Wed, 19 Mar 2008) | 72 lines
(closes issue #11442)
Reported by: tzafrir
Patches:
11442.patch uploaded by murf (license 17)
Tested by: murf
I didn't give tzafrir very much time to test this, but if he does
still have remaining issues, he is welcome to
re-open this bug, and we'll do what is called for.
I reproduced the problem, and tested the fix, so I hope I
am not jumping by just going ahead and committing the fix.
The problem was with what file_save does with templates;
firstly, it tended to print out multiple options:
[my_category](!)(templateref)
instead of
[my_category](!,templateref)
which is fixed by this patch.
Nextly, the code to suppress output of duplicate declarations
that would occur because the reader copies inherited declarations
down the hierarchy, was not working. Thus:
[master-template](!)
mastervar = bar
[template](!,master-template)
tvar = value
[cat](template)
catvar = val
would be rewritten as:
;!
;! Automatically generated configuration file
;! Filename: experiment.conf (/etc/asterisk/experiment.conf)
;! Generator: Manager
;! Creation Date: Tue Mar 18 23:17:46 2008
;!
[master-template](!)
mastervar = bar
[template](!,master-template)
mastervar = bar
tvar = value
[cat](template)
mastervar = bar
tvar = value
catvar = val
This has been fixed. Since the config reader 'explodes' inherited
vars into the category, users may, in certain circumstances, see
output different from what they originally entered, but it should
be both correct and equivalent.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@109969 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r109447 | twilson | 2008-03-18 10:43:34 -0500 (Tue, 18 Mar 2008) | 3 lines
Go through and fix a bunch of places where character strings were being interpreted as format strings. Most of these changes are solely to make compiling with -Wsecurity and -Wformat=2 happy, and were not
actual problems, per se. I also added format attributes to any printf wrapper functions I found that didn't have them. -Wsecurity and -Wmissing-format-attribute added to --enable-dev-mode.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@109459 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r109229 | twilson | 2008-03-17 17:10:06 -0500 (Mon, 17 Mar 2008) | 5 lines
Replace minimime with superior GMime library so that the entire contents of an http post are not read into memory.
This does introduce a dependency on the GMime library for handling HTTP POSTs, but it is available in most distros.
If the library is present, then the compile flag for ENABLE_UPLOADS is enabled by default in menuselect.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@109254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r109227 | mmichelson | 2008-03-17 17:06:44 -0500 (Mon, 17 Mar 2008) | 20 lines
Merged revisions 109226 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r109226 | mmichelson | 2008-03-17 17:05:49 -0500 (Mon, 17 Mar 2008) | 12 lines
Fix a logic flaw in the code that stores lock info which is displayed
via the "core show locks" command. The idea behind this section of code was
to remove the previous lock from the list if it was a trylock that had failed.
Unfortunately, instead of checking the status of the previous lock, we were referencing
the index immediately following the previous lock in the lock_info->locks array.
The result of this problem, under the right circumstances, was that the lock which
we currently in the process of attempting to acquire could "overwrite" the previous lock
which was acquired. While this does not in any way affect typical operation, it *could*
lead to misleading "core show locks" output.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@109228 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r108584 | russell | 2008-03-13 16:40:43 -0500 (Thu, 13 Mar 2008) | 19 lines
Merged revisions 108583 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108583 | russell | 2008-03-13 16:38:16 -0500 (Thu, 13 Mar 2008) | 11 lines
Fix another issue that was causing crashes in chanspy. This introduces a new
datastore callback, called chan_fixup(). The concept is exactly like the
fixup callback that is used in the channel technology interface. This callback
gets called when the owning channel changes due to a masquerade. Before this
was introduced, if a masquerade happened on a channel being spyed on, the
channel pointer in the datastore became invalid.
(closes issue #12187)
(reported by, and lots of testing from atis)
(props to file for the help with ideas)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@108585 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r108529 | mmichelson | 2008-03-13 15:59:00 -0500 (Thu, 13 Mar 2008) | 11 lines
Fixing a potential buffer overflow in the manager command ModuleCheck.
Though this overflow is exploitable remotely, we are NOT issuing a security
advisory for this since in order to exploit the overflow, the attacker would
have to establish an authenticated manager session AND have the system privilege.
By gaining this privilege, the attacker already has more powerful weapons at his
disposal than overflowing a buffer with a malformed manager header, so the vulnerability
in this case really lies with the authentication method that allowed the attacker to
gain the system privilege in the first place.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@108582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r108137 | russell | 2008-03-12 14:59:05 -0500 (Wed, 12 Mar 2008) | 48 lines
Merged revisions 108135 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108135 | russell | 2008-03-12 14:57:42 -0500 (Wed, 12 Mar 2008) | 40 lines
(closes issue #12187, reported by atis, fixed by me after some brainstorming
on the issue with mmichelson)
- Update copyright info on app_chanspy.
- Fix a race condition that caused app_chanspy to crash. The issue was that
the chanspy datastore magic that was used to ensure that spyee channels did
not disappear out from under the code did not completely solve the problem.
It was actually possible for chanspy to acquire a channel reference out of
its datastore to a channel that was in the middle of being destroyed. That
was because datastore destruction in ast_channel_free() was done near the
end. So, this left the code in app_chanspy accessing a channel that was
partially, or completely invalid because it was in the process of being free'd
by another thread. The following sort of shows the code path where the race
occurred:
=============================================================================
Thread 1 (PBX thread for spyee chan) || Thread 2 (chanspy)
--------------------------------------||-------------------------------------
ast_channel_free() ||
- remove channel from channel list ||
- lock/unlock the channel to ensure ||
that no references retrieved from ||
the channel list exist. ||
--------------------------------------||-------------------------------------
|| channel_spy()
- destroy some channel data || - Lock chanspy datastore
|| - Retrieve reference to channel
|| - lock channel
|| - Unlock chanspy datastore
--------------------------------------||-------------------------------------
- destroy channel datastores ||
- call chanspy datastore d'tor ||
which NULL's out the ds' || - Operate on the channel ...
reference to the channel ||
||
- free the channel ||
||
|| - unlock the channel
--------------------------------------||-------------------------------------
=============================================================================
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@108138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r108084 | file | 2008-03-12 15:29:33 -0300 (Wed, 12 Mar 2008) | 12 lines
Merged revisions 108083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108083 | file | 2008-03-12 15:26:37 -0300 (Wed, 12 Mar 2008) | 4 lines
Add a trigger mode that triggers on both read and write. The actual function that returns the combined audio frame though will wait until both sides have fed in audio, or until one side stops (such as the case when you call Wait).
(closes issue #11945)
Reported by: xheliox
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@108085 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r107791 | tilghman | 2008-03-11 17:55:16 -0500 (Tue, 11 Mar 2008) | 5 lines
An offhand comment from Russell made me realize that the configuration file
caching would not work properly for users.conf and any other file read from
more than one place. I needed to add the filename which requested the config
file to get it to work properly.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@107793 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r107373 | kpfleming | 2008-03-11 06:36:51 -0500 (Tue, 11 Mar 2008) | 19 lines
Merged revisions 107352 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r107352 | kpfleming | 2008-03-11 06:04:29 -0500 (Tue, 11 Mar 2008) | 11 lines
fix up various compiler warnings found with gcc-4.3:
- the output of flex includes a static function called 'input' that is not used, so for the moment we'll stop having the compiler tell us about unused variables in the flex source files (a better fix would be to improve our flex post-processing to remove the unused function)
- main/stdtime/localtime.c makes assumptions about signed integer overflow, and gcc-4.3's improved optimizer tries to take advantage of handling potential overflow conditions at compile time; for now, suppress these optimizations until we can fiure out if the code needs improvement
- main/udptl.c has some references to uninitialized variables; in one case there was no bug, but in the other it was certainly possibly for unexpected behavior to occur
- main/editline/readline.c had an unused variable
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@107374 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r107019 | murf | 2008-03-10 08:55:21 -0600 (Mon, 10 Mar 2008) | 1 line
way back in July, in r.75706, a fix was made ot the strftime usages, which was good, but in this case, the check for a nil time was accidentally removed, and now it is restored, to keep timevals like '1969-12-31 17:00:00' from showing up in the cdrs. No idea what databases will do with this. No bugs filed as yet, but it felt like a bug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@107289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r107162 | russell | 2008-03-10 15:17:37 -0500 (Mon, 10 Mar 2008) | 16 lines
Merged revisions 107161 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r107161 | russell | 2008-03-10 15:17:11 -0500 (Mon, 10 Mar 2008) | 8 lines
Fix another bug specifically related to asynchronous call origination. Once the
PBX is started on the channel using ast_pbx_start(), then the ownership of the
channel has been passed on to another thread. We can no longer access it in this
code. If the channel gets hung up very quickly, it is possible that we could
access a channel that has been free'd.
(inspired by BE-386)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@107163 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r107159 | russell | 2008-03-10 15:05:12 -0500 (Mon, 10 Mar 2008) | 17 lines
Merged revisions 107158 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r107158 | russell | 2008-03-10 15:04:27 -0500 (Mon, 10 Mar 2008) | 9 lines
Fix some bugs related to originating calls. If the code failed to start a PBX
on the channel (such as if you set a call limit based on the system's load
average), then there were cases where a channel that has already been free'd
using ast_hangup() got accessed. This caused weird memory corruption and
crashes to occur.
(fixes issue BE-386)
(much debugging credit goes to twilson, final patch written by me)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@107160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r106501 | russell | 2008-03-06 18:24:58 -0600 (Thu, 06 Mar 2008) | 28 lines
Merge changes from team/russell/g722-sillyness ...
Fix a number of other places where the number of samples in a G722 frame was
not properly handled because of various reasons.
main/rtp.c:
- When a G722 frame is read from the smoother, the number of samples in the
frame must be divided by 2 before being sent out over the network. Even
though G722 is 16 kHz, an error in some previous spec has made it so that
we have to list the number of samples such as if it was 8 kHz.
main/file.c:
- When scheduling the next time to expect a frame, take into account that the
format of the file we're reading from may not be 8 kHz.
codecs/codec_g722.c:
- When converting from G722 to slinear, g722_decode() expects its samples
parameter to be in the silly (real samples / 2) format. Make it so.
- When converting from slinear to G722, properly set the number of samples in
the frame to be the number of bytes of output * 2.
formats/format_pcm.c:
- This format module handles G722, among a number of other formats. However,
the read() and seek() functions did not account for the fact that G722 has
2 samples per byte.
(closes issue #12130, reported by rickross, patched by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@106502 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r106438 | mmichelson | 2008-03-06 16:11:26 -0600 (Thu, 06 Mar 2008) | 16 lines
Merged revisions 106437 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106437 | mmichelson | 2008-03-06 16:10:07 -0600 (Thu, 06 Mar 2008) | 8 lines
Quell an annoying message that is likely to print every single time that
ast_pbx_outgoing_app is called. The reason is that __ast_request_and_dial
allocates the cdr for the channel, so it should be expected that the channel
will have a cdr on it.
Thanks to joetester on IRC for pointing this out
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@106442 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r105933 | russell | 2008-03-04 19:54:16 -0600 (Tue, 04 Mar 2008) | 13 lines
Merged revisions 105932 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105932 | russell | 2008-03-04 19:52:18 -0600 (Tue, 04 Mar 2008) | 5 lines
Fix a bug that I just noticed in the RTP code. The calculation for setting the
len field in an ast_frame of audio was wrong when G.722 is in use. The len field
represents the number of ms of audio that the frame contains. It would have
set the value to be twice what it should be.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@106310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r105864 | mmichelson | 2008-03-04 17:24:56 -0600 (Tue, 04 Mar 2008) | 5 lines
There are several places in manager.c where BUFSIZ is used for a buffer
which will contain nowhere near that amount of data. This makes these buffers
more reasonably sized.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@106308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r105675 | file | 2008-03-04 12:08:42 -0600 (Tue, 04 Mar 2008) | 16 lines
Merged revisions 105674 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105674 | file | 2008-03-04 14:05:28 -0400 (Tue, 04 Mar 2008) | 8 lines
When a new source of audio comes in (such as music on hold) make sure the marker bit gets set.
(closes issue #10355)
Reported by: wdecarne
Patches:
10355.diff uploaded by file (license 11)
(closes issue #11491)
Reported by: kanderson
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@106299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
LIST instead of an RWLIST. The way this list works makes it such that
a RWLIST provides no additional benefit. Also, a mutex is needed for
use with the thread condition.
Merged revisions 105563 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105563 | russell | 2008-03-03 09:50:43 -0600 (Mon, 03 Mar 2008) | 24 lines
Merge in some changes from team/russell/autoservice-nochans-1.4
These changes fix up some dubious code that I came across while auditing what
happens in the autoservice thread when there are no channels currently in
autoservice.
1) Change it so that autoservice thread doesn't keep looping around calling
ast_waitfor_n() on 0 channels twice a second. Instead, use a thread condition
so that the thread properly goes to sleep and does not wake up until a
channel is put into autoservice.
This actually fixes an interesting bug, as well. If the autoservice thread
is already running (almost always is the case), then when the thread goes
from having 0 channels to have 1 channel to autoservice, that channel would
have to wait for up to 1/2 of a second to have the first frame read from it.
2) Fix up the code in ast_waitfor_nandfds() for when it gets called with no
channels and no fds to poll() on, such as was the case with the previous code
for the autoservice thread. In this case, the code would call alloca(0), and
pass the result as the first argument to poll(). In this case, the 2nd
argument to poll() specified that there were no fds, so this invalid pointer
shouldn't actually get dereferenced, but, this code makes it explicit and
ensures the pointers are NULL unless we have valid data to put there.
(related to issue #12116)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105564 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105560 | file | 2008-03-03 11:28:59 -0400 (Mon, 03 Mar 2008) | 7 lines
It is possible for no audio to pass between the current digit and next digit so expand logic that clears emulation to AST_FRAME_NULL.
(closes issue #11911)
Reported by: edgreenberg
Patches:
v1-11911.patch uploaded by dimas (license 88)
Tested by: tbsky
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105561 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105409 | russell | 2008-02-29 17:34:32 -0600 (Fri, 29 Feb 2008) | 23 lines
Fix a major bug in autoservice. There was a race condition in the handling of
the list of channels in autoservice. The problem was that it was possible for
a channel to get removed from autoservice and destroyed, while the autoservice
thread was still messing with the channel. This led to memory corruption, and
caused crashes. This explains multiple backtraces I have seen that have
references to autoservice, but do to the nature of the issue (memory corruption),
could cause crashes in a number of areas.
(fixes the crash in BE-386)
(closes issue #11694)
(closes issue #11940)
The following issues could be related. If you are the reporter of one of these,
please update to include this fix and try again.
(potentially fixes issue #11189)
(potentially fixes issue #12107)
(potentially fixes issue #11573)
(potentially fixes issue #12008)
(potentially fixes issue #11189)
(potentially fixes issue #11993)
(potentially fixes issue #11791)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105116 | russell | 2008-02-28 16:23:05 -0600 (Thu, 28 Feb 2008) | 8 lines
Fix a bug in the lock tracking code that was discovered by mmichelson. The issue
is that if the lock history array was full, then the functions to mark a lock as
acquired or not would adjust the stats for whatever lock is at the end of the array,
which may not be itself. So, do a sanity check to make sure that we're updating
lock info for the proper lock.
(This explains the bizarre stats on lock #63 in BE-396, thanks Mark!)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104841 | mmichelson | 2008-02-27 15:49:20 -0600 (Wed, 27 Feb 2008) | 17 lines
Two fixes:
1. Make the list of ast_dial_channels a lockable list. This is because in some cases,
the ast_dial may exist in multiple threads due to asynchronous execution of its application, and
I found some cases where race conditions could exist.
2. Check in ast_dial_join to be sure that the channel still exists before attempting to lock it, since
it could have gotten hung up but the is_running_app flag on the ast_dial_channel may not have been
cleared yet.
(closes issue #12038)
Reported by: jvandal
Patches:
12038v2.patch uploaded by putnopvut (license 60)
Tested by: jvandal
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105005 | qwell | 2008-02-28 13:20:10 -0600 (Thu, 28 Feb 2008) | 9 lines
Make pbx_exec pass an empty string into applications, if we get NULL.
This protects against possible segfaults in applications that may try
to use data before checking length (ast_strdupa'ing it, for example)
(closes issue #12100)
Reported by: foxfire
Patches:
12100-nullappargs.diff uploaded by qwell (license 4)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104593 | kpfleming | 2008-02-27 10:53:06 -0600 (Wed, 27 Feb 2008) | 8 lines
fallback to standard English prompts properly when using new prompt directory layout
(closes issue #11831)
Reported by: IgorG
Patches:
fallbacken.v1.diff uploaded by IgorG (license 20) (modified by me to improve code and conform rest of function to coding guidelines)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104594 65c4cc65-6c06-0410-ace0-fbb531ad65f3
automatically generated file like it used to be. This still needs to be there
for modules that have to check it to compile against multiple asterisk versions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104102 | russell | 2008-02-25 17:19:05 -0600 (Mon, 25 Feb 2008) | 7 lines
Improve the lock tracking code a bit so that a bunch of old locks that threads
failed to lock don't sit around in the history. When a lock is first locked,
this checks to see if the last lock in the list was one that was failed to be
locked. If it is, then that was a lock that we're no longer sitting in a trylock
loop trying to lock, so just remove it.
(inspired by issue #11712)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104092 | qwell | 2008-02-25 14:49:42 -0600 (Mon, 25 Feb 2008) | 11 lines
Allow the use of #include and #exec in situations where the max include depth was only 1.
Specifically, this fixes using #include and #exec in extconfig.conf.
This was basically caused because the config file itself raises the include level to 1.
I opted not to raise the include limit, because recursion here could cause very bizarre behavior.
Pointed out, and tested by jmls
(closes issue #12064)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103786 | mmichelson | 2008-02-18 14:52:09 -0600 (Mon, 18 Feb 2008) | 10 lines
There was an invalid assumption when calculating the duration of a file that the filestream in question
was created properly. Unfortunately this led to a segfault in the situation where an unknown format was
specified in voicemail.conf and a voicemail was recorded. Now, we first check to be sure that the stream
was written correctly or else assume a zero duration.
(closes issue #12021)
Reported by: jakep
Tested by: putnopvut
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103780 | tilghman | 2008-02-18 11:31:52 -0600 (Mon, 18 Feb 2008) | 9 lines
When a SIP channel is being auto-destroyed, it's possible for it to still be
in bridge code. When that happens, we crash. Delay the RTP destruction until
the bridge is ended.
(closes issue #11960)
Reported by: norman
Patches:
20080215__bug11960__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: norman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103728 | russell | 2008-02-15 13:50:11 -0600 (Fri, 15 Feb 2008) | 4 lines
In the case that you try to directly reload a module has returned
AST_MODULE_LOAD_DECLINE, log a message indicating that the module is not fully
initialized and must be initialized using "module load".
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103729 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103726 | russell | 2008-02-15 12:33:29 -0600 (Fri, 15 Feb 2008) | 6 lines
Don't attempt to execute the reload callback for a module that returned
AST_MODULE_LOAD_DECLINE. This fixes a crash that was reported against
chan_console in trunk.
(closes issue #11953, reported by junky, fixed by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103727 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to indicate there was more data than there really was, causing the iterator read beyond the end
of the event structure. This led to invalid memory reads and potential crashes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added ability to retrieve list of categories in a config file.
Added ability to retrieve the content of a particular category.
Added ability to empty a context.
Created new action to create a new file.
Updated delete action to allow deletion by line number with respect to category.
Added new action insert to add new variable to category at specified line.
Updated action newcat to allow new category to be inserted in file above another existing category.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in the event API.
ast_event_iterator_get_ie_type should return the ie type in
host byte order. Furthermore, ast_event_get_ie_raw should already
have its ie type argument in host byte order since it could be called
externally (and it in fact is called in this way by ast_event_get_cached).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #8925)
About a year ago, as Leif Madsen and Jim van Meggelen were going over the CLI
commands in Asterisk 1.4 for the next version of their book, they documented
a lot of inconsistencies. This set of changes addresses all of these issues
and has been reviewed by Leif.
While this does introduce even more changes to the CLI command structure, it
makes everything consistent, which is the most important thing.
Thanks to all that helped with this one!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r101601 | russell | 2008-01-31 17:10:06 -0600 (Thu, 31 Jan 2008) | 12 lines
Fix a couple of places where ast_frfree() was not called on a frame that came
from a translator. This showed itself by g729 decoders not getting released.
Since the flag inside the translator frame never got unset by freeing the frame
to indicate it was no longer in use, the translators never got destroyed, and
thus the g729 licenses were not released.
(closes issue #11892)
Reported by: xrg
Patches:
11892.diff uploaded by russell (license 2)
Tested by: xrg, russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@101611 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
Jason Parker
Joshua Colp
Dwayne M. Hubbard
Steve Murphy
Terry Wilson
Russell Bryant
Tilghman Lesher
Kevin P. Fleming
Michiel van Baak
Olle Johansson
Jeff Peeler