Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.
Review: https://reviewboard.asterisk.org/r/2879
........
Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
This patch optimizes how forwards are dispatched in Stasis.
Originally, forwards were dispatched as subscriptions that are invoked
on the publishing thread. This did not account for the vast number of
forwards we would end up having in the system, and the amount of work it
would take to walk though the forward subscriptions.
This patch modifies Stasis so that rather than walking the tree of
forwards on every dispatch, when forwards and subscriptions are changed,
the subscriber list for every topic in the tree is changed.
This has a couple of benefits. First, this reduces the workload of
dispatching messages. It also reduces contention when dispatching to
different topics that happen to forward to the same aggregation topic
(as happens with all of the channel, bridge and endpoint topics).
Since forwards are no longer subscriptions, the bulk of this patch is
simply changing stasis_subscription objects to stasis_forward objects
(which, admittedly, I should have done in the first place.)
Since this required me to yet again put in a growing array, I finally
abstracted that out into a set of ast_vector macros in
asterisk/vector.h.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When r382230 added an option to not denoise the MeetMe conference (if a user
had a channel whose format's sample rate changed frequently, for example),
the value added was the maximum allowed value for the constants that define
the options for MeetMe in 1.8. Not so in 11 - unfortunately, the option
CONFFLAG_DONT_DENOISE conflicts with CONFFLAG_INTROUESR_VMREC. This patch
fixes that, and also tweaks one of the way in which the constants was
declared for consistency.
Thanks to Tony Mountifield for pointing out the problem and solution.
(closes issue ASTERISK-22269)
Reported by: Tony Mountifield
........
Merged revisions 396944 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents XML documentation duplication by expanding channel and
bridge snapshot tags into channel and bridge snapshot parameter sets
with a given prefix or defaulting to no prefix. This also prevents
documentation from becoming fractured and out of date by keeping all
variations of the documentation in template form such that it only
needs to be updated once and keeps maintenance to a minimum.
Review: https://reviewboard.asterisk.org/r/2708/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In working with res_stasis, I discovered a significant limitation to
the current structure of stasis_caching_topics: you cannot subscribe
to cache updates for a single channel/bridge/endpoint/etc.
To address this, this patch splits the cache away from the
stasis_caching_topic, making it a first class object. The stasis_cache
object is shared amongst individual stasis_caching_topics that are
created per channel/endpoint/etc. These are still forwarded to global
whatever_all_cached topics, so their use from most of the code does
not change.
In making these changes, I noticed that we frequently used a similar
pattern for bridges, endpoints and channels:
single_topic ----------------> all_topic
^
|
single_topic_cached ----+----> all_topic_cached
|
+----> cache
This pattern was extracted as the 'Stasis Caching Pattern', defined in
stasis_caching_pattern.h. This avoids a lot of duplicate code between
the different domain objects.
Since the cache is now disassociated from its upstream caching topics,
this also necessitated a change to how the 'guaranteed' flag worked
for retrieving from a cache. The code for handling the caching
guarantee was extracted into a 'stasis_topic_wait' function, which
works for any stasis_topic.
(closes issue ASTERISK-22002)
Review: https://reviewboard.asterisk.org/r/2672/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since ast_hangup() is effectively a channel destructor, it should be a
void function.
* Make the few silly callers checking the return value no longer do so.
Only the CDR and CEL unit tests checked the return value.
* Make all callers take advantage of the NULL safe change and remove the
NULL check before the call.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SLA code within app_meetme was written before asotbj2 had been
merged into Asterisk. Worse, support for reloads did not exist at first
and was added later as a bolt-on feature. I knew at the time that
reloading was not safe at all while SLA was in use, so the reload would
be queued up to execute when the system was idle. Unfortunately, this
approach was still prone to errors beyond the fact that this was the
only place in Asterisk where configuration was not reloaded
instantly when requested.
This patch converts various SLA objects to be reference counted objects
using astobj2. This allows reloads to be processed while the system is
in use. The code ensures that the objects will not disappear while one
of the other threads is using them. However, they will be immediately
removed from the global trunk and station containers so no new calls
will use them if removed from configuration.
Review: https://reviewboard.asterisk.org/r/2581/
........
Merged revisions 393928 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 393929 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393930 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reload support was originally not included for SLA. It was added later,
but in a fairly non-traditional way. It basically sets a flag
indicating that a reload is pending, and then waits for a time where it
thinks everything SLA related is idle and unused, and *then* executes
the reload. It does this because the reload process is destructive. It
starts by throwing everything away and starting over.
There are a number of problems with this approach. One of them is that
the check to see if anything in use was incomplete. This patch makes it
more complete and thus less likely for a crash to occur during reload
processing. However, this approach still has problems so some much more
significant reworking of this code will need to come in as a next step.
Patch credit and testing by CoreDial, LLC.
........
Merged revisions 387688 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 387689 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sla.lock was already locked in the only place that sla_check_reload() was called.
Remove the redundant locking of sla.lock done in this function. Less recursive
locking is A Good Thing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an SLA trunk is ringing (inbound call on the trunk) Asterisk will
make outbound calls to the stations that have that trunk. If more than
one station answers the call at the same time, all channels other than
the first one to answer are left in a bad state. The channel gets
leaked, is not connected to anything, and there's no way to get rid of
it.
We now properly clean up these losing channels by hanging up on them.
Since they lost the race, as we process their answer, there is no
ringing trunk for them to answer.
........
Merged revisions 383835 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 383836 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383837 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For some channel drivers, specifically those that have a varying rate in the
number of audio samples, the audio quality for a MeetMe conference can be
exceedingly poor. This is due to a unilateral application of the DENOISE
function in func_speex to channels joining the conference.
The denoiser function in the speex library is initialized with the number of
audio samples in each sample that will be provided to it. If the number of
audio samples changes, the denoiser has to be thrown away and re-initialized.
While this could be worked around by removing func_speex, that doesn't help
if you actually use the denoiser with other channels on the system.
This patches does the following:
* Checks for the presence of func_speex as opposed to codec_speex when
determining if the DENOISE function is present (which is where the function
is actually implemented)
* Adds an option to MeetMe 'n' that causes the denoiser to not be applied
to a channel when it joins. This keeps the current behavior the default, but
let's users disable the denoiser if it causes problems on their system.
Review: https://reviewboard.asterisk.org/r/2358
(closes issue AST-1062)
Reported by: Thomas Arimont
........
Merged revisions 382227 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 382230 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382232 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The old prompts for the administrator menu were inadequate. They didn't mention
that the menu had additional options through the 8 key and pressing the 8 key
wouldn't reveal what those options were. This patch fixes all of that while
also organizing code pertaining to each individual menu type which was
previously all stored in one gigantic function along with many of the basic
conference functions.
(closes issue AST-996)
Reported by: John Bigelow
Review: http://reviewboard.digium.internal/r/360/
........
Merged revisions 379885 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379892 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379912 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two bugs:
* If an outbound call is made from a SLA phone using SLAStation, then there is
no ringtone audible to the phone that originates the call. The indication of
the ringing was not being passed to the SLA station; this patch fixes that
by passing through the progress indications.
* If an SLA station hangs up before the called party answers, then the channel
to the called party continues to ring until a timeout occurs. If the called
party manages to answer, Asterisk attempts to connect the called party to
a non-existant MeetMe room. This patch corrects the behavior by abandoning
the call attempt if it detects that the SLA station is no longer in use
while attempting to call the called party.
Review: https://reviewboard.asterisk.org/r/2275/
(closes issue ASTERISK-20462)
Reported by: dkerr
patches:
asterisk-11-bugid20440+20462.patch uploaded by dkerr (license 5558)
asterisk-11-bugid20462.patch uploaded by dkerr (license 5558)
(closes issue ASTERISK-20440)
Reported by: dkerr
patches:
asterisk-11-bugid20440.patch uploaded by dkerr (license 5558)
asterisk-11-bugid20440+20462.patch uploaded by dkerr (license 5558)
........
Merged revisions 379825 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379826 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk maintains an internal cache for devices in the event subsystem. The
device state cache holds the state of each device known to Asterisk, such that
consumers of device state information can query for the last known state for
a particular device, even if it is not part of an active call. The concept of
a device in Asterisk can include entities that do not have a physical
representation. One way that this occurred was when anonymous calls are allowed
in Asterisk. A device was automatically created and stored in the cache for
each anonymous call that occurred; this was possible in the SIP and IAX2
channel drivers and through channel drivers that utilized the
res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
are never removed from the system, allowing anonymous calls to potentially
exhaust a system's resources.
This patch changes the event cache subsystem and device state management to
no longer cache devices that are not associated with a physical entity.
(issue ASTERISK-20175)
Reported by: Russell Bryant, Leif Madsen, Joshua Colp
Tested by: kmoore
patches:
event-cachability-3.diff uploaded by jcolp (license 5000)
........
Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378321 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378322 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r375993 | mmichelson | 2012-11-07 11:01:13 -0600 (Wed, 07 Nov 2012) | 30 lines
Fix misuses of timeouts throughout the code.
Prior to this change, a common method for determining if a timeout
was reached was to call a function such as ast_waitfor_n() and inspect
the out parameter that told how many milliseconds were left, then use
that as the input to ast_waitfor_n() on the next go-around.
The problem with this is that in some cases, submillisecond timeouts
can occur, resulting in the out parameter not decreasing any. When this
happens thousands of times, the result is that the timeout takes much
longer than intended to be reached. As an example, I had a situation where
a 3 second timeout took multiple days to finally end since most wakeups
from ast_waitfor_n() were under a millisecond.
This patch seeks to fix this pattern throughout the code. Now we log the
time when an operation began and find the difference in wall clock time
between now and when the event started. This means that sub-millisecond timeouts
now cannot play havoc when trying to determine if something has timed out.
Part of this fix also includes changing the function ast_waitfor() so that it
is possible for it to return less than zero when a negative timeout is given
to it. This makes it actually possible to detect errors in ast_waitfor() when
there is no timeout.
(closes issue ASTERISK-20414)
reported by David M. Lee
Review: https://reviewboard.asterisk.org/r/2135/
........
r375994 | mmichelson | 2012-11-07 11:08:44 -0600 (Wed, 07 Nov 2012) | 3 lines
Remove some debugging that accidentally made it in the last commit.
........
Merged revisions 375993-375994 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375995 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 376014 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376015 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update and extend the configuration_file group and enable linking to the application. Update title that was left behind many years ago.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Doxygen updates including mistakes, misspellings, missing parameters, updates for Doxygen style. Some missing txt file links are removed but their content or essense will be included in some later updates. A majority of the txt files were removed in the 1.6 era but never noted. The HR and EXTREF are simple changes that make the documentation more compatable with more versions of Doxygen.
Further updates coming.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the 'e' or 'E' option to MeetMe the configured conference bridges are loaded and examined to see
if any are empty. If no conference bridges are empty the caller is prompted to enter the number of one.
This operation left around a pointer to the last created conference bridge still containing participants.
When the caller that was not able to find any empty conference bridge hung up this pointer was disposed of
and the reference count of the conference bridge decremented. If there was only a single participant in the
conference bridge it was ultimately destroyed prematurely.
(closes issue AST-994)
Reported by: John Bigelow
........
Merged revisions 373242 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373245 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373246 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the core changes necessary to support AMI event documentation
in the source files of Asterisk, and adds documentation to those AMI events
defined in the core application modules. Event documentation is built from
the source by two new python scripts, located in build_tools:
get_documentation.py and post_process_documentation.py.
The get_documentation.py script mirrors the actions of the existing AWK
get_documentation scripts, except that it will scan the entirety of a source
file for Asterisk documentation. Upon encountering it, if the documentation
happens to be an AMI event, it will attempt to extract information about the
event directly from the manager event macro calls that raise the event. The
post_process_documentation.py script combines manager event instances that
are the same event but documented in multiple source files. It generates
the final core-[lang].xml file.
As this process can take longer to complete than a typical 'make all', it
is only performed if a new make target, 'full', is chosen.
Review: https://reviewboard.asterisk.org/r/1967/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369346 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix only issue pointed out by deprecated_REVERSE_INULL.txt for
app_meetme.c in find_user().
* Change use of %i to %d in sscanf() in find_user(). The use of %i gives
unexpected parsing because it can accept hex, octal, and decimal integer
formats.
* Changed other uses of %i in app_meetme() to use %d for consistency.
(issue ASTERISK-19648)
Reported by: Matt Jordan
........
Merged revisions 367906 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367907 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367908 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A memory leak/reference counting leak occurs if the MeetMeAdmin 'e' command
(eject last user that joined) is used in conjunction with a specified user.
Regardless of the command being executed, if a user is specified for the
command, MeetMeAdmin will look up that user. Because the 'e' option kicks
the last user that joined, as opposed to the one specified, the reference to
the user specified by the command would be leaked when the user variable
was assigned to the last user that joined.
........
Merged revisions 361558 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361560 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361561 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Continue channel opaque-ification by wrapping all of the stringfields.
Eventually, we will restrict what can actually set these variables, but
the purpose for now is to hide the implementation and keep people from
adding code that directly accesses the channel structure. Semantic
changes will follow afterward.
Review: https://reviewboard.asterisk.org/r/1661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are many benefits to making the ast_channel an opaque handle, from
increasing maintainability to presenting ways to kill masquerades. This patch
kicks things off by taking things a field at a time, renaming the field to
'__do_not_use_${fieldname}' and then writing setters/getters and converting the
existing code to using them. When all fields are done, we can move ast_channel
to a C file from channel.h and lop off the '__do_not_use_'.
This patch sets up main/channel_interal_api.c to be the only file that actually
accesses the ast_channel's fields directly. The intent would be for any API
functions in channel.c to use the accessor functions. No more monkeying around
with channel internals. We should use our own APIs.
The interesting changes in this patch are the addition of
channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to
channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to
use accessor functions when ast_channel is really opaque), and some re-working
of the way channel iterators/callbacks are handled so as to avoid creating fake
ast_channels on the stack to pass in matching data by directly accessing fields
(since "name" is a stringfield and the fake channel doesn't init the
stringfields, you can't use the ast_channel_name_set() function). I went with
ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a
setter.
The majority of the grunt-work for this change was done by writing a semantic
patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
Review: https://reviewboard.asterisk.org/r/1655/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Meetme would attempt to substitute the realtime values of RECORDING_FILE and
RECORDING_FORMAT from the meetme db entry instead of using the channel variable set
for those variables in spite of those database entries being NULL or even lacking
a column to represent them.
(closes issue ASTERISK-18873)
Reported by: Byron Clark
Patches:
ASTERISK-18873-1.patch uploaded by Byron Clark (license 6157)
........
Merged revisions 347369 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 347383 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@347395 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
David M. Lee
Kinsey Moore
Matthew Jordan
Richard Mudgett
Russell Bryant
Jonathan Rose
Andrew Latham
Joshua Colp
Terry Wilson