https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r77942 | murf | 2007-08-02 11:56:37 -0600 (Thu, 02 Aug 2007) | 1 line
This patch hopefully solves 10141; The user is running with it, and it doesn't appear to harm asterisk's operation, and may prevent a crash. I'll store it in 1.2, as we have shut down support on 1.2, but since I developed the patch before support finished, and it might affect 1.4 and trunk, I'm going ahead with it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
request an "unknown" character such as a comma.
Instead, skip the character and move on.
Issue 10083, initial patch by jsmith, modified by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: fnordian
Patches:
asterisk-1.4.9-channel.c.patch uploaded by fnordian (license 110)
Additional changes by me
Fix some problems in channel_find_locked() which can cause an infinite loop.
The reference to the previous channel is set to NULL in some cases. These changes
ensure that the reference to the previous channel gets restored before needing
it again.
I'm not convinced that the code that is setting it to NULL is really the right
thing to do. However, I am making these changes to fix the obvious problem
and just leaving an XXX comment that it needs a better explanation that what
is there now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: fnordian
Patches:
asterisk-1.4.9-channel.c.patch uploaded by fnordian (license 110)
Restore previous behavior where if we failed to lock the channel we wanted we would return to exactly the same point as if we had just reentered the function.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: litnialex
If a DTMF end frame comes from a channel without a begin and it is going to a technology that only accepts end frames (aka INFO) then use the minimum DTMF duration if one is not in the frame already.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
attempted compilation. The makefile now defines AST_DEVMODE if configure was run with --enable-dev-mode. Also, changes were
made to acccomodate 64 bit systems in ast_backtrace.
Thanks to qwell, kpfleming, and Corydon76 for their roles in allowing me to get this committed
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77380 65c4cc65-6c06-0410-ace0-fbb531ad65f3
DTMF digit in the ast_senddigit() function. The define is set to 100ms by
default, which is the same thing that this function was using. But, using
the define lets changes take effect in this case, as well as the others where
it was already used.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: juggie
Patches:
10209-trunk-2.patch uploaded by juggie
Tested by: juggie, blitzrage
In ast_pbx_run(), mark a channel as hung up after an application returned -1,
or when it runs out of extensions to execute. This is so that code can detect
that this channel has been hung up for things like making sure DeadAGI is used
on actual dead channels, and is beneficial for other things, like making sure
someone doesn't try to start spying on a channel that is about to go away.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75403 65c4cc65-6c06-0410-ace0-fbb531ad65f3
variable declarations in the middle of a block.
Fix the few instances of the above spotted out by the compiler.
All of this has been already done or is not applicable in trunk,
so the merge of this change will be blocked.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@72462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r72373 | bbryant | 2007-06-27 18:22:13 -0500 (Wed, 27 Jun 2007) | 3 lines
Reinstating patch. This actually fixes the problem, however I was running a development branch without it and mistakenly thought it wasn't fixed.
Fixes issue #10010, and #9654: 100% CPU usage caused by an asterisk console losing it's controlling terminal.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@72383 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r72256 | file | 2007-06-27 16:23:24 -0400 (Wed, 27 Jun 2007) | 2 lines
I may possibly get shot for doing this... but... defer CDR processing until after the channel has been dealt with. This should eliminate all of the issues with channels going funky (SIP/PRI) when you are posting CDRs to a database that is either slow or unavailable and do not want to enable batching.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@72257 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r71064 | bbryant | 2007-06-22 09:39:34 -0500 (Fri, 22 Jun 2007) | 10 lines
Fixed infinite loop when controlling terminal was lost
and return value of input function wasn't checked for
errors. This would cause 100% cpu to be taken up.
(closes issue #9654, issue #10010)
Reported by: mnicholson, and eserra
Idea for the patch from mnicholson, patched by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@71066 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r70948 | murf | 2007-06-21 16:29:50 -0600 (Thu, 21 Jun 2007) | 1 line
This little fix is in response to bug 10016, but may not cure it. The code is wrong, clearly. In a situation where you set the CDR's amaflags, and then ForkCDR, and then set the new CDR's amaflags to some other value, you will see that all CDRs have had their amaflags changed. This is not good. So I fixed it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@70949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r70053 | murf | 2007-06-19 12:07:59 -0600 (Tue, 19 Jun 2007) | 1 line
This fixes 9246, where channel variables are not available in the 'h' exten, on a 'ZOMBIE' channel. The fix is to consolidate the channel variables during a masquerade, and then copy the merged variables back onto the clone, so the zombie has the same vars that the 'original' has.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@70062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
Fix some issues related to generating inband DTMF. There are two changes here:
1) The list of DTMF tones in the senddigit_begin() function explicitly
specified 100ms of the tone followed by 100ms of silence. This really
broke things with the way that Asterisk now wants complete control
over when the digit begins and ends. So, regardless of what Asterisk
really wanted to do, this was going to play out the tone at the length it
wanted to. This caused various problems like DTMF translation to inband to
be extremely unreliable.
The list of tones has been changed so that the correct DTMF tone is played
indefinitely until Asterisk tells it to stop.
2) ast_write() had to be modified to let a DTMF_END frame get processed even
when a generator is present. This is how the tone will finally get stopped.
(issues #8944, #9250, #9348, maybe others. Thanks to mdu113 from #8944 for
the testing and feedback!)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@62789 65c4cc65-6c06-0410-ace0-fbb531ad65f3
don't even bother creating a temporary bogus channel, since that is only for
allowing certain functions to operate on the variables as if they were on a
channel. Most importantly, this fixes a crash.
(issue #9613, reported by callguy, fixed by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@62171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the asterisk-dev mailing list. I changed the enforced minimum length of a
digit from 100ms to 80ms. Furthermore, I made it now enforce a gap of 45ms in
between digits. These values are not configurable in a configuration file
right now, but they can be easily changed near the top of main/channel.c.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
will get notified of these changes even when an owner channel is not provided.
This isn't from a specific bug report, it's just something I noticed while
poking around.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channel. So, this little hack lets them work in places where a channel doesn't
exist, such as within DUNDi configuration.
(issue #9465, reported and patched by Corydon76, testing by blitzrage)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61765 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per comment from Dave Troy:
This adds back in some simple typecasting I had in an earlier version
which I realize now may be breaking things.
Issue #9554.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
However, after much discussion, it has been decided that adding this to 1.4 is
not in the best interests of the project. It has been removed here, but will
remain in trunk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61220 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r60849 | tilghman | 2007-04-08 21:49:06 -0500 (Sun, 08 Apr 2007) | 2 lines
Don't check for error when lowering priority (according to the manpage, it should never happen anyway). It might could happen, though, if another thread messed with the priority, so safeguard against that (reported via -dev list).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@60850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk GUI project, we need a fully functional HTTP interface with access
to the Asterisk manager interface. One of the things that was intended to be
a part of this system, but was never actually implemented, was the ability for
the GUI to be able to upload files to Asterisk. So, this commit adds this in
the most minimally invasive way that we could come up with.
A lot of work on minimime was done by Steve Murphy. He fixed a lot of bugs in
the parser, and updated it to be thread-safe. The ability to check
permissions of active manager sessions was added by Dwayne Hubbard. Then,
hacking this all together and do doing the modifications necessary to the HTTP
interface was done by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@60603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Steve Murphy
Joshua Colp
Jim Dixon
Jason Parker
Russell Bryant
Mark Michelson
Tilghman Lesher
Luigi Rizzo
Kevin P. Fleming
Brett Bryant
Olle Johansson
Doug Bailey