........
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
........
Blocked revisions 399305
........
Fix Segfault When Syntax Of A Line Under [applicationmap] Is Invalid
When processing the lines under the [applicationmap] context in features.conf, a
segfault occurs from attempting to process a line with an invalid syntax
(basically missing most of the arguments).
Example:
[applicationmap]
automon=*6
* This patch moves the checking for empty arguments to before they are accessed.
* Also, checked the "todo" comment and removed it. Some applications do not
require arguments.
(closes issue ASTERISK-22416)
Reported by: CGI.NET
Tested by: CGI.NET
Patches:
asterisk-22416-check-syntax-first_v2.diff by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2803
........
Merged revisions 399304 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400185 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RTCP's calculation of the number of lost packets in an RTP stream is based on
that stream's sequence number count, the number of received packets, and how
many packets we expect to receive. When the SSRC for an RTP stream changes,
there can - and almost always will be - a large jump in the next packet's
timestamp and sequence number. If we don't reset the number of received
packets, sequence number count, and other metrics used by RTCP, the next RR/SR
report will use the previous SSRC's values to calculate the lost packet count
for the new SSRC - resulting in a very large number of lost packets.
This patch modifies res_rtp_asterisk such that, if it detects a SSRC change, it
will reset the various values used by the RTCP calculations. From the
perspective of RTCP, this appears as a new media stream - which is what it is.
Review: https://reviewboard.asterisk.org/r/2886/
(closes issue AST-1174)
Reported by: Thomas Arimont
........
Merged revisions 400089 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400093 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 400108 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400117 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch covers two problems:
1) Currently, when a call is transferred into a parking lot from a bridge
(using either the blind transfer or one touch parking mechanisms), the
application fails to be set to "Park" in the resulting CDR record for
the parked channel. This is due to the ParkedCall message arriving before
the BridgeEnter for the channel entering the parking bridge. The ParkedCall
message isn't handled as the CDR for the channel has already been finalized
(due to the channel having left its two party bridge), and the BridgeEnter -
which creates the new CDR - doesn't have the parking information. This patch
modifies the behavior so that reception of a ParkedCall message will - if
not handled by a CDR chain - cause a new CDR to be created and put into the
Parking state.
2) It fixes a FRACK that occurred when a channel is originated into a parking
space. The DialedPending state - which occurs for both Dialed and Originated
channels - assumed that it couldn't handle the parking transitions due to it
having a Party B; however, Originated channels don't have a Party B. As such,
the existing CDR needs to transition into the parking state - this patch does
that.
Review: https://reviewboard.asterisk.org/r/2877/
(closes issue ASTERISK-22482)
Reported by: Richard Mudgett
........
Merged revisions 400062 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_queue currently attempts to handle Local channel optimizations in an effort
to provide accurate information in Stasis messages (and their corresponding
AMI events) as well as the Queue log. Sometimes, however, things don't go as
planned.
Consider the following scenario:
SIP/foo <-> L;1 <-> L;2 <-> SIP/agent
SIP/agent answers, triggering a Local channel optimization. app_queue will
normally do the following:
* Listen for the Local optimization events and update our agent accordingly
to SIP/agent in the queue log and messages
* When we get a hangup, publish the AgentComplete event based on our
information (SIP/foo and SIP/agent)
However, as with all things that depend on sanity from something as capricious
as Local channels, things can go wrong:
(1) SIP/agent immediately hangs up upon answering. This triggers a race
condition between termination messages coming from SIP/agent and the
ongoing Local channel optimization messages. (Note that this can also
occur with SIP/foo)
(2) In a race condition, Asterisk can (rarely) deliver the hangup messages
prior to the Local channel optimization.
In that case, the messages *may* arrive to app_queue in the following order:
* Hangup SIP/Agent
* Hangup SIP/foo
* Optimize L;1/L;2
* Hangup L;2
* Hangup L;1
When app_queue receives the hangup of the agent or the caller, it will attempt
to publish the AgentComplete event. However, it now has a problem - it thinks
its agent is the ;1 side of the Local channel, as it never received the
optimization event. At the same time, that channel is already gone. This
results in getting NULL from the Stasis cache. What's more, we can't really
wait for the optimization message, as we are currently handling the hangup
of the channel that the optimization event would tell us to use.
This patch modifies the behavior in app_queue such that, since we still have a
lot of pertinent queue information (interface, queue name, etc.), we now raise
the event with what information we know. The channels involved now may or may
not be present. Users will still at least get the "AgentComplete" event, which
"completes" the known Agent information.
Review: https://reviewboard.asterisk.org/r/2878/
(closes issue ASTERISK-22507)
Reported by: Richard Mudgett
........
Merged revisions 400060 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400061 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r399887, a minor performance improvement was introduced by not allocating
the manager variable struct if it wasn't used. Unfortunately, when directly
accessing an ast_channel struct, manager assumed that the struct was always
allocated. Since this was no longer the case, things got a bit crashy.
This fixes that problem by simply bypassing appending variables if the manager
channel variable struct isn't there.
........
Merged revisions 400058 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a collision of mod_data use on the transaction between using a nat
hook and an session response callback. During state change it was assumed
what was in the mod_data was nothing or the response callback. However, it
was possible for it to also contain a nat hook thus resulting in a bad cast
and a crash.
Added the ability to store multiple data elements in mod_data via a hash table.
In this instance, mod_data now stores a hash table of the two values that can
be retrieved using an associated string key.
(closes issue ASTERISK-22394)
Reported by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/2843/
........
Merged revisions 399990 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk receives a 200 OK in response to an invite, that peer should have
sent an SDP at some point by then. If the channel has never received an SDP,
media won't have been set and the remote address won't be known. Endpoints in
general should not be doing this. This patch makes it so that Asterisk will
simply hang up a call if it sends a 200 OK at this point. So far this odd
behavior for endpoints has only been observed in tests which involved manually
created SIP transactions in SIPp.
(closes issue ASTERISK-22424)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2827/
........
Merged revisions 399939 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 399962 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 399976 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These refleaks were causing bridged calls not to close their RTP ports. Thus
a call would leave open 4 ports (RTP for party A, RTCP for party A, RTP for party
B, and RTCP for party B). This led to an eventual depletion of available RTP
ports.
........
Merged revisions 399924 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399925 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While handling a registration request a race condition could occur if/when two+
clients registered at the same time. This happened when one request obtained a
copy of the current contacts for an AOR and another request did the same before
the first request updated. Thus the second would update and overwrite the first
(or vice-versa depending on which actually updated first). In the case of it
being the same contact two "add" events would be raised.
pjsip registration handling is now serialized to alleviate this issue.
(closes issue AST-1213)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2860/
........
Merged revisions 399897 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399898 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The PRI and SS7 link control threads are not stopped correctly when the
chan_dahdi.so module is unloaded. The link control threads pri_dchannel()
and ss7_linkset() are not awakened from a poll() to cancel the thread.
* Added a SIGURG signal after requesting the thread cancel to break the
link control thread poll() immediately.
For SS7 it was slightly worse, the link poll() timeout would always be
whatever was the last libss7 scheduled event time used. If no libss7
scheduled event was pending, the thread could run more often than
necessary.
* Set nextms to 60 seconds for the ss7_linkset() poll() if there is no
other libss7 scheduled event.
........
Merged revisions 399818 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 399834 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 399842 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1st Issue
When a realtime peer sends an un-REGISTER request, Asterisk
un-registers the peer but the database table record still has regseconds and
fullcontact for the peer. This results in calls attempting to be routed to the
peer which is no longer registered. The expected behavior is to get
busy/congested when attempting to call an un-registered peer through the
dialplan.
What was discovered is that we are clearing out the peer's registration in the
database in parse_register_contact() when calling expire_register() but then
upon returning from parse_register_contact(), update_peer() is run which stores
back in the database table regseconds and fullcontact.
2nd Issue
The reporter pointed out that the 200 ok being returned by Asterisk
after un-registering a peer contains a Contact header with ;expires= and the
Expires header is not set to 0. This is actually a regression.
Tests were created for this second issue (ASTERISK-22548). The tests have been
reviewed and a Ship It! was received on those tests.
This patch does the following:
* Do not ignore the Expires header value even when it is set to 0. The patch
sets the pvt->expiry earlier on in the function so that it is set properly and
used.
* If pvt->expiry is 0, do not call update_peer since that means the peer has
already been un-registered and there is no need to update the database record
again since nothing has changed.
(closes issue ASTERISK-22428)
Reported by: Ben Smithurst
Tested by: Ben Smithurst, Michael L. Young
Patches:
asterisk-22428-rt-peer-update-and-expires-header.diff
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2869/
........
Merged revisions 399794 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 399795 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 399796 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Re-using some of Mark Michelson's text from an E-mail discussion for:
* Modifying synopsis for both options
* Adding description to both options
* Changing name of "external_media_address" for Endpoint configuration to "media_address" in anticipation of the option name being changed. (As it is not really specific to external destinations)
(issue ASTERISK-22405)
(closes issue ASTERISK-22405)
Reported by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/2850/
........
Merged revisions 399781 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399782 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the channel variable MONITOR_EXEC is set, app_queue will pass the specified
execution parameters to the MixMonitor application when a queue is recorded.
If that channel variable is not set, the buffer that holds the escaped value
was not being initialized to NULL, and so would be passed to the MixMonitor
application with garbage. Hilarity ensued as app_mixmonitor attempted to
execute gobeldy-gook.
........
Merged revisions 399681 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is a large performance price currently in the CDR engine. We currently
perform two ao2_callback calls on a container that has an entry for every
channel in the system. This is done to create matching pairs between channels
in a bridge.
As such, the portion of the CDR logic that this patch deals with is how we
make pairings when a channel enters a mixing bridge. In general, when a
channel enters such a bridge, we need to do two things:
(1) Figure out if anyone in the bridge can be this channel's Party B.
(2) Make pairings with every other channel in the bridge that is not already
our Party B.
This is a two step process. In the first step, we look through everyone in the
bridge and see if they can be our Party B (single_state_process_bridge_enter).
If they can - yay! We mark our CDR as having gotten a Party B. If not, we keep
searching. If we don't find one, we wait until someone joins who can be our
Party B.
Step 2 is where we changed the logic
(handle_bridge_pairings and bridge_candidate_process). Previously, we would
first find candidates - those channels in the bridge with us - from the
active_cdrs_by_channel container. Because a channel could be a candidate if it
was Party B to an item in the container, the code implemented multiple
ao2_container callbacks to get all the candidates. We also had to store them
in another container with some other meta information. This was rather complex
and costly, particularly if you have 300 Local channels (600 channels!) going
at once.
Luckily, none of it is needed: when a channel enters a bridge (which is when
we're figuring all this stuff out), the bridge snapshot tells us the unique
IDs of everyone already in the bridge. All we need to do is:
For all channels in the bridge:
If the channel is us or our Party B that we got in step 1, skip it
Compare us and the candidate to figure out who is Party A (based on some
specific rules)
If we are Party A:
Make a new CDR for us, append it to our chain, and set the candidate as
Party B
If they are Party A:
If they don't have a Party B:
Make a new CDR for them, append us to their chain, and us as Party B
Otherwise:
Copy us over as Party B on their existing CDR.
This patch does that.
Because we now use channel unique IDs to find the candidates during bridging,
active_cdrs_by_channel now looks up things using uniqueid instead of channel
name. This makes the more complex code simpler; it does, however, have the
drawback that dialplan applications and functions will be slightly slower as
they have to iterate through the container looking for the CDR by name.
That's a small price to pay however as the bridging code will be called a lot
more often.
This patch also does two other minor changes:
(1) It reduces the container size of the channels in a bridge snapshot to 1.
In order to be predictable for multi-party bridges, the order of the
channels in the container must be stable; that is, it must always devolve
to a linked list.
(2) CDRs and the multi-party test was updated to show the relationship between
two dialed channels. You still want to know if they talked - previously,
dialed channels were always ignored, which is wrong when they have
managed to get a Party B.
(closes issue ASTERISK-22488)
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/2861/
........
Merged revisions 399666 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399667 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During load time in res_pjsip if an error occurred the operation would attempt to rollback all
operations done during load. This is not permitted by PJSIP as it will assert if the operation has
not been done. This fix changes the code so it will only rollback what has been initialized already.
Further changes also prevent res_pjsip and res_pjsip_session from being unloaded. This is due to
limitations within PJSIP itself. The library environment can only be changed to a certain extent
and does not provide the ability, currently, to deinitialize certain required functionality.
(closes issue ASTERISK-22474)
Reported by: Corey Farrell
........
Merged revisions 399624 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Moved rtcp_report RAII_VAR declaration into the loop so it is unref'ed
after every loop. Moved message_blob to loop and switched it to a regular
variable. The regular variable was used since message_blob is used in a
very contained way.
(closes issue ASTERISK-22565)
Reported by: Corey Farrell
Patches:
rtcp_report-leak.patch (license #5909) patch uploaded by Corey Farrell
Tested by: Corey Farrell
........
Merged revisions 399607 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The config framework is supposed to be able to load configs that come from
multiple config files. The principle example is chan_sip's sip.conf and
users.conf. Unfortunately, it only does this correctly on initial load.
This patch causes the module's config to be reloaded entirely if any of
the config files change.
(closes issue ASTERISK-22009)
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/2859/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pjsip's message technology was being registered as 'sip', which was causing it
to not load due it conflicting with chan_sip's registered 'sip' technology for
messaging. It now registers as 'pjsip'. However, due to this change the "to"
field for outgoing pjsip messages need to be prefixed with 'pjsip:' instead of
'sip:'. Incoming messages to res_pjsip_messaging will automatically have their
"to" fields altered in order to accommodate the change. Outgoing messages also
handle changing it back to 'sip' before being sent so the pjsip library will
properly handle it.
(closes issue ASTERISK-22445)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2833/
........
Merged revisions 399339 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399340 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The endpoint option does not apply to communication with external entities. Rather,
the option is applied to all communications with the endpoint. The external_media_address
transport configuration option may override the endpoint option if it turns out that
we are going to be communicating with an external entity.
Two things of note:
1) I have not updated the XML documentation. This is being taken care of by Rusty as part
of his work on issue ASTERISK-22405
2) This commit is likely to cause testsuite failures since there are tests that use the
external_media_address endpoint option, and they will need to be changed over. Well, I'm
planning to get that updated ASAP after this commit.
(closes issue ASTERISK-22528)
reported by Rusty Newton
........
Merged revisions 399283 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The remote console continued to have issues with its output. In this case CLI
command output would either not show up (if verbose level = 0) or would contain
verbose prefixes (if verbose level > 0) once log messages were sent to the
remote console. The fix now now adds verbose prefix data to all new lines
contained in a verbose log string.
(closes issue ASTERISK-22450)
Reported by: David Brillert
(closes issue AST-1193)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/2825/
........
Merged revisions 399267 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 399268 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
