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/trunk@113297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113013 | jpeeler | 2008-04-07 10:18:10 -0500 (Mon, 07 Apr 2008) | 15 lines
Merged revisions 113012 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113012 | jpeeler | 2008-04-07 10:16:44 -0500 (Mon, 07 Apr 2008) | 7 lines
(closes issue #12362)
(closes issue #12372)
Reported by: vinsik
Tested by: tecnoxarxa
This one line change makes an if inside a for loop (in realtime_peer) check all the ast_variables the loop was intending to test rather than just the first one.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The variable name "flag" to distinguish between whether a message is being forwarded or
is new is not a helpful name. The newly added doxygen documentation to app_voicemail is
tremendously helpful, but I still just...hate this variable name. I think is_new_message
is more indicative of what its purpose is.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113207 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@113066 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113012 | jpeeler | 2008-04-07 10:16:44 -0500 (Mon, 07 Apr 2008) | 7 lines
(closes issue #12362)
(closes issue #12372)
Reported by: vinsik
Tested by: tecnoxarxa
This one line change makes an if inside a for loop (in realtime_peer) check all the ast_variables the loop was intending to test rather than just the first one.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Attaching to a running asterisk with "telnet hostname 5060", I would input "something", then hit return three times, and asterisk crashes.
I traced it to handle_request_do(), which zeroes out the data (an ast_str ptr) if the string is too short.
Instead of freeing the struct and nulling the pointer, it now just resets it, because this
ast_str is expected by the calling routine to still be there after handle_request_do() returns.
This appears to fix the crash. I assume that it was introduced with ast_str's being adopted. It's a subtle and easy-to-miss sort of problem.
I also found all the places where the req.data is freed, and made sure the ptr is Nulled out as well;
no good leaving bad ptrs laying around-- I didn't need to do this, but it seemed a good thing to do...
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@112874 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r112599 | mmichelson | 2008-04-03 09:32:20 -0500 (Thu, 03 Apr 2008) | 9 lines
Fix the testing of the "res" variable so that it is more logically correct and
makes the correct warning and debug messages print.
(closes issue #12361)
Reported by: one47
Patches:
chan_zap_deferred_digit.patch uploaded by one47 (license 23)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@112600 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@112469 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@112289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
