https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111856 | qwell | 2008-03-28 16:45:35 -0500 (Fri, 28 Mar 2008) | 12 lines
Allow gsm to compile correctly on x86 with gcc4 optimizations.
(closes issue #11243)
Reported by: whiskerp
Patches:
11243-maybe-asm.diff uploaded by qwell (license 4)
Tested by: Seggy (IRC)
Note: While I did write this patch, I would not have found this if fossil
had not reported and fixed issue #12253. A huge thanks to him for helping
to (indirectly) find the problem here.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111857 65c4cc65-6c06-0410-ace0-fbb531ad65f3
that valgrind no longer complains and that calls do complete correctly.
The fix is along the same lines as before: Make sure the final null terminator gets copied
into the new sip_request's data pointer. Without it, parse_request will read and potentially
write past the end of the string, causing potential crashes.
(closes issue #12284...for real this time!)
reported by falves11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111811 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(same patch as before, I just split this part out)
(close issue #12326)
Reported by: travishein
Patches:
app_voicemail_code_documentation.patch uploaded by travishein (license 385)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
for the string to be copied into. This resulted in parse_request reading invalid
memory beyond the end of the string, and in some cases led to crashes. Thanks
to falves11 for providing the valgrind output which led to the closure of this issue.
(closes issue #12284)
Reported by: falves11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem was that when the refcount on the queue hit 0, the destructor was
called, and inside the destructor, another function was called which would increase
the refcount back to 1 again and then decrease it again back to 0 for every member
in the queue. This meant that the destructor was being recursively called, leading
to a double free of the queue. This is now fixed by making sure to unlink the
queue from the queues container prior to the final unref of the queue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@111410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111341 | murf | 2008-03-26 21:21:05 -0600 (Wed, 26 Mar 2008) | 15 lines
(closes issue #12302)
Reported by: pj
Tested by: murf
These changes will set a channel variable ~~EXTEN~~ just before generating code
for a switch, with the value of ${EXTEN}. The exten is marked as having a switch,
and ever after that, till the end of the exten, we substitute any ${EXTEN}
with ${~~EXTEN~~} instead in application arguments; (and the ${EXTEN: also).
The reason for this, is that because switches are coded using
separate extensions to provide pattern matching, and
jumping to/from these switch extensions messes up the ${EXTEN} value,
which blows the minds of users.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@111246 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111049 | mmichelson | 2008-03-26 14:22:16 -0500 (Wed, 26 Mar 2008) | 9 lines
Add a lock to the vm_state structure and use the lock around mail_open calls
to prevent concurrent access of the same mailstream. This, along with trunk's
ability to configure TCP timeouts for IMAP storage will help to prevent
crashes and hangs when using voicemail with IMAP storage.
(closes issue #10487)
Reported by: ewilhelmsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per comments from dimas:
1. The code now generates DTMF_BEGIN frames in addition to DTMF_END ones.
2. "quelching" rewritten - now each detector (MF/DTMF/generic tone) may mark fragment of a frame for suppression (squelching, muting) with a call to mute_fragment. Actual muting happens only once at the very end of ast_dsp_process where all marked fragments are zeroed. This way every detector sees original data in the frame without any piece of a frame being zeroed by a detector which was run before.
3. DTMF detector tries to "mute" one block before and one block after the block where actual tone was detected. Muting of previois block is something new for this patch. Obviously this operation is not always possible - if current frame does not contain data for previous block - it is too late. But at least we make our best.
Muting of next block was already done by the old code but it only affects part of the next block which is in the frame being processed. New code keeps this information in state structures so it will mute proper number of samples in the next frame(s) too.
4. Removed ast_dsp_digitdetect and ast_dsp_getdigits APIs because these are not used.
5. DSP API extended a bit - ast_dsp_was_muted() function added which returns true if DSP code was muting any fragment in the last frame. chan_zap uses this function to decide it needs to turn on confmute on the channel.
This is to replace AST_FRAME_DTMF 'm'/'u' (mute/unmute) functionality.
(closes issue #11968)
Reported by: dimas
Patches:
v2-11968-dsp.patch uploaded by dimas (license 88)
v4-11968-zap.patch uploaded by dimas (license 88)
Tested by: dimas, qwell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@111017 65c4cc65-6c06-0410-ace0-fbb531ad65f3