https://origsvn.digium.com/svn/asterisk/trunk
........
r203721 | dbrooks | 2009-06-26 15:13:51 -0500 (Fri, 26 Jun 2009) | 16 lines
Fixing voicemail's error in checking max silence vs min message length
Max silence was represented in milliseconds, yet vmminsecs (minmessage) was represented
as seconds.
Also, the inequality was reversed. The warning, if triggered, was "Max silence should
be less than minmessage or you may get empty messages", which should have been logged
if max silence was greater than minmessage, but the check was for less than.
Also, conforming if statement to coding guidelines.
closes issue #15331)
Reported by: markd
Review: https://reviewboard.asterisk.org/r/293/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@203731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r201783 | tilghman | 2009-06-18 15:52:36 -0500 (Thu, 18 Jun 2009) | 6 lines
One of the changes in 1.6.1 was to allow app_directory to use functionality
within app_voicemail for directory functions. It is therefore no longer
necessary for app_directory to be linked against the ODBC libraries (and it
never was necessary for app_directory to be linked against IMAP, though it
was).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@201785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r201445 | dvossel | 2009-06-17 14:45:35 -0500 (Wed, 17 Jun 2009) | 25 lines
Merged revisions 201423 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r201423 | dvossel | 2009-06-17 14:28:12 -0500 (Wed, 17 Jun 2009) | 19 lines
StopMixMonitor race condition (not giving up file immediately)
StopMixMonitor only indicates to the MixMonitor thread to stop
writing to the file. It does not guarantee that the recording's
file handle is available to the dialplan immediately after execution.
This results in a race condition. To resolve this, the filestream
pointer is placed in a datastore on the channel. When StopMixMonitor
is called, the datastore is retrieved from the channel and the
filestream is closed immediately before returning to the dialplan.
Documentation indicating the use of StopMixMonitor to free files
has been updated as well.
(closes issue #15259)
Reported by: travisghansen
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/283/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@201447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r201056 | kpfleming | 2009-06-16 13:54:30 -0500 (Tue, 16 Jun 2009) | 18 lines
Merged revisions 200991 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r200991 | kpfleming | 2009-06-16 12:05:38 -0500 (Tue, 16 Jun 2009) | 11 lines
Improve support for media paths that can generate multiple frames at once.
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
https://reviewboard.asterisk.org/r/175/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@201097 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r200943 | mvanbaak | 2009-06-16 17:51:36 +0200 (Tue, 16 Jun 2009) | 9 lines
add FILE_STORAGE to Voicemail Build Options
Voicemail can only use one storage module at the moment.
Because it's unclear that selecting one of the storage modules
in menuselect will disable filesystem storage we now have
a FILE_STORAGE option that conflicts with the other modules.
(closes issue #15333)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@200948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r197828 | lmadsen | 2009-05-28 18:04:00 -0400 (Thu, 28 May 2009) | 8 lines
Update documentation in MixMonitor.
Updated the MixMonitor documentation for the 'b' option so that
it is more obvious that you must not optimize away the Local
channel when using this option.
(closes issue #14829)
Reported by: licedey
Tested by: mmichelson, licedey, lmadsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@197894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197543 | mmichelson | 2009-05-28 09:58:06 -0500 (Thu, 28 May 2009) | 27 lines
Merged revisions 197537 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197537 | mmichelson | 2009-05-28 09:49:13 -0500 (Thu, 28 May 2009) | 21 lines
Add flags to chanspy audiohook so that audio stays in sync.
There are two flags being added to the chanspy audiohook here. One
is the pre-existing AST_AUDIOHOOK_TRIGGER_SYNC flag. With this set,
we ensure that the read and write slinfactories on the audiohook do
not skew beyond a certain tolerance.
In addition, there is a new audiohook flag added here,
AST_AUDIOHOOK_SMALL_QUEUE. With this flag set, we do not allow for
a slinfactory to build up a substantial amount of audio before
flushing it. For this particular issue, this means that the person
spying on the call will hear the conversations in real time with very
little delay in the audio.
(closes issue #13745)
Reported by: geoffs
Patches:
13745.patch uploaded by mmichelson (license 60)
Tested by: snblitz
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@197548 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r196377 | eliel | 2009-05-22 15:38:33 -0400 (Fri, 22 May 2009) | 11 lines
Unregister every registered application by MiniVM.
The MinivmMWI application was not being unregistered on unload and we were not
able to load again the module or reload it.
(closes issue #15174)
Reported by: junky
Patches:
unregister_minivm_mwi.diff uploaded by junky (license 177)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@196378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r195316 | mmichelson | 2009-05-18 13:58:26 -0500 (Mon, 18 May 2009) | 18 lines
Fix externalivr's setvariable command so that it properly sets multiple variables.
The command had a for loop that was guaranteed to only execute once since
the continuation operation of the loop would set the input buffer NULL. I rewrote
the loop so that its operation was more obvious, and it would set multiple variables
correctly.
I also reduced stack space required for the function, constified the input string,
and modified the function so that it would not modify the input string while I was
at it.
(closes issue #15114)
Reported by: chris-mac
Patches:
15114.patch uploaded by mmichelson (license 60)
Tested by: chris-mac
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@195319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@195164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r193756 | tilghman | 2009-05-11 17:50:47 -0500 (Mon, 11 May 2009) | 25 lines
Recorded merge of revisions 193755 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193755 | tilghman | 2009-05-11 17:48:20 -0500 (Mon, 11 May 2009) | 18 lines
Move 300 bytes around on the stack, to make more room for an extension buffer.
This allows more concurrent extensions to be copied for a single voicemail,
without creating a possibility of upsetting existing users, where a dialplan
could run out of stack space where it had run fine before. Alternatively,
we could have allocated off the heap, but that is a larger change and would
have increased the chance for instability introduced by this change.
This is really solved starting in 1.6.0.11, as the use of an ast_str buffer
allows an unlimited number of extensions (up to available memory). We
additionally create a new warning message when the buffer length is exceeded,
permitting administrators to see an issue after the fact, whereas previously
the list was silently truncated.
(closes issue #14739)
Reported by: p_lindheimer
Patches:
20090417__bug14739.diff.txt uploaded by tilghman (license 14)
Tested by: p_lindheimer
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@193823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r193349 | mmichelson | 2009-05-08 14:50:44 -0500 (Fri, 08 May 2009) | 12 lines
Reset the members' call counts when resetting queue statistics.
This helps to prevent odd scenarios where a queue will claim to have
taken 0 calls, but the members appear to have taken a non-zero amount.
(closes issue #15068)
Reported by: sum
Patches:
patchreset.patch uploaded by sum (license 766)
Tested by: sum
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@193350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r188032 | mmichelson | 2009-04-13 09:17:56 -0500 (Mon, 13 Apr 2009) | 6 lines
Set all queue variables on both the caller and member channels.
This allows for the variables to be accessed if a member macro is run.
Thanks to Grigoriy Puzankin for bringing this up on the -dev list.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@188039 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r186286 | mmichelson | 2009-04-03 09:32:05 -0500 (Fri, 03 Apr 2009) | 20 lines
Fix the ability to retrieve voicemail messages from IMAP.
A recent change made interactive vm_states no longer get
added to the list of vm_states and instead get stored in
thread-local storage.
In trunk and all the 1.6.X branches, the problem is that
when we search for messages in a voicemail box, we would
attempt to update the appropriate vm_state struct by directly
searching in the list of vm_states instead of using the
get_vm_state_by_imap_user function. This meant we could not
find the interactive vm_state that we wanted.
(closes issue #14685)
Reported by: BlargMaN
Patches:
14685.patch uploaded by mmichelson (license 60)
Tested by: BlargMaN, qualleyiv, mmichelson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@186289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r185072 | mmichelson | 2009-03-30 11:26:48 -0500 (Mon, 30 Mar 2009) | 45 lines
Merged revisions 185031 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185031 | mmichelson | 2009-03-30 11:17:35 -0500 (Mon, 30 Mar 2009) | 39 lines
Fix queue weight behavior so that calls in low-weight queues are not inappropriately blocked.
(This is copied and pasted from the review request I made for this patch)
Asterisk has some odd behavior when queue weights are used. The current logic used when
potentially calling a queue member is:
If the member we are going to call is part of another queue and _that other queue has any
callers in it_ and has a higher weight than the queue we are calling from, then don't try
to contact that member. The issue here is what I have marked with underscores. If the
higher-weighted queue has any callers in it at all, then the queue member will be unreachable
from the lower-weighted queue. This has the potential to be really really bad if using a
queue strategy, such as leastrecent or fewestcalls, with the potential to call the same
member repeatedly.
The fix proposed by garychen on issue 13220 is very simple and, as far as I can see, works
well for this situation. With this set of changes, the logic used becomes:
If the member we are going to call is part of another queue, the other queue has a higher
weight than the queue we are calling from, and the higher weight queue has at least as many
callers as available members, then do not try to contact the queue member. If the higher
weighted queue has fewer callers than available members, then there is no reason to deny
the call to this member since the other queue can afford to spare a member.
Since the fix involved writing a generic function for determining the number of available
members in the queue, I also modified the is_our_turn function to make use of the new
num_available_members function to determine if it is our turn to try calling a member. There
is one small behavior change. Before writing this patch, if you had autofill disabled, then
if you were the head caller in a queue, you would automatically be told that it was your
turn to try calling a member. This did not take into account whether there were actually any
queue members available to take the call. Now we actually make sure there is at least one
member available to take the call if autofill is disabled.
(closes issue #13220)
Reported by: garychen
Review: http://reviewboard.digium.com/r/202/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@185089 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
................
r184079 | mmichelson | 2009-03-24 17:40:39 -0500 (Tue, 24 Mar 2009) | 15 lines
Merged revisions 184078 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r184078 | mmichelson | 2009-03-24 17:34:45 -0500 (Tue, 24 Mar 2009) | 9 lines
Change NULL pointer check to be ast_strlen_zero.
The 'digit' variable is guaranteed to be non-NULL, so the if
statement could never evaluate true. Changing to ast_strlen_zero
makes the logic correct.
This was found while reviewing ast_channel_ao2 code review.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@184082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r183244 | mmichelson | 2009-03-19 13:10:34 -0500 (Thu, 19 Mar 2009) | 16 lines
Fix a memory leak associated with queues.
For every attempt that app_queue made to place an outbound call to a queue member,
we would allocate a queue_end_bridge structure. When the bridge for the call had
completed, we would free the structure. Unfortunately not all call attempts actually
end up bridged to a member, so we need to be more selective of when to allocate
the structure. With this change, the allocation occurs in an area where we can
guarantee that the call will be bridged.
(closes issue #14680)
Reported by: caspy
Patches:
14680.patch uploaded by mmichelson (license 60)
Tested by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@183247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
