https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r69469 | qwell | 2007-06-14 18:21:45 -0500 (Thu, 14 Jun 2007) | 4 lines
Fix an issue where the line number in an unterminated comment block error message would show the wrong line number.
"Reported" to me on #asterisk (somebody posted an error message, and I happened to catch it)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@69470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
formats already match up. There are code paths that call this function on a
pair of channels multiple times. This made calls fail that were using g729
in some cases. The reason is that codec_g729a will unregister itself from the
list of available translators will all licenses are in use. So, the first
time the function got called, the right translation path was allocated.
However, the second time it got called, the code would not find a translation
path to/from g729 and make the call fail, even if the channel actually already
had a g729 translation path allocated.
(SPD-32)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@69010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r67715 | russell | 2007-06-06 11:40:51 -0500 (Wed, 06 Jun 2007) | 5 lines
We have some bug reports showing crashes due to a double free of a channel.
Add a sanity check to ast_channel_free() to make sure we don't go on trying
to free a channel that wasn't found in the channel list.
(issue #8850, and others...)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67716 65c4cc65-6c06-0410-ace0-fbb531ad65f3
bogus on my machine. ast_safe_string_alloc() was broken. It called
vsnprintf() on a va_args list twice without re-initializing it. After the first
usage, va_end() and va_start() must be called again.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
all of the modules. "stop now" is considered a non-graceful shutdown and will
not go through this process.
(issue #9804, reported by chrisost, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
oscillating and incorrect data. Additionally, the RTT would sometimes report
negative values due to incorrect calculations.
(issue #9601, patch from davetroy)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@65842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I realize that there are other ways to get this,
but we really don't need to just show it in plain text so easily.
Issue 9273, patch by junky
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63982 65c4cc65-6c06-0410-ace0-fbb531ad65f3
either because the Challenge action was never issued, or some other reason,
give a proper error message and return an error instead of claiming that the
user wasn't found.
(reported by jsmith on IRC)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
code in that if a channel does not have a send_digit_begin() callback, it only
cares about DTMF END events. (pointed out by Michael Neuhauser on the
asterisk-dev list)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
send_digit_begin() callback. Checking the END_DTMF_ONLY flag was the
wrong thing to do, because that flag indicates that a *bridged* channel
only wants DTMF END events coming from this channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes came from a debugging session I had with Dwayne Hubbard.
When he called into his home FXO, ran the Echo application, and pressed a
digit, the digit would be echoed back and would never end. This is fixed,
along with a couple other little improvements.
* When chan_zap is in the middle of playing a digit to a channel, it feeds
back null frames, not voice frames. So, I have modified ast_read to check
the timing on emulated DTMF when it receives null frames, in addition to
where it was doing this on voice frames.
* Make a tweak to setting the duration on emulated DTMF digits. If there was
no duration specified, it set it to be the minimum, instead of the default.
* Instead of timing the emulated digits off of the number of samples in audio
frames that pass through, just use time values. Now there is no code in this
section that assumes 8kHz audio.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@62942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
