https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269821 | mmichelson | 2010-06-10 14:30:12 -0500 (Thu, 10 Jun 2010) | 19 lines
Fix potential crash when writing raw SLIN audio on a PLC-enabled channel.
The issue here was that the frame created when adjusting for PLC had no offset
to its audio data. If this frame were translated to another format prior to
being sent out an RTP socket, all went well because the translation code would
put an appropriate offset into the frame. However, if the SLIN audio were not
translated before being sent out the RTP socket, bad things would happen.
Specifically, the ast_rtp_raw_write makes the assumption that the frame has
at least enough of an offset that it can accommodate an RTP header. This was
not the case. As such, data was being written prior to the allocation, likely
corrupting the data the memory allocator had written. Thus when the time came
to free the data, all hell broke loose. ....Well, Asterisk crashed at least.
The fix was just what one would expect. Offset the data in the frame by a reasonable
amount. The method I used is a bit odd since the data in the frame is 16 bit integers
and not bytes. I left a big ol' comment about it. This can be improved on if someone
is interested. I was more interested in getting the crash resolved.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r269426 | qwell | 2010-06-09 16:19:17 -0500 (Wed, 09 Jun 2010) | 6 lines
Let systems without a working fork() use res_musiconhold.
Files mode doesn't require anything special, so that can still be used just fine.
AST-357
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269486 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind pointed out that attempting to get an IE value from an event that has
no IEs produces an invalid memory read past the end of the event. Thanks to
mmichelson for pointing the problem out to me and then testing the fix.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269334 | pabelanger | 2010-06-09 13:24:53 -0400 (Wed, 09 Jun 2010) | 12 lines
Fix Debian init script to not use -c.
When using the init script as-is currently, it could cause issues on Debian
such as high CPU usage. This fix has worked for several people so I'm
implementing the change. We now handle color displays properly.
(closes issue #16784)
Reported by: pabelanger
Patches:
20100530__issue16784__2.diff.txt uploaded by tilghman (license 14)
Tested by: pabelanger, tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269346 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling dahdi_indicate() within dahdi_fixup() while the owner pointers are
in a potentially inconsistent state is a potentially bad thing in
principle.
However, calling dahdi_indicate() when the channel private lock is already
held can cause a deadlock if the PRI lock is needed because
dahdi_indicate() will also get the channel private lock. The pri_grab()
function assumes that the channel private lock is held once to avoid
deadlock.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The result for moh_register was not verified to guarantee
the mohclass as added to the container.
(closes issue #16993)
Reported by: dmitri
Patches:
res_musiconhold_rtclass2.patch uploaded by dmitri (license 1001)
moh_crash2.diff uploaded by dvossel (license 671)
Tested by: dmitri
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269271 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* chan_dahdi supports dialing configuring and dialing by device file name.
DAHDI/span-name!local!1 will use /dev/dahdi/span-name/local/1 . Likewise
it may appear in chan_dahdi.conf as 'channel => span-name!local!1'.
* A new options for chan_dahdi.conf: 'ignore_failed_channels'. Boolean.
False by default. If set, chan_dahdi will ignore failed 'channel' entries.
Handy for the above name-based syntax as it does not depend on
initialization order.
* have my_pri_make_cc_dialstring() only manupulate dial-strings of group
(gGrR) dialing, which make it lsightly more complicated.
https://reviewboard.asterisk.org/r/535/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
People expressed an interest in having access to the exact length of calls to a finer degree than seconds. See the CHANGES and UPGRADE.txt for usage also updated the sample configs to note the change.
Patch by snuffy.
(closes issue #16559)
Reported by: cianmaher
Tested by: cianmaher, snuffy
Review: https://reviewboard.asterisk.org/r/461/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269006 | seanbright | 2010-06-08 11:28:49 -0400 (Tue, 08 Jun 2010) | 11 lines
Reduce startup time for cdr_tds with large CDR tables.
Since we are just checking for table existence, add a WHERE clause that will
return no rows but will raise an error if the table doesn't exist.
(closes issue #17380)
Reported by: kkwong
Patches:
issue17380-01.patch uploaded by seanbright (license 71)
Tested by: kkwong
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Extract the SS7 specific code out of chan_dahdi like what was done to
ISDN/PRI and analog signaling. The new SS7 structures were modeled on
sig_pri.
The changes to sig_pri are an enhancement and a bug fix made possible
because SS7 was extracted.
1) The sig_pri TRANSFERCAPABILITY channel variable should have been set
unconditionally in sig_pri_new_ast_channel().
2) SS7/PRI transfer capability interaction in dahdi_new() fixed because of
SS7 extraction.
3) Module ref count error in dahdi_new() if startpbx failed to start the
PBX for some reason.
Review: https://reviewboard.asterisk.org/r/661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Suppress the warning about unexpected control subclass frames for
AST_CONTROL_CONNECTED_LINE, AST_CONTROL_REDIRECTING, and AST_CONTROL_AOC
in file.c:waitstream_core().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268578 65c4cc65-6c06-0410-ace0-fbb531ad65f3
What I did not originally see in my previous commit was that even though the
next digit could be detected before the previous was considered ended, the
detection of the next digit effectively ends the detection of the previous.
Therefore, the length moves in lockstep with the digit, and no separate counter
is needed for the length alone.
(closes issue #17371)
Reported by: alecdavis
(closes issue #17474)
Reported by: kenner
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
