https://origsvn.digium.com/svn/asterisk/trunk
........
r269417 | russell | 2010-06-09 16:11:43 -0500 (Wed, 09 Jun 2010) | 6 lines
Resolve an invalid memory read on an event.
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/branches/1.6.2@269418 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r269346 | pabelanger | 2010-06-09 13:32:52 -0400 (Wed, 09 Jun 2010) | 19 lines
Merged revisions 269334 via svnmerge from
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/branches/1.6.2@269347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r268456 | tilghman | 2010-06-05 12:55:28 -0500 (Sat, 05 Jun 2010) | 14 lines
Fix crash in DTMF detection.
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/branches/1.6.2@268457 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r267303 | russell | 2010-06-02 16:41:54 -0500 (Wed, 02 Jun 2010) | 6 lines
Ensure the -Wno-strict-aliasing flag makes it, even if ASTCFLAGS has been specified.
When ASTCFLAGS was specified with the make command, Makefile.rules was using
the specified value from the command line and not the one here, making it so this
flag would go missing.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@267304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r266682 | tilghman | 2010-06-01 11:41:00 -0500 (Tue, 01 Jun 2010) | 16 lines
Eliminate stale manager events after a set interval, even if AMI clients don't query for them.
Actions (or failures to act) by external clients should not cause memory leaks
in Asterisk, especially when those continued leaks could cause Asterisk to
misbehave later.
(closes issue #17234)
Reported by: mav3rick
Patches:
20100510__issue17234.diff.txt uploaded by tilghman (license 14)
20100517__issue17234__trunk.diff.txt uploaded by tilghman (license 14)
Tested by: mav3rick, davidw
(closes issue #17365)
Reported by: davidw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@266683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r266592 | tilghman | 2010-06-01 10:18:59 -0500 (Tue, 01 Jun 2010) | 18 lines
Merged revisions 266585 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r266585 | tilghman | 2010-06-01 10:17:46 -0500 (Tue, 01 Jun 2010) | 11 lines
Prevent CLI prompt from distorting output of lines shorter than the prompt.
Uses the VT100 method of clearing the line from the cursor position to the
end of the line: Esc-0K
(closes issue #17160)
Reported by: coolmig
Patches:
20100531__issue17160.diff.txt uploaded by tilghman (license 14)
Tested by: coolmig
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@266598 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r266146 | tilghman | 2010-05-26 16:17:46 -0500 (Wed, 26 May 2010) | 21 lines
Merged revisions 266142 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r266142 | tilghman | 2010-05-26 16:11:44 -0500 (Wed, 26 May 2010) | 14 lines
Use sigaction for signals which should persist past the initial trigger, not signal.
If you call signal() in a Solaris signal handler, instead of just resetting
the signal handler, it causes the signal to refire, because the signal is not
marked as handled prior to the signal handler being called. This effectively
causes Solaris to immediately exceed the threadstack in recursive signal
handlers and crash.
(closes issue #17000)
Reported by: rmcgilvr
Patches:
20100526__issue17000.diff.txt uploaded by tilghman (license 14)
Tested by: rmcgilvr
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@266154 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r265320 | twilson | 2010-05-24 14:06:40 -0500 (Mon, 24 May 2010) | 14 lines
Add the FullyBooted AMI event
It is possible to connect to the manager interface before all Asterisk modules
are loaded. To ensure that an application does not send AMI actions that might
require a module that has not yet loaded, the application can listen for the
FullyBooted manager event. It will be sent upon connection if all modules have
been loaded, or as soon as loading is complete. The event:
Event: FullyBooted
Privilege: system,all
Status: Fully Booted
Review: https://reviewboard.asterisk.org/r/639/
........
r265467 | twilson | 2010-05-24 17:21:58 -0500 (Mon, 24 May 2010) | 1 line
Merge the rest of the FullyBooted patch
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@265521 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r264997 | mmichelson | 2010-05-21 11:44:27 -0500 (Fri, 21 May 2010) | 38 lines
Merged revisions 264996 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264996 | mmichelson | 2010-05-21 11:28:34 -0500 (Fri, 21 May 2010) | 32 lines
Allow ast_safe_sleep to defer specific frames until after the sleep has concluded.
From reviewboard
Background:
A Digium customer discovered a somewhat odd bug. The setup is that parties A
and B are bridged, and party A places party B on hold. While party B is
listening to hold music, he mashes a bunch of DTMF. Party A takes party
B off hold while this is happening, but party B continues to hear hold
music. I could reproduce this about 1 in 5 times.
The issue:
When DTMF features are enabled and a user presses keys, the channel that
the DTMF is streamed to is placed in an ast_safe_sleep for 100 ms, the
duration of the emulated tone. If an AST_CONTROL_UNHOLD frame is read
from the channel during the sleep, the frame is dropped. Thus the
unhold indication is never made to the channel that was originally placed
on hold.
The fix:
Originally, I discussed with Kevin possible ways of fixing the specific
problem reported. However, we determined that the same type of problem
could happen in other situations where ast_safe_sleep() is used. Using
autoservice as a model, I modified ast_safe_sleep_conditional() to
defer specific frame types so they can be re-queued once the sleep has
finished. I made a common function for determining if a frame should
be deferred so that there are not two identical switch blocks to
maintain.
Review: https://reviewboard.asterisk.org/r/674/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r264828 | rmudgett | 2010-05-20 18:29:43 -0500 (Thu, 20 May 2010) | 13 lines
Merged revisions 264820 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264820 | rmudgett | 2010-05-20 18:23:21 -0500 (Thu, 20 May 2010) | 6 lines
ast_callerid_parse() had a path that left name uninitialized.
Several callers of ast_callerid_parse() do not initialize the name
parameter before calling thus there is the potential to use an
uninitialized pointer.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r264452 | mmichelson | 2010-05-19 16:29:08 -0500 (Wed, 19 May 2010) | 86 lines
Fix transcode_via_sln option with SIP calls and improve PLC usage.
From reviewboard:
The problem here is a bit complex, so try to bear with me...
It was noticed by a Digium customer that generic PLC (as configured in
codecs.conf) did not appear to actually be having any sort of benefit when
packet loss was introduced on an RTP stream. I reproduced this issue myself
by streaming a file across an RTP stream and dropping approx. 5% of the
RTP packets. I saw no real difference between when PLC was enabled or disabled
when using wireshark to analyze the RTP streams.
After analyzing what was going on, it became clear that one of the problems
faced was that when running my tests, the translation paths were being set
up in such a way that PLC could not possibly work as expected. To illustrate,
if packets are lost on channel A's read stream, then we expect that PLC will
be applied to channel B's write stream. The problem is that generic PLC can
only be done when there is a translation path that moves from some codec to
SLINEAR. When I would run my tests, I found that every single time, read
and write translation paths would be set up on channel A instead of channel
B. There appeared to be no real way to predict which channel the translation
paths would be set up on.
This is where Kevin swooped in to let me know about the transcode_via_sln
option in asterisk.conf. It is supposed to work by placing a read translation
path on both channels from the channel's rawreadformat to SLINEAR. It also
will place a write translation path on both channels from SLINEAR to the
channel's rawwriteformat. Using this option allows one to predictably set up
translation paths on all channels. There are two problems with this, though.
First and foremost, the transcode_via_sln option did not appear to be working
properly when I was placing a SIP call between two endpoints which did not
share any common formats. Second, even if this option were to work, for PLC
to be applied, there had to be a write translation path that would go from
some format to SLINEAR. It would not work properly if the starting format
of translation was SLINEAR.
The one-line change presented in this review request in chan_sip.c fixed the
first issue for me. The problem was that in sip_request_call, the
jointcapability of the outbound channel was being set to the format passed to
sip_request_call. This is nativeformats of the inbound channel. Because of this,
when ast_channel_make_compatible was called by app_dial, both channels already
had compatibly read and write formats. Thus, no translation path was set up at
the time. My change is to set the jointcapability of the sip_pvt created during
sip_request_call to the intersection of the inbound channel's nativeformats and
the configured peer capability that we determined during the earlier call to
create_addr. Doing this got the translation paths set up as expected when using
transcode_via_sln.
The changes presented in channel.c fixed the second issue for me. First and
foremost, when Asterisk is started, we'll read codecs.conf to see the value of
the genericplc option. If this option is set, and ast_write is called for a
frame with no data, then we will attempt to fill in the missing samples for
the frame. The implementation uses a channel datastore for maintaining the
PLC state and for creating a buffer to store PLC samples in. Even when we
receive a frame with data, we'll call plc_rx so that the PLC state will have
knowledge of the previous voice frame, which it can use as a basis for when
it comes time to actually do a PLC fill-in.
So, reviewers, now I ask for your help. First off, there's the one line change
in chan_sip that I have put in. Is it right? By my logic it seems correct, but
I'm sure someone can tell me why it is not going to work. This is probably the
change I'm least concerned about, though. What concerns me much more is the
set of changes in channel.c. First off, am I even doing it right? When I run
tests, I can clearly see that when PLC is activated, I see a significant increase
in RTP traffic where I would expect it to be. However, in my humble opinion, the
audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to
me than when no PLC is used at all. I need someone to review the logic I have used
to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic
is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm
sure someone can point out somewhere where I've done something incorrectly.
As I was writing this review request up, I decided to give the code a test run under
valgrind, and I find that for some reason, calls to plc_rx are causing some invalid
reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around
a bit to see why that is the case. If it's obvious to someone reviewing, speak up!
Finally, I have one other proposal that is not reflected in my code review. Since
without transcode_via_sln set, one cannot predict or control where a translation
path will be up, it seems to me that the current practice of using PLC only when
transcoding to SLINEAR is not useful. I recommend that once it has been determined
that the method used in this code review is correct and works as expected, then
the code in translate.c that invokes PLC should be removed.
Review: https://reviewboard.asterisk.org/r/622/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264453 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r264400 | dvossel | 2010-05-19 15:30:33 -0500 (Wed, 19 May 2010) | 11 lines
fixes infinite loop during udptl.c's decode_open_type
When decode_length returns the length there is a check to see if that
length is negative, if so the decode loop breaks as this means the
limit has been reached. The problem here is that length is an
unsigned int, so length can never be negative. This resulted in
an infinite loop.
(issue #17352)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264405 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r264114 | dvossel | 2010-05-19 09:38:02 -0500 (Wed, 19 May 2010) | 13 lines
fixes crash during dtmf
During the processing of Cisco dtmf the dtmf samples were
not being calculated correctly. In an attempt to determine
what sample rate was being used, a NULL frame was processed
which caused a crash. This patch resolves this.
(closes issue #17248)
Reported by: falves11
Patches:
issue_17248.diff uploaded by dvossel (license 671)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r263640 | mmichelson | 2010-05-17 17:08:01 -0500 (Mon, 17 May 2010) | 16 lines
Merged revisions 263639 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r263639 | mmichelson | 2010-05-17 17:00:28 -0500 (Mon, 17 May 2010) | 10 lines
Fix logic error when checking for a devstate provider.
When using strsep, if one of the list of specified separators is not found,
it is the first parameter to strsep which is now NULL, not the pointer returned
by strsep.
This issue isn't especially severe in that the worst it is likely to do is waste
some cycles when a device with no '/' and no ':' is passed to ast_device_state.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@263642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r263457 | lmadsen | 2010-05-17 09:37:35 -0500 (Mon, 17 May 2010) | 19 lines
Recorded merge of revisions 263456 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r263456 | lmadsen | 2010-05-17 09:35:18 -0500 (Mon, 17 May 2010) | 11 lines
Manager cookies are not compatible with RFC2109.
The Version field in the cookies we're setting contain quotes around the version
number which is not compatible with RFC2109 and breaks some implementations.
(closes issue #17231)
Reported by: ecarruda
Patches:
manager_rfc2109-trunk-v1.patch uploaded by ecarruda (license 559)
manager_rfc2109-1.6.2-v1.patch uploaded by ecarruda (license 559)
Tested by: ecarruda, russell
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@263458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r261496 | russell | 2010-05-06 08:58:07 -0500 (Thu, 06 May 2010) | 40 lines
Fix handling of removing nodes from the middle of a heap.
This bug surfaced in 1.6.2 and does not affect code in any other released
version of Asterisk. It manifested itself as SIP qualify not happening when
it should, causing peers to go unreachable. This was debugged down to scheduler
entries sometimes not getting executed when they were supposed to, which was in
turn caused by an error in the heap code.
The problem only sometimes occurs, and it is due to the logic for removing an entry
in the heap from an arbitrary location (not just popping off the top). The scheduler
performs this operation frequently when entries are removed before they run (when
ast_sched_del() is used).
In a normal pop off of the top of the heap, a node is taken off the bottom,
placed at the top, and then bubbled down until the max heap property is restored
(see max_heapify()). This same logic was used for removing an arbitrary node
from the middle of the heap. Unfortunately, that logic is full of fail. This
patch fixes that by fully restoring the max heap property when a node is thrown
into the middle of the heap. Instead of just pushing it down as appropriate, it
first pushes it up as high as it will go, and _then_ pushes it down.
Lastly, fix a minor problem in ast_heap_verify(), which is only used for
debugging. If a parent and child node have the same value, that is not an
error. The only error is if a parent's value is less than its children.
A huge thanks goes out to cappucinoking for debugging this down to the scheduler,
and then producing an ast_heap test case that demonstrated the breakage. That
made it very easy for me to focus on the heap logic and produce a fix. Open source
projects are awesome.
(closes issue #16936)
Reported by: ib2
Tested by: cappucinoking, crjw
(closes issue #17277)
Reported by: cappucinoking
Patches:
heap-fix.rev2.diff uploaded by russell (license 2)
Tested by: cappucinoking, russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@261498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r261095 | tilghman | 2010-05-04 18:51:52 -0500 (Tue, 04 May 2010) | 18 lines
Merged revisions 261093-261094 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r261093 | tilghman | 2010-05-04 18:36:53 -0500 (Tue, 04 May 2010) | 7 lines
Protect against overflow, when calculating how long to wait for a frame.
(closes issue #17128)
Reported by: under
Patches:
d.diff uploaded by under (license 914)
........
r261094 | tilghman | 2010-05-04 18:47:08 -0500 (Tue, 04 May 2010) | 2 lines
Add a tiny corner case to the previous commit
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@261098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r254450 | kpfleming | 2010-03-25 10:27:31 -0500 (Thu, 25 Mar 2010) | 49 lines
Improve handling of T.38 re-INVITEs that arrive before a T.38-capable
application is executing on a channel.
This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.
This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.
This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).
This patch also modifies res_fax to take advantage of the new request.
In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.
This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.
Review: https://reviewboard.asterisk.org/r/556/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r260292 | tilghman | 2010-04-30 01:19:35 -0500 (Fri, 30 Apr 2010) | 13 lines
Don't allow file descriptors to go above 64k, when we're closing them in a fork(2).
This saves time, when, even though the system allows the process limit to be
that high, the practical limit is much lower.
(closes issue #17223)
Reported by: dbackeberg
Patches:
20100423__issue17223.diff.txt uploaded by tilghman (license 14)
Tested by: dbackeberg
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r260050 | dvossel | 2010-04-29 10:33:27 -0500 (Thu, 29 Apr 2010) | 21 lines
Merged revisions 260049 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260049 | dvossel | 2010-04-29 10:31:02 -0500 (Thu, 29 Apr 2010) | 14 lines
Fixes crash in audiohook_write_list
The middle_frame in the audiohook_write_list function was
being freed if a audiohook manipulator returned a failure.
This is incorrect logic. This patch resolves this and
adds detailed descriptions of how this function should work
and why manipulator failures must be ignored.
(closes issue #17052)
Reported by: dvossel
Tested by: dvossel
(closes issue #16196)
Reported by: atis
Review: https://reviewboard.asterisk.org/r/623/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r259870 | dvossel | 2010-04-28 16:20:03 -0500 (Wed, 28 Apr 2010) | 39 lines
Merged revisions 259858 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010) | 33 lines
resolves deadlocks in chan_local
Issue_1.
In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan,
and pvt->owner. Proper deadlock avoidance is done when the channel to hangup
is the outbound chan_local channel, but when it is not the outbound channel we
have an issue... We attempt to do deadlock avoidance only on the tech pvt, when
both the tech pvt and the pvt->owner are locked coming into that loop. By
never giving up the pvt->owner channel deadlock avoidance is not entirely possible.
This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt
when trying to get the pvt->chan lock.
Issue_2.
ast_prod() is used in ast_activate_generator() to queue a frame on the channel
and make the channel's read function get called. This function is used in
ast_activate_generator() while the channel is locked, which mean's the channel
will have a lock both from the generator code and the frame_queue code by the
time it gets to chan_local.c's local_queue_frame code... local_queue_frame
contains some of the same crazy deadlock avoidance that local_hangup requires,
and this recursive lock prevents that deadlock avoidance from happening correctly.
This patch removes ast_prod() from the channel lock so only one lock is held during
the local_queue_frame function.
(closes issue #17185)
Reported by: schmoozecom
Patches:
issue_17185_v1.diff uploaded by dvossel (license 671)
issue_17185_v2.diff uploaded by dvossel (license 671)
Tested by: schmoozecom, GameGamer43
Review: https://reviewboard.asterisk.org/r/631/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r259439 | qwell | 2010-04-27 16:13:01 -0500 (Tue, 27 Apr 2010) | 5 lines
Add gar to the check for AR for those silly OSes (Solaris) that don't have ar.
autoconf2.13 couldn't handle AC_PROG_GREP, so I removed it. This is fine,
since we don't need to use anything that the configure script doesn't.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259486 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r259023 | mmichelson | 2010-04-26 16:13:35 -0500 (Mon, 26 Apr 2010) | 19 lines
Merged revisions 259018 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259018 | mmichelson | 2010-04-26 16:03:08 -0500 (Mon, 26 Apr 2010) | 13 lines
Prevent Newchannel manager events for dummy channels.
No Newchannel manager event will be fired for channels that are
allocated to not match a registered technology type. Thus bogus
channels allocated solely for variable substitution or CDR
operations do not result in a Newchannel event.
(closes issue #16957)
Reported by: atis
Review: https://reviewboard.asterisk.org/r/601
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
For 1.6.2, only merge the bug fixes, not the unit test.
........
r258632 | russell | 2010-04-22 16:06:53 -0500 (Thu, 22 Apr 2010) | 22 lines
Add ast_event subscription unit test and fix some ast_event API bugs.
This patch introduces another test in test_event.c that exercises most of the
subscription related ast_event API calls. I made some minor additions to the
existing event allocation test to increase API coverage by the test code.
Finally, I made a list in a comment of API calls not yet touched by the test
module as a to-do list for future test development.
During the development of this test code, I discovered a number of bugs in
the event API.
1) subscriptions to AST_EVENT_ALL were not handled appropriately in a couple
of different places. The API allows a subscription to all event types,
but with IE parameters, just as if it was a subscription to a specific
event type. However, the parameters were being ignored. This affected
ast_event_check_subscriber() and event distribution to subscribers.
2) Some of the logic in ast_event_check_subscriber() for checking subscriptions
against query parameters was wrong.
Review: https://reviewboard.asterisk.org/r/617/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@258672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r257947 | qwell | 2010-04-19 16:49:30 -0500 (Mon, 19 Apr 2010) | 6 lines
Don't consider a missing indications.conf to be a critical error.
There were many changes in revision 176627 which would avoid the error that a
missing config would have caused. Other than this, there are no other config
files (including asterisk.conf, surprisingly) that are required.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@257948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r257262 | tilghman | 2010-04-14 17:57:35 -0500 (Wed, 14 Apr 2010) | 15 lines
Yet another issue where the conversion of the application delimiter to comma caused an issue.
Application arguments within the feature map could possibly contain a comma,
which conflicts with the syntax of the features.conf configuration file. This
patch allows the argument to be wrapped in parentheses or quoted, to allow the
application arguments to be interpreted as a single configuration parameter.
(closes issue #16646)
Reported by: pinga-fogo
Patches:
20100414__issue16646.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
Review: https://reviewboard.asterisk.org/r/547/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@257265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r257146 | mnicholson | 2010-04-13 13:10:30 -0500 (Tue, 13 Apr 2010) | 16 lines
Merged revisions 257070 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257070 | mnicholson | 2010-04-13 11:46:30 -0500 (Tue, 13 Apr 2010) | 9 lines
Add an option to restore past broken behavor of the Events manager action
Before r238915, certain values for the EventMask parameter of the Events action would result in no response being returned. This patch adds an option to restore that broken behavior. Also while fixing this bug I discovered that passing an empty EventMasks parameter would also result in no response being returned, this has been fixed as well while being preserved when the broken behavior is requested.
(closes issue #17023)
Reported by: nblasgen
Review: https://reviewboard.asterisk.org/r/602/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@257184 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r254454 | mmichelson | 2010-03-25 11:04:48 -0500 (Thu, 25 Mar 2010) | 50 lines
Recorded merge of revisions 254452 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r254452 | mmichelson | 2010-03-25 10:59:56 -0500 (Thu, 25 Mar 2010) | 44 lines
Several fixes regarding RFC2833 DTMF detection.
Here is a copy and paste of the details from my request on
reviewboard that dealt with these changes:
Fix 1. The first change in place is to fix Mantis issue 15811, which deals with a situation where Asterisk will incorrectly interpret out of order RFC2833 frames as duplicate DTMF digits. For instance, we would receive a sequence like:
seqno 1: DTMF 1
seqno 2: DTMF 1
seqno 3: DTMF 1
seqno 4: DTMF 1
seqno 6: DTMF 1 (end)
seqno 5: DTMF 1
seqno 7: DTMF 1 (end)
seqno 8: DTMF 1 (end)
Prior to this patch when we received the frame with seqno 5, we would interpret this as a new DTMF 1. With this patch, we will check the seqno of the incoming digit and not process the frame if the seqno is lower than the last recorded seqno. Note that we do not record the seqno of the dropped DTMF frame for future processing. While the above situation is what was designed to be fixed, the patch is written in such a way that the following would also be fixed too:
seqno 9: DTMF 1
seqno 10: DTMF 1 (end)
seqno 11: DTMF 1 (end)
seqno 13: DTMF 2
seqno 12: DTMF 1 (end)
seqno 14: DTMF 2
seqno 15: DTMF 2 (end)
seqno 16: DTMF 2 (end)
seqno 17: DTMF 2 (end)
In this second situation, the beginning of the DTMF 2 arrives before the final end frame of the DTMF 1. With the patch, seqno 12 is no processed and thus we properly interpret the DTMF.
Fix 2. The second change in place is to fix an issue like the following:
seqno 1: DTMF 1
seqno 2: DTMF 1
seqno 3: DTMF 1 (end) *packet lost*
seqno 4: DTMF 1 (end) *packet lost*
seqno 5: DTMF 1 (end) *packet lost*
seqno 6: DTMF 2
When we receive seqno 6, we had code in place that was supposed to properly end the previously unended DTMF 1. The problem was that the code was essentially a no-op. The code would set up an end frame for the DTMF 1 but would immediately overwrite the frame with the begin for DTMF 2. I changed process_dtmf_rfc2833() so that instead of returning a single frame, it is given as an output parameter a list of frames. Each frame that needs to be returned is appended to this list.
Fix 3. The final change is a minor one where an AST_CONTROL_SRCCHANGE frame could get lost. If we process a cisco DTMF or an RFC 3389 frame and no frame was returned, then we would return &ast_null_frame. The problem is that earlier in the function, we may have generated an AST_CONTROL_SRCCHANGE frame and put it in the list of frames we wish to return. This frame would be lost in such a case. The patch fixes this problem
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@254482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r254050 | jpeeler | 2010-03-23 16:17:23 -0500 (Tue, 23 Mar 2010) | 14 lines
Exit native bridging early for greater timing accuracy with warnings
This changes native bridging to break one millisecond early so that the more
accurate timeval calculations done in the generic bridge can be performed using
the bridge config. Currently the time between exiting native bridging slightly
late can sometimes cause a large enough discrepancy for warnings to be missed.
For the record, 1.4 does not attempt to native bridge at all when warnings are
enabled.
(closes issue #15815)
Reported by: adomjan
Review: https://reviewboard.asterisk.org/r/577/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@254068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r253490 | alecdavis | 2010-03-19 20:37:00 +1300 (Fri, 19 Mar 2010) | 19 lines
prevent segfault if bad magic number is encountered.
internal_ao2_ref uses INTERNAL_OBJ which mzy report 'bad magic number', but
internal_ao2_ref continues on, causing segfault.
Although AO2_MAGIC number is checked by INTERNAL_OBJ before internal_ao2_ref is
called, A02_MAGIC is being destroyed (or a wrong pointer) by the time
internal_ao2_ref uses INTERNAL_OBJ.
internal_ao2_ref now returns -1 if INTERNAL_OBJ encouters a bad magic number.
(issue #17037)
Reported by: alecdavis
Patches:
bug17037.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@253492 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r252089 | twilson | 2010-03-12 16:04:51 -0600 (Fri, 12 Mar 2010) | 20 lines
Only change the RTP ssrc when we see that it has changed
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@252137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r251679 | jpeeler | 2010-03-10 14:51:23 -0600 (Wed, 10 Mar 2010) | 13 lines
Fix ParkAndAnnounce not respecting parking options.
The patch ensures that if a peer does not exist, parking settings are read from
the channel. A unit test has been written to ensure proper operation for both
standard parking and parking using masquerades.
(closes issue #16592)
Reported by: mwyres
Patches:
bug_16592.diff uploaded by snuffy (license 35)
Review: https://reviewboard.asterisk.org/r/539/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@251685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r251631 | jpeeler | 2010-03-10 12:25:18 -0600 (Wed, 10 Mar 2010) | 14 lines
Fix jitterbuffer logging not creating logfiles.
Three changes made here:
1) Do not fail if a previous log does not exist (in fact, this is probably
expected).
2) Ensure that the file descriptor to write to gets assigned properly. I am at
a loss as to why assigning safe_fd outside the if fixes this, but it makes
the if statement slightly less complicated anyway.
3) Move up the failure message so that the errno of the failure is not
overwritten by fclose.
(closes issue #16917)
Reported by: Artem
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@251632 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r251262 | tilghman | 2010-03-07 23:12:55 -0600 (Sun, 07 Mar 2010) | 2 lines
Change needed to make Mac OS X 10.6 happy
........
r251263 | tilghman | 2010-03-07 23:15:01 -0600 (Sun, 07 Mar 2010) | 2 lines
Remove portions that weren't meant to be committed for the OS X compat fix
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@251268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r249893 | dvossel | 2010-03-02 13:08:38 -0600 (Tue, 02 Mar 2010) | 11 lines
fixes adaptive jitterbuffer configuration
When configuring the adaptive jitterbuffer, the target_extra
value not only could not be set from the configuration, but was
not even being set to its proper default. This value is required
in order for the adaptive jitterbuffer to work correctly. To resolve
this a config option has been added to expose this value to the conf
files, and a default value is provided when no config specific value
is present.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@249895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r248861 | tilghman | 2010-02-25 15:22:39 -0600 (Thu, 25 Feb 2010) | 22 lines
Merged revisions 248859 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r248859 | tilghman | 2010-02-25 15:21:05 -0600 (Thu, 25 Feb 2010) | 15 lines
Some platforms clear /var/run at boot, which makes connecting a remote console... difficult.
Previously, we only created the default /var/run/asterisk directory at install
time. While we could create it in the init script, that would not work for
those who start asterisk manually from the command line. So the safest thing
to do is to create it as part of the Asterisk boot process. This also changes
the ownership of the directory, because the pid and ctl files are created after
we setuid/setgid.
(closes issue #16802)
Reported by: Brian
Patches:
20100224__issue16802.diff.txt uploaded by tilghman (license 14)
Tested by: tzafrir
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@248864 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r228798 | tilghman | 2009-11-09 01:37:52 -0600 (Mon, 09 Nov 2009) | 14 lines
Fix various problems detected with Valgrind.
* chan_console accessed pvts after deallocation.
* The module loader did not check usecount on shutdown, which led to chan_iax2
reading a timer that was already unloaded.
(closes issue #16062)
Reported by: alexanderheinz
Patches:
20091109__issue16062.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@248011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r247335 | mmichelson | 2010-02-17 15:22:40 -0600 (Wed, 17 Feb 2010) | 20 lines
Fix two problems in ast_str functions found while writing a unit test.
1. The documentation for ast_str_set and ast_str_append state that
the max_len parameter may be -1 in order to limit the size of the
ast_str to its current allocated size. The problem was that the max_len
parameter in all cases was a size_t, which is unsigned. Thus a -1 was
interpreted as UINT_MAX instead of -1. Changing the max_len parameter
to be ssize_t fixed this issue.
2. Once issue 1 was fixed, there was an off-by-one error in the case
where we attempted to write a string larger than the current allotted
size to a string when -1 was passed as the max_len parameter. When trying
to write more than the allotted size, the ast_str's __AST_STR_USED was
set to 1 higher than it should have been. Thanks to Tilghman for quickly
spotting the offending line of code.
Oh, and the unit test that I referenced in the top line of this commit
will be added to reviewboard shortly. Sit tight...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@247337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r247076 | mmichelson | 2010-02-16 17:44:33 -0600 (Tue, 16 Feb 2010) | 12 lines
Add va_end calls to __ast_str_helper.
According to the man page for stdarg(3),
"Each invocation of va_copy() must be matched by a
corresponding invocation of va_end() in the same
function."
There were several cases in __ast_str_helper where
va_copy was not matched with a corresponding call
to va_end.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@247079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r246899 | dvossel | 2010-02-16 11:07:41 -0600 (Tue, 16 Feb 2010) | 16 lines
fixes sample rate conversion issue with Monitor application
When using ast_seekstream with the read/write streams of a monitor,
the number of samples we are seeking must be of the same rate as the
stream or the jump calculation will be incorrect. This patch adds logic
to correctly convert the number of samples to jump to the sample rate
the read/write stream is using.
For example, if the call is G722 (16khz) and the read/write stream is
recording a 8khz wav, seeking 320 samples of 16khz audio is not the
same as seeking 320 samples of 8khz audio when performing the ast_seekstream
on the stream.
ABE-2044
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@246900 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r246546 | dvossel | 2010-02-12 17:32:33 -0600 (Fri, 12 Feb 2010) | 21 lines
Merged revisions 246545 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r246545 | dvossel | 2010-02-12 17:30:17 -0600 (Fri, 12 Feb 2010) | 16 lines
lock channel during datastore removal
On channel destruction the channel's datastores are removed and
destroyed. Since there are public API calls to find and remove
datastores on a channel, a lock should be held whenever datastores are
removed and destroyed. This resolves a crash caused by a race
condition in app_chanspy.c.
(closes issue #16678)
Reported by: tim_ringenbach
Patches:
datastore_destroy_race.diff uploaded by tim ringenbach (license 540)
Tested by: dvossel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@246547 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r245578 | tilghman | 2010-02-08 16:31:40 -0600 (Mon, 08 Feb 2010) | 12 lines
Actually use _ASTLDFLAGS in the main/ and channels/ Makefiles.
They were previously passed correctly, but they simply weren't used. This
caused issues with various platforms whose builds needed to pass special
linker flags via the configure script.
(closes issue #16596)
Reported by: pprindeville
Patches:
asterisk-1.6-astldflags.patch uploaded by pprindeville (license 347)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@245581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r244505 | tilghman | 2010-02-03 12:34:29 -0600 (Wed, 03 Feb 2010) | 8 lines
The chanvar= setting should inherit the entire list of variables, not just the first one.
(closes issue #16359)
Reported by: raarts
Patches:
dahdi-setvars.diff uploaded by raarts (license 937)
Tested by: raarts
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@244508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Conditional expanded to check for hooks before aborting manager event
processing. The other two changes are just optimizations.
(closes issue #16455)
Reported by: atis
Patches:
manager_hooks_16.patch uploaded by atis (license 242)
Tested by: atis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@243989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r243244 | jpeeler | 2010-01-26 12:07:57 -0600 (Tue, 26 Jan 2010) | 12 lines
Fix crash resulting from frames with invalid data pointers.
In ast_frdup the frame data union does not get set to point to malloced memory
if the datalen is zero, so make sure to handle the same case in ast_frisolate
appropriately.
(closes issue #16058)
Reported by: atis
Patches:
bug16058-fix.patch uploaded by jpeeler (license 325)
Tested by: atis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@243247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Branch support, retains ABI, if backend CDR collector is adaptive then database
requires 'dnid' field to be added, otherwise no functional changes.
Reported by: alecdavis
Tested by: alecdavis
Patch
cdr_dnid.diff2.txt uploaded by alecdavis (license 585)
Review: https://reviewboard.asterisk.org/r/455/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@242139 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Allows CDR variables added in cdr.c:set_one_cid to become visable during the call,
by executing ast_cdr_update() early in __ast_pbx_run.
Based on cdr_update.diff3.txt
(issue #16638)
Reported by: alecdavis
Patches:
cdr_update.diff3.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@241455 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r241366 | jpeeler | 2010-01-19 16:59:53 -0600 (Tue, 19 Jan 2010) | 13 lines
Initialize data on the stack so that Park doesn't interpret random arguments.
passdata was only being set in pbx_substitue_variables when arguments were
passed.
(closes issue #16406)
(closes issue #16586)
Reported by: DLNoah
Patches:
bug16586v2.patch uploaded by jpeeler (license 325)
Tested by: DLNoah
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@241369 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r241016 | seanbright | 2010-01-18 14:57:52 -0500 (Mon, 18 Jan 2010) | 19 lines
Merged revisions 241015 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r241015 | seanbright | 2010-01-18 14:54:19 -0500 (Mon, 18 Jan 2010) | 12 lines
Plug a memory leak when reading configs with their comments.
While reading through configuration files with the intent of returning their
full contents (comments specifically) we allocated some memory and then forgot
to free it. This doesn't fix 16554 but clears up a leak I had in the lab.
(issue #16554)
Reported by: mav3rick
Patches:
issue16554_20100118.patch uploaded by seanbright (license 71)
Tested by: seanbright
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@241019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r240499 | tilghman | 2010-01-15 15:40:14 -0600 (Fri, 15 Jan 2010) | 9 lines
The previous attempt at using a pipe to guarantee astcanary shutdown did not work.
We're revisiting the previous patch, albeit with a method that overcomes the
prior criticism that it was not POSIX-compliant.
(closes issue #16602)
Reported by: frawd
Patches:
20100114__issue16602.diff.txt uploaded by tilghman (license 14)
Tested by: frawd
........
r240500 | tilghman | 2010-01-15 15:42:36 -0600 (Fri, 15 Jan 2010) | 2 lines
Oops, missed an include
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@240503 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r240078 | mnicholson | 2010-01-14 10:14:35 -0600 (Thu, 14 Jan 2010) | 2 lines
This change fixes a few bugs in the way the far max IFP was calculated that were introduced in r231692.
(closes issue #16497)
Reported by: globalnetinc
Patches:
udptl-max-ifp-fix1.diff uploaded by mnicholson (license 96)
Tested by: globalnetinc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@240079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r239839 | jpeeler | 2010-01-13 13:48:16 -0600 (Wed, 13 Jan 2010) | 18 lines
Merged revisions 239838 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r239838 | jpeeler | 2010-01-13 13:43:33 -0600 (Wed, 13 Jan 2010) | 11 lines
Fix regression for timed out parked call returning to caller
This issue seems to have been exposed by the fix in 160390 whereby using a
masquerade prevented a crash. The new channel used in the masquerade was
not copying the macro information from the old channel.
(closes issue #15459)
Reported by: djrodman
Patches:
patch_15459.txt uploaded by mnick (license )
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@239840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r239712 | dvossel | 2010-01-13 10:31:14 -0600 (Wed, 13 Jan 2010) | 24 lines
add silence gen to wait apps
asterisk.conf's 'transmit_silence' option existed before
this patch, but was limited to only generating silence
while recording and sending DTMF. Now enabling the
transmit_silence option generates silence during wait
times as well.
To achieve this, ast_safe_sleep has been modified to
generate silence anytime no other generators are present
and transmit_silence is enabled. Wait apps not using
ast_safe_sleep now generate silence when transmit_silence
is enabled as well.
(closes issue #16524)
Reported by: kobaz
(closes issue #16523)
Reported by: kobaz
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/456/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@239713 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r239571 | tilghman | 2010-01-12 13:58:00 -0600 (Tue, 12 Jan 2010) | 5 lines
Blank callerid and NULL callerid should not compare equal.
The second is the default state for matching CID in the dialplan (no matching)
while the first matches one particular CallerID. This is a regression.
(fixes AST-314, SWP-611)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@239575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r238635 | dvossel | 2010-01-08 13:39:30 -0600 (Fri, 08 Jan 2010) | 22 lines
fixes AUDIOHOOK_INHERIT regression
During the process of removing an audiohook from one channel
and attaching it to another the audiohook's status is updated
to DONE and then back to whatever it was previously. Typically
updating the status after setting it to DONE is not a good idea
because DONE can trigger unrecoverable audiohook destruction
events... because of this a conditional check was added to
audiohook_update_status to explicitly prevent the audiohook
from ever changing after being set to DONE. It was this check
that prevented audiohook inherit from work properly though.
Now ast_audiohook_move_by_source is treated as a special exception,
as the audiohook must be returned to its previous status after
attaching it to the new channel. This is only a safe operation
because the audiohook's lock is held the entire time, otherwise
this could cause trouble.
(closes issue #16522)
Reported by: corruptor
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@238637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r238134 | jpeeler | 2010-01-06 13:05:06 -0600 (Wed, 06 Jan 2010) | 10 lines
Fix channel name comparison for bridge application.
The channel name comparison was not comparing the whole string and therefore
if one channel name was a substring of the other, the bridge would fail.
(closes issue #16528)
Reported by: telecos82
Patches:
res_features_r236843.diff uploaded by telecos82 (license 687)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@238137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r237839 | dvossel | 2010-01-05 13:29:47 -0600 (Tue, 05 Jan 2010) | 19 lines
fixes subscriptions being lost after 'module reload'
During a module reload if multiple extension configs are present,
such as both extensions.conf and extensions.ael, watchers for one
config's hints will be lost during the merging of the other config.
This happens because hint watchers are only preserved for the
current config being merged. The old context list is destroyed
after the merging takes place, meaning any watchers that were not
perserved will be removed.
Now all hints are preserved during merging regardless of what config
file is being merged. These hints are only restored if they
are present within the new context list.
(closes issue #16093)
Reported by: jlaroff
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@237840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r237406 | tilghman | 2010-01-04 12:28:28 -0600 (Mon, 04 Jan 2010) | 23 lines
Merged revisions 237405 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r237405 | tilghman | 2010-01-04 12:19:00 -0600 (Mon, 04 Jan 2010) | 16 lines
Add a flag to disable the Background behavior, for AGI users.
This is in a section of code that relates to two other issues, namely
issue #14011 and issue #14940), one of which was the behavior of
Background when called with a context argument that matched the current
context. This fix broke FreePBX, however, in a post-Dial situation.
Needless to say, this is an extremely difficult collision of several
different issues. While the use of an exception flag is ugly, fixing all
of the issues linked is rather difficult (although if someone would like
to propose a better solution, we're happy to entertain that suggestion).
(closes issue #16434)
Reported by: rickead2000
Patches:
20091217__issue16434.diff.txt uploaded by tilghman (license 14)
20091222__issue16434__1.6.1.diff.txt uploaded by tilghman (license 14)
Tested by: rickead2000
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@237409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r235660 | jpeeler | 2009-12-18 16:51:37 -0600 (Fri, 18 Dec 2009) | 55 lines
Merged revisions 235635 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r235635 | jpeeler | 2009-12-18 16:29:51 -0600 (Fri, 18 Dec 2009) | 48 lines
Correct CDR dispositions for BUSY/FAILED
This patch is simple in that it reorders the disposition defines so that the fix
for issue 12946 works properly (the default CDR disposition was changed to
AST_CDR_NOANSWER). Also, the AST_CDR_FLAG_ORIGINATED flag was set in ast_call to
ensure all CDR records are written.
The side effects of CDR changes are scary, so I'm documenting the test cases
performed to attempt to catch any regressions. The following tests were all
performed using 1.4 rev 195881 vs head (235571) + patch:
A calls B
C calls B (busy)
Hangup C
Hangup A
(Both SIP and features)
A calls B
A blind transfers to C
Hangup C
(Both SIP and features)
A calls B
A attended transfers to C
Hangup C
A calls B
A attended transfers to C (SIP)
C blind transfers to A (features)
Hangup A
All of the test scenario CDRs matched.
The following tests were performed just with the patch to ensure proper operation
(with unanswered=yes):
exten =>s,1,Answer
exten =>s,n,ResetCDR(w)
exten =>s,n,ResetCDR(w)
exten =>s,1,ResetCDR(w)
exten =>s,n,ResetCDR(w)
(closes issue #16180)
Reported by: aatef
Patches:
bug16180.patch uploaded by jpeeler (license 325)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@235665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r235422 | tilghman | 2009-12-17 11:19:08 -0600 (Thu, 17 Dec 2009) | 15 lines
Merged revisions 235421 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r235421 | tilghman | 2009-12-17 11:17:51 -0600 (Thu, 17 Dec 2009) | 8 lines
Use context from which Macro is executed, not macro context, if applicable.
Also, ensure that the extension COULD match, not just that it won't match more.
(closes issue #16113)
Reported by: OrNix
Patches:
20091216__issue16113.diff.txt uploaded by tilghman (license 14)
Tested by: OrNix
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@235425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r233100 | russell | 2009-12-04 11:18:22 -0600 (Fri, 04 Dec 2009) | 14 lines
Merged revisions 233092 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r233092 | russell | 2009-12-04 11:12:47 -0600 (Fri, 04 Dec 2009) | 7 lines
Only do frame payload check for HOLD frames.
This code was added for helping to debug the source of invalid HOLD frames.
However, a side effect of this is that it will incorrectly report errors for
frames that have an integer payload. Make the check for this block specific
to the HOLD frame case.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@233130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r233046 | mnick | 2009-12-04 09:38:33 -0600 (Fri, 04 Dec 2009) | 17 lines
Merged revisions 233014 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r233014 | mnick | 2009-12-04 09:17:03 -0600 (Fri, 04 Dec 2009) | 11 lines
Warning message gets displayed only once
Added additional field 'int display_inband_dtmf_warning', which when set to '1' displays the warning ('Inband DTMF is not supported on codec %s. Use RFC2833'), and when set to '0' doesn't display the warning. Otherwise you would get hundreds of warnings every second.
(closes issue #15769)
Reported by: falves11
Patches:
patch_15769_14.txt uploaded by mnick (license 874)
Tested by: mnick, falves11
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@233049 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r231927 | jpeeler | 2009-12-01 15:54:21 -0600 (Tue, 01 Dec 2009) | 19 lines
Merged revisions 231911 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r231911 | jpeeler | 2009-12-01 15:29:31 -0600 (Tue, 01 Dec 2009) | 12 lines
Fix crash with invalid frame data
The crash was happening as a result of a frame containing an invalid data
pointer, but was set with data length of zero. The few times the issue was
reproduced it _seemed_ that the frame was queued properly, that is the data
pointer was set to NULL. I never could reproduce the crash so as a last resort
the crash has been fixed, but a check in __ast_read has been added to give as
much information about the source of problematic frames in the future.
(closes issue #16058)
Reported by: atis
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@231930 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r231692 | kpfleming | 2009-11-30 15:47:42 -0600 (Mon, 30 Nov 2009) | 22 lines
Another round of UDPTL stack fixes/improvements:
1) Allow users of UDPTL stack to associate a character-string tag with a UDPTL
session, so that log/error/debug messages generated by the UDPTL stack can
be 'connected' to the endpoint that caused them to be generated.
2) Improve comments (and process) of calculating the far end's maximum IFP size
when redundancy mode is in use for error correction.
3) When an IFP larger than the calculated 'far max IFP' size is presented for
writing, truncate it rather than putting in the buffer and allowing the buffer
to overflow; this will cause the ends to retrain to a lower bit rate that
produces IFPs of an appropriate size if possible, and if not possible, the
FAX transfer will fail completely. In these cases, it is due to the one endpoint
supplying a T38FaxMaxDatagram value that is improperly calculated and is
too low to be of use; we have configuration options available to override
this behavior.
4) Eliminate use of T38FaxMaxDatagram value in udptl.conf; it is no longer
needed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@231696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r231095 | jpeeler | 2009-11-24 12:50:36 -0600 (Tue, 24 Nov 2009) | 11 lines
Fix erroneous hangup extension execution
ast_spawn_extension behaves differently from 1.4 in that hangups and extensions
that do not exist do not return an error, whereas in 1.6 it does. This is now
taken into account so that the AST_FLAG_BRIDGE_HANGUP_RUN flag gets set
properly.
(closes issue #16106)
Reported by: ajohnson
Tested by: ajohnson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@231098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r230628 | mnicholson | 2009-11-20 15:01:10 -0600 (Fri, 20 Nov 2009) | 15 lines
Merged revisions 230627 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r230627 | mnicholson | 2009-11-20 14:53:06 -0600 (Fri, 20 Nov 2009) | 8 lines
Copy the peer CDR's userfield to the bridge CDR if it exists. This is necessary for the recordagentcalls option in chan_agent to store the recorded file name in the bridge CDR.
(closes issue #14590)
Reported by: msetim
Patches:
queue_agent_userfield.patch uploaded by Laureano (license 265)
Tested by: Laureano, mnicholson
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@230629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r229361 | tilghman | 2009-11-10 16:14:22 -0600 (Tue, 10 Nov 2009) | 19 lines
Merged revisions 229360 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r229360 | tilghman | 2009-11-10 16:09:16 -0600 (Tue, 10 Nov 2009) | 12 lines
If two pattern classes start with the same digit and have the same number of characters, they will compare equal.
The example given in the issue report is that of [234] and [246], which have
these characteristics, yet they are clearly not equivalent. The code still
uses these two characteristics, yet when the two scores compare equal, an
additional check will be done to compare all characters within the class to
verify equality.
(closes issue #15421)
Reported by: jsmith
Patches:
20091109__issue15421__2.diff.txt uploaded by tilghman (license 14)
Tested by: jsmith, thedavidfactor
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@229366 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r228693 | dvossel | 2009-11-06 16:35:44 -0600 (Fri, 06 Nov 2009) | 16 lines
Merged revisions 228692 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r228692 | dvossel | 2009-11-06 16:33:27 -0600 (Fri, 06 Nov 2009) | 9 lines
fixes audiohook write crash occuring in chan_spy whisper mode.
After writing to the audiohook list in ast_write(), frames
were being freed incorrectly. Under certain conditions this
resulted in a double free crash.
(closes issue #16133)
Reported by: wetwired
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@228694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r226159 | tilghman | 2009-10-27 15:22:07 -0500 (Tue, 27 Oct 2009) | 14 lines
Merged revisions 226138 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r226138 | tilghman | 2009-10-27 15:16:49 -0500 (Tue, 27 Oct 2009) | 7 lines
Manager output is not always NULL-terminated, so force a NULL at the end of the filestream.
(closes issue #15495)
Reported by: pdf
Patches:
20090916__issue15495.diff.txt uploaded by tilghman (license 14)
Tested by: pdf
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@226170 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r225445 | dvossel | 2009-10-22 14:55:51 -0500 (Thu, 22 Oct 2009) | 50 lines
SIP TCP/TLS: move client connection setup/write into tcp helper thread, various related locking/memory fixes.
What this patch fixes
1.Moves sip TCP/TLS connection setup into the TCP helper thread:
Connection setup takes awhile and before this it was being
done while holding the monitor lock.
2.Moves TCP/TLS writing to the TCP helper thread: Through the
use of a packet queue and an alert pipe, the TCP helper thread
can now be woken up to write data as well as read data.
3.Locking error: sip_xmit returned an XMIT_ERROR without giving
up the tcptls_session lock. This lock has been completely removed
from sip_xmit and placed in the new sip_tcptls_write() function.
4.Memory leak: When creating a tcptls_client the tls_cfg was alloced
but never freed unless the tcptls_session failed to start. Now the
session_args for a sip client are an ao2 object which frees the
tls_cfg on destruction.
5.Pointer to stack variable: During sip_prepare_socket the creation
of a client's ast_tcptls_session_args was done on the stack and
stored as a pointer in the newly created tcptls_session. Depending
on the events that followed, there was a slight possibility that
pointer could have been accessed after the stack returned. Given
the new changes, it is always accessed after the stack returns
which is why I found it.
Notable code changes
1.I broke tcptls.c's ast_tcptls_client_start() function into two
functions. One for creating and allocating the new tcptls_session,
and a separate one for starting and handling the new connection.
This allowed me to create the tcptls_session, launch the helper
thread, and then establish the connection within the helper thread.
2.Writes to a tcptls_session are now done within the helper thread.
This is done by using an alert pipe to wake up the thread if new
data needs to be sent. The thread's sip_threadinfo object contains
the alert pipe as well as the packet queue.
3.Since the threadinfo object contains the alert pipe, it must now be
accessed outside of the helper thread for every write (queuing of a
packet). For easy lookup, I moved the threadinfo objects from a
linked list to an ao2_container.
(closes issue #13136)
Reported by: pabelanger
Tested by: dvossel, whys
(closes issue #15894)
Reported by: dvossel
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/380/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@225489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r224856 | tilghman | 2009-10-20 17:09:07 -0500 (Tue, 20 Oct 2009) | 12 lines
Merged revisions 224855 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224855 | tilghman | 2009-10-20 17:07:11 -0500 (Tue, 20 Oct 2009) | 5 lines
Pay attention to the return value of the manipulate function.
While this looks like an optimization, it prevents a crash from occurring
when used with certain audiohook callbacks (diagnosed with SVN trunk,
backported to 1.4 to keep the source consistent across versions).
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@224859 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r224671 | kpfleming | 2009-10-19 18:47:39 -0500 (Mon, 19 Oct 2009) | 14 lines
Merged revisions 224670 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224670 | kpfleming | 2009-10-19 18:44:07 -0500 (Mon, 19 Oct 2009) | 7 lines
Correct timestamp calculations when RTP sample rates over 8kHz are used.
While testing some endpoints that support 16kHz and 32kHz sample rates, some
log messages were generated due to calc_rxstamp() computing timestamps in a way
that produced odd results, so this patch sanitizes the result of the
computations.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@224674 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r223487 | russell | 2009-10-11 12:25:42 -0500 (Sun, 11 Oct 2009) | 17 lines
Merged revisions 223485-223486 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r223485 | russell | 2009-10-11 12:22:52 -0500 (Sun, 11 Oct 2009) | 6 lines
Don't use data outside of its scope.
The purpose of this code was to have a hangup frame put on the list of deferred
frames. However, the code that read the hangup frame was outside of the scope
of where the hangup frame was declared.
........
r223486 | russell | 2009-10-11 12:25:06 -0500 (Sun, 11 Oct 2009) | 2 lines
Remove some unnecessary code.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@223490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r222880 | russell | 2009-10-08 14:52:03 -0500 (Thu, 08 Oct 2009) | 51 lines
Merged revisions 222878 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222878 | russell | 2009-10-08 14:45:47 -0500 (Thu, 08 Oct 2009) | 44 lines
Make filestream frame handling safer by isolating frames before returning them.
This patch is related to a number of issues on the bug tracker that show
crashes related to freeing frames that came from a filestream. A number of
fixes have been made over time while trying to figure out these problems, but
there re still people seeing the crash. (Note that some of these bug reports
include information about other problems. I am specifically addressing
the filestream frame crash here.)
I'm still not clear on what the exact problem is. However, what is _very_
clear is that we have seen quite a few problems over time related to unexpected
behavior when we try to use embedded frames as an optimization. In some cases,
this optimization doesn't really provide much due to improvements made in other
areas.
In this case, the patch modifies filestream handling such that the embedded frame
will not be returned. ast_frisolate() is used to ensure that we end up with a
completely mallocd frame. In reality, though, we will not actually have to malloc
every time. For filestreams, the frame will almost always be allocated and freed
in the same thread. That means that the thread local frame cache will be used.
So, going this route doesn't hurt.
With this patch in place, some people have reported success in not seeing the
crash anymore.
(SWP-150)
(AST-208)
(ABE-1834)
(issue #15609)
Reported by: aragon
Patches:
filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
Tested by: aragon, russell
(closes issue #15817)
Reported by: zerohalo
Tested by: zerohalo
(closes issue #15845)
Reported by: marhbere
Review: https://reviewboard.asterisk.org/r/386/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r222176 | kpfleming | 2009-10-05 20:24:24 -0500 (Mon, 05 Oct 2009) | 27 lines
Recorded merge of revisions 222152 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222152 | kpfleming | 2009-10-05 20:16:36 -0500 (Mon, 05 Oct 2009) | 20 lines
Fix ao2_iterator API to hold references to containers being iterated.
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r222110 | kpfleming | 2009-10-05 14:45:00 -0500 (Mon, 05 Oct 2009) | 25 lines
Allow non-compliant T.38 endpoints to be supportable via configuration option.
Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept
as the T38FaxMaxDatagram value in their SDP, when in fact this value is
supposed to be the maximum UDPTL payload size (datagram size) they can accept.
If the value they supply is small enough (a commonly supplied value is '72'),
T.38 UDPTL transmissions will likely fail completely because the UDPTL packets
will not have enough room for a primary IFP frame and the redundancy used for
error correction. If this occurs, the Asterisk UDPTL stack will emit log messages
warning that data loss may occur, and that the value may need to be overridden.
This patch extends the 't38pt_udptl' configuration option in sip.conf to allow
the administrator to override the value supplied by the remote endpoint and
supply a value that allows T.38 FAX transmissions to be successful with that
endpoint. In addition, in any SIP call where the override takes effect, a debug
message will be printed to that effect. This patch also removes the
T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not
actually had any effect for a number of releases.
In addition, this patch cleans up the T.38 documentation in sip.conf.sample
(which incorrectly documented that T.38 support was passthrough only).
(issue #15586)
Reported by: globalnetinc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r221592 | kpfleming | 2009-10-01 11:16:09 -0500 (Thu, 01 Oct 2009) | 12 lines
Remove ability to control T.38 FAX error correction from udptl.conf.
chan_sip has had the ability to control T.38 FAX error correction mode on a per-peer
(or global) basis for a couple of releases now, which is where it should have been
all along. This patch removes the ability to configure it in udptl.conf, but issues
a warning if the user tries to do, telling them to look at sip.conf.sample for how
to configure it now. For any SIP peers that are T.38 enabled in sip.conf, there is
already a default for FEC error correction even if the user does not specify any mode,
so this change will not turn off error correction by default, it will have the same
default value that has been in the udptl.conf sample file.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r221266 | twilson | 2009-09-30 12:52:30 -0500 (Wed, 30 Sep 2009) | 32 lines
Merged revisions 221086 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221086 | twilson | 2009-09-30 09:49:11 -0500 (Wed, 30 Sep 2009) | 25 lines
Change the SSRC by default when our media stream changes
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r219139 | mnicholson | 2009-09-17 10:18:01 -0500 (Thu, 17 Sep 2009) | 17 lines
Merged revisions 219136 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines
Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.
This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h.
(closes issue #15316)
Reported by: vmarrone
Tested by: mnicholson
Review: https://reviewboard.asterisk.org/r/362/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@219194 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r218868 | dbrooks | 2009-09-16 13:06:42 -0500 (Wed, 16 Sep 2009) | 20 lines
Merged revisions 218867 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r218867 | dbrooks | 2009-09-16 13:00:45 -0500 (Wed, 16 Sep 2009) | 13 lines
Fixes CID pattern matching behavior to mirror that of extension pattern matching.
Pattern matching for extensions uses a type of scoring system, giving values for
specificity to each character in the pattern. Unfortunately, this is done character
by character, in order. This does lead to some less specific patterns being first
in line for matching, but it will usually get the job done.
This patch merely brings CID matching to the same level as extension matching.
This patch does not attempt to tackle the problem shared by extension matching.
(closes issue #14708)
Reported by: klaus3000
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@218938 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r216438 | oej | 2009-09-04 16:02:34 +0200 (Fre, 04 Sep 2009) | 35 lines
Merged revisions 216430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines
Make apps send PROGRESS control frame for early media and fix too early media issue in SIP
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@216647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r215567 | tilghman | 2009-09-02 13:37:25 -0500 (Wed, 02 Sep 2009) | 9 lines
Close up to the soft open file limit (same on Linux, but varies drastically on OS X).
Also, a Makefile fix for Darwin (OS X).
(closes issue #14542)
Reported by: jtodd
Patches:
20090901__issue14542.diff.txt uploaded by tilghman (license 14)
Tested by: jtodd, tilghman
Change-type: bugfix
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@215570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tilghman Lesher
Russell Bryant
Paul Belanger
Mark Michelson
Terry Wilson
David Vossel
Richard Mudgett
Matthew Nicholson
Leif Madsen
Jason Parker
Jeff Peeler
Alec L Davis
Sean Bright
Olle Johansson
Matthias Nick
Kevin P. Fleming
David Brooks
Joshua Colp
Michiel van Baak