Adds the following AMI events, closely following their CLI counterparts:
BridgeDestroy
BridgeKick
BridgeTechnologyList
BridgeTechnologySuspend
BridgeTechnologyUnsuspend
BridgeDestroy kicks an entire bridge, where BridgeKick kicks just one
channel off the bridge. When kicking a channel, specifying the bridge
also (optional) insures it is not removed from the wrong bridge. The
BridgeTechnology events allow viewing and changing suspension status,
which affects only subsequent not active bridging.
(closes ASTERISK-22356)
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/2973/
........
Merged revisions 402387 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For awhile now, we've noticed continuous integration builds hanging on CentOS 6
64-bit build agents. After resolving a number of problems with symbols, strange
locks, and other shenanigans, the problem has persisted. In all cases, gdb
shows the Asterisk process stuck in loader.c on one of the infinite while loops
that calls dlclose repeatedly until success.
The documentation of dlclose states that it returns 0 on success; any other
value on error. It does not state that repeatedly calling it will eventually
clear those errors. Most likely, the repeated calls to dlclose was to force a
close by exhausting the references on the library; however, that will never
succeed if:
(a) There is some fundamental error at work in the loaded library that
precludes unloading it
(b) Some other loaded module is referencing a symbol in the currently loaded
module
This results in Asterisk sitting forever.
Since we have matching pairs of dlopen/dlclose, this patch opts to only call
dlclose once, and log out as an ERROR if dlclose fails to return success. If
nothing else, this might help to determine why on the CentOS 6 64-bit build agent
things are not closing successfully.
Review: https://reviewboard.asterisk.org/r/2970
........
Merged revisions 402287 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402288 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402289 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Based on feedback from ipengineer in #asterisk, when the media indexer
cannot access a sound file on the system (or otherwise fails) Asterisk
displays a "Cannot frob file" error but fails to tell you why. This is
especially problematic as the media_indexer failing will rpevent Asterisk
from starting, as it is in the core.
We now display the errno error messages so folks can figure out what they've
done wrong.
........
Merged revisions 402285 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Debug messages aren't free. Even when the debug level is sufficiently low such
that the messages are never evaluated, there is a cost to having to parse
Asterisk logs that contain debug messages that (a) fail to convey sufficient
information or (b) occur so frequently as to be next to meaningless. Based on
having to stare at lots of DEBUG messages, this patch makes the following
changes:
* channel.c: When copying variables from a parent channel to a child channel,
specify the channels involved. Do not log anything for a variable that is not
inherited; the fact that it doesn't have an _ or __ already signifies that it
won't be inherited.
* pbx.c: Specify what function evaluation has occurred that created the result.
* translate.c: Bump up the translator path messages to 10. I've never once had
to use these debug messages, and for each format that is registered (on
startup) and unregistered (on shutdown) the entire f^2 matrix is logged out.
For short tests in the Asterisk Test Suite, this should make finding the
actual test much easier.
* xmldoc.c: The debug message that 'blah' is not found in the tree is expected.
Often, description elements - which are not required - are not provided.
This debug message adds no additional value, as it is not indicative of an
error or helpful in debugging which element did not contain a 'blah' element
as a child. If an element is supposed to contain a child element, then that
XML tree should have failed validation in the first place.
Review: https://reviewboard.asterisk.org/r/2966/
........
Merged revisions 402150 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402151 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402154 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402155 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Surrogate channels would pop up from time to time in dial message handling.
This would cause a WARNING message to appear, indicating that the Surrogate
channel had no CDR. This patch filters out those channels that have the
internal implementation flag set, such that the WARNING message isn't
displayed.
........
Merged revisions 402090 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In function ast_rtp_instance_early _bridge_make_compatible the
use of instance 0/1 as arguments doesn't clearly communicate a
direction that the copying of payloads from the source channel
to the destination channel will occur, making it more probable
to have the arguments to ast_rtp_codecs_payloads_copy() put in
the reverse order. This patch renames the arguments with _dst
and _src suffixes and corrects the copy direction.
(closes issue ASTERISK-21464)
Reported by: Kevin Stewart
Review: https://reviewboard.asterisk.org/r/2894/
........
Merged revisions 402000 from http://svn.asterisk.org/svn/asterisk/branches/1.8
Test shows rtpmap:119 being copied per this change, but is not in sip invite
........
Merged revisions 402042 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402043 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402054 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also covers ast_app_parse_timelen-fail-zero-length.patch, but the patch was
replaced with one of my own.
(issue ASTERISK-22467)
Reported by: Corey Farrell
Patches:
chan_dahdi-cleanup_push.patch uploaded by coreyfarrell (license 5909)
clicompat-r2.patch uploaded by coreyfarrell (license 5909)
codecs-ilbc-doCPLC.patch uploaded by coreyfarrell (license 5909)
data-cleanup-test-registration.patch uploaded by coreyfarrell (license 5909)
main-asterisk-kill-listener.patch uploaded by coreyfarrell (license 5909)
........
Merged revisions 401704 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 401705 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 401706 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original issue noted that the bridge is orphaned when res_parking.so
is not loaded and a call uses the dial kK flags.
A similar issue happens when only one of the park flags is used. In this
case you have the bridge with one or the other channel left in it. The
channel and bridge will stay around until the channel hangs up.
* Fixed the initial bridge channel push failure to act as if the channel
were kicked out of the bridge. The bridge then decides if it needs to be
dissolved.
(closes issue ASTERISK-22629)
Reported by: Kevin Harwell
Review: https://reviewboard.asterisk.org/r/2928/
........
Merged revisions 401424 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This particular debug message, during a stress test, was logged so
often that it appeared that there may be a memory leak in the logger
code. In actuality, there was no memory leak, but the logger thread
was having a hard time keeping up with the demands of the rest of the
system.
Since this debug message has no value at all, the best way to fix the
problem was to just remove the message.
(closes issue AST-1225)
reported by John Bigelow
Patches:
spammy_log.diff uploaded by Mark Michelson (License #5049)
........
Merged revisions 401364 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A common idiom in Asterisk is to due something like:
for (ao2_obj = list_beginning; ao2_obj = next_item; ao2_ref(ao2_obj, -1)) {
...do stuff...
}
This is nice because it automatically takes care of the object references
for you. However, there is a pitfall here. If a break statement is in the
for loop, then the current reference is not cleaned up. In some cases, this
is on purpose, but in others there is a leak. This commit fixes the leak
cases.
........
Merged revisions 401248 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401249 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most callers of ast_channel_make_compatible() happen before the channels
enter a two party bridge. With the new bridging framework, two party
bridging technologies may also call ast_channel_make_compatible() when
there is more than one thread involved with the two channels.
* Added channel lock protection in set_format() and
ast_channel_make_compatible_helper() when dealing with the channel's
native formats while setting up a translation path.
* Fixed best_src_fmt and best_dst_fmt usage consistency in
ast_channel_make_compatible_helper(). The call to
ast_translator_best_choice() got them backwards.
* Updated some callers of ast_channel_make_compatible() and the function
documentation. There is actually a difference between the two channels
passed in.
* Fixed the deadlock potential in res_fax.c dealing with
ast_channel_make_compatible(). The deadlock potential was already there
anyway because res_fax called ast_channel_make_compatible() with chan
locked.
(closes issue ASTERISK-22542)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2915/
........
Merged revisions 401239 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r378303 the AST_FLAG_DISABLE_DEVSTATE_CACHE flag was added that tells
the devstate system to not cache states for non-real devices. However,
when optimizing away channels (ast_do_masquerade), that flag wasn't
copied.
In my case, using Local devices as queue members created a situation
where the endpoint was considered in use, but the state change of the
device being available again was ignored (not cached). The endpoint
channel was optimized into the (previously) Local channel, but kept
the do-not-cache flag. The end result being that the queue member
apparently stayed in use forever.
(closes issue ASTERISK-22718)
Reported by: Walter Doekes
Review: https://reviewboard.asterisk.org/r/2925/
........
Merged revisions 401178 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 401179 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 401180 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401181 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Consistently compare format2index() return value so matrix_get() cannot
get passed negative values.
* Optimize ast_translator_best_choice() to defer initializing things until
needed. Also cached the matrix_get() return value rather than repeatedly
calling it.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401039 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds an /applications API to ARI, allowing explicit management of
Stasis applications.
* GET /applications - list current applications
* GET /applications/{applicationName} - get details of a specific application
* POST /applications/{applicationName}/subscription - explicitly subscribe to
a channel, bridge or endpoint
* DELETE /applications/{applicationName}/subscription - explicitly unsubscribe
from a channel, bridge or endpoint
Subscriptions work by a reference counting mechanism: if you subscript to an
event source X number of times, you must unsubscribe X number of times to stop
receiveing events for that event source.
Review: https://reviewboard.asterisk.org/r/2862
(issue ASTERISK-22451)
Reported by: Matt Jordan
........
Merged revisions 400522 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch removes said publication for a few reasons:
(1) It is unnecessary. Association of the channel technology with a specific
channel is an implementation detail that should be assumed to "just happen",
and consumers of Stasis don't need to be informed about it.
(2) Publication of said message can now cause crashes, as the actual creation
of a channel in normal locations now stages its messages. As a result, things
that create dummy channels (such as the SIP RTP QOS unit test) and associate
them with a channel technology were now crashing, as the channel itself was
not known by Stasis.
........
Merged revisions 400460 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400461 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r337595, additional security events were added for chan_sip
authentication failures. The new IEs added to the existing invalid
password event were defined as required IEs, but existing users of the
event did not set the new IEs and could not since they didn't apply to
existing uses. They are now marked as optional IEs.
(closes issue ASTERISK-22578)
Reported by: Matt Jordan
........
Merged revisions 400421 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 400440 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400441 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This introduces usage of an additional libxslt cleanup function,
xsltCleanupGlobals, when the configure script detects that it is
available. Early versions of the library did not include this function.
(closes issue ASTERISK-22570)
Reported by: Corey Farrell
Patches:
xsltCleanupGlobals.patch uploaded by Corey Farrell (License 5909)
........
Merged revisions 400384 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
........
r400318 | mmichelson | 2013-10-02 17:08:49 -0500 (Wed, 02 Oct 2013) | 12 lines
Remove unnecessary waits from stasis.
Since caches are updated on publisher threads, there is no need
to wait for the cache updates to occur after a stasis message
is published.
In the case of chan_pjsip device state changes, this set of
changes caused an improvement to performance.
Review: https://reviewboard.asterisk.org/r/2890
........
r400319 | mmichelson | 2013-10-02 17:10:54 -0500 (Wed, 02 Oct 2013) | 3 lines
Remove svn:mergeinfo property.
........
Merged revisions 400318-400319 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previous code was requiring both name and number to be available.
Also restored a comment block on why caller id is also set on an outgoing
call leg in addition to connected line from earlier versions of Asterisk.
........
Merged revisions 400303 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the switch from channel names to channel unique IDs happened, the poor
CLI command got left in the dust. This fixes the command so that users can
once again see how Asterisk is messing up your billing information.
........
Merged revisions 400286 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400287 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* There were several places in ARI where an external library was mallocing
memory that must always be released with free(). When MALLOC_DEBUG is
enabled, free() is redirected to the MALLOC_DEBUG version. Since the
external library call still uses the normal malloc(), MALLOC_DEBUG
complains that the freed memory block is not registered and will not free
it. These cases must use ast_std_free().
* Changed calls to asprintf() and vasprintf() to the equivalent
ast_asprintf() and ast_vasprintf() versions respectively.
........
Merged revisions 400270 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400271 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
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
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 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
Scott Griepentrog
Matthew Jordan
Richard Mudgett
Kevin Harwell
Jonathan Rose
John Bigelow
Mark Michelson
Joshua Colp
Walter Doekes
Michael L. Young
Kinsey Moore
David M. Lee