Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is highly unlikely, but - at least in Asterisk 12 - theoretically possible
to load Asterisk with no dialplan whatsoever. If that occurs, and some other
module (that is not a pbx module) attempts to merge its contexts into the
dialplan, the existing merge routine will crash. This is because it is not
insane, and rightly believes that you provided some sort of dialplan,
somewhere.
This patch will gracefully merge the contexts in such a case. Note that this
is highly unlikely to occur in 1.8/11, as features will most likely provide
some dialplan via parking. However, in Asterisk 12, parking is now provided
by res_parking, and hence may create its dialplan later.
(closes issue ASTERISK-23297)
Reported by: CJ Oster
Review: https://reviewboard.asterisk.org/r/3222
........
Merged revisions 408200 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 408201 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 408220 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a number of small-ish problems that were noticed when
witnessing the records that the FreePBX dialplan produces:
(1) Mid-call events (as well as privacy options) have the ability to change the
overall state of the Dial operation after the called party answers. This
means that publishing the DialEnd event when the called party is premature;
we have to wait for the execution of these subroutines to complete before
we can signal the overall status of the DialEnd. This patch moves that
publication and adds handlers for the mid-call events.
(2) The AST_FLAG_OUTGOING channel flag is cleared if an after bridge goto
datastore is detected. This flag was preventing CDRs from being recorded
for all outbound channels that had a 'continue' option enabled on them by
the Dial application.
(3) The CDR engine now locks the 'Dial' application as being the CDR
application if it detects that the current CDR has entered that app. This
is similar to the logic that is done for Parking. In general, if we entered
into Dial, then we want that CDR to record the application as such - this
prevents pre-dial handlers, mid-call handlers, and other shenaniganry
from changing the application value.
(4) The CDR engine now checks for the AST_SOFTHANGUP_HANGUP_EXEC in more places
to determine if the channel is in hangup logic or dead. In either case, we
don't want to record changes in the channel.
(5) The default option for "endbeforehexten" has been changed to "yes". In
general, you don't want to see CDRs in the 'h' exten or in hangup logic.
Since the semantics of that option changed in 12, it made sense to update
the default value as well.
(6) Finally, because we now have the ability to synchronize on the messages
published to the CDR topic, on shutdown the CDR engine will now synchronize
to the messages currently in flight. This helps to ensure that all
in-flight CDRs are written before shutting down.
(closes issue ASTERISK-23164)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3154
........
Merged revisions 407084 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407085 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The per console verbose level feature as previously implemented caused a
large performance penalty. The fix required some minor incompatibilities
if the new rasterisk is used to connect to an earlier version. If the new
rasterisk connects to an older Asterisk version then the root console
verbose level is always affected by the "core set verbose" command of the
remote console even though it may appear to only affect the current
console. If an older version of rasterisk connects to the new version
then the "core set verbose" command will have no effect.
* Fixed the verbose performance by not generating a verbose message if
nothing is going to use it and then filtered any generated verbose
messages before actually sending them to the remote consoles.
* Split the "core set debug" and "core set verbose" CLI commands to remove
the per module verbose support that cannot work with the per console
verbose level.
* Added a silent option to the "core set verbose" command.
* Fixed "core set debug off" tab completion.
* Made "core show settings" list the current console verbosity in addition
to the root console verbosity.
* Changed the default verbose level of the 'verbose' setting in the
logger.conf [logfiles] section. The default is now to once again follow
the current root console level. As a result, using the AMI Command action
with "core set verbose" could again set the root console verbose level and
affect the verbose level logged.
(closes issue AST-1252)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/3114/
........
Merged revisions 405431 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 405432 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When doing the rework of the CDR engine that pushed all of the logic into cdr.c
and made it respond to changes in channel state over Stasis, we knew that
accessing the CDR engine from the dialplan would be "slightly"
non-deterministic. Dialplan threads would be accessing CDRs while Stasis
threads would be updating the state of said CDRs - whereas in the past,
everything happened on the dialplan threads. Tests have shown that "slightly"
is in reality "very".
This patch synchronizes things by making the dialplan applications/functions
that manipulate CDRs do so over Stasis. ForkCDR, NoCDR, ResetCDR, CDR, and
CDR_PROP now all use Stasis to send their requests over to the CDR engine,
and synchronize on the channel Stasis topic via a subscription so that they
return their values/control to the dialplan at the appropriate time.
While going through this, the following changes were also made:
* DISA, which can reset the CDR when a user successfully authenticates, now
just uses the ResetCDR app to do this. This prevents having to duplicate
the same Stasis synchronization logic in that application.
* Answer no longer disables CDRs. It actually didn't work anyway - calling
DISABLE on the channel's CDR doesn't stop the CDR from getting the Answer
time - it just kills all CDRs on that channel, which isn't what the caller
would intend.
(closes issue ASTERISK-22884)
(closes issue ASTERISK-22886)
Review: https://reviewboard.asterisk.org/r/3057/
........
Merged revisions 404294 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch allows individual dialplan functions to be marked as
'dangerous', to inhibit their execution from external sources.
A 'dangerous' function is one which results in a privilege escalation.
For example, if one were to read the channel variable SHELL(rm -rf /)
Bad Things(TM) could happen; even if the external source has only read
permissions.
Execution from external sources may be enabled by setting
'live_dangerously' to 'yes' in the [options] section of asterisk.conf.
Although doing so is not recommended.
Also, the ABI was changed to something more reasonable, since Asterisk
12 does not yet have a public release.
(closes issue ASTERISK-22905)
Review: http://reviewboard.digium.internal/r/432/
........
Merged revisions 403913 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 403917 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 403959 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403960 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
........
Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Similar to how background works, if a say application is called with
this variable set to 'true', 'yes', 'on', etc. then using DTMF while
the say action is in progress will result in the channel jumping to
that extension in the dialplan.
Review: https://reviewboard.asterisk.org/r/3011/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402819 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
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
........
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 originating channels, ast_pbx_outgoing_* caused the dialed channel
reference to be bumped twice. Ostensibly, this routine is bumping the channel
lifetime such that the channel doesn't get nuked in between locks/unlocks;
however, since the routine should return the dialed channel with its
reference bumped, it only needs to do this one time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a new dialplan application, SayAlphaCase, that performs much
the same function as SayAlpha except that it takes additional options
which allow the user to specify whether the case of each letter should
be announced for uppercase, lowercase, or all letters. Similar
functionality has been added to the SAY ALPHA AGI command via an
optional parameter.
Original Patch by: Kevin Scott Adams
Reported by: Kevin Scott Adams
Review: https://reviewboard.asterisk.org/r/2725/
(closes issue ASTERISK-20782)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This removes unused code, event types, IE pltypes, and event IE types
where possible and makes several functions private that were once
public. This includes a renumbering of the remaining event and IE types
which breaks binary compatibility with previous versions. The last
remaining consumers of the old event system (or parts thereof) are
main/security_events.c, res/res_security_log.c, tests/test_cel.c,
tests/test_event.c, main/cel.c, and the CEL backends.
Review: https://reviewboard.asterisk.org/r/2703/
(closes issue ASTERISK-22139)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When asterisk has run out of memory (for whatever reason), the alloc
function logs a message. Logging requires memory. A recipe for
infinite recursion.
Stop the recursion by comparing the function call depth for sane values
before attempting another OOM log message.
Review: https://reviewboard.asterisk.org/r/2743/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the thread servicing the dial request isn't created successfully, the
outgoing dial lock will still be held when the function returns. This patch
unlocks the lock on this off nominal path.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396542 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a dial operation fails, the pbx_outgoing_attempt routine will exit without
first having unlocked the outgoing dial lock. This would be a "bad thing".
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396521 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This makes it so that we can detect failures to originate as with
earlier versions of Asterisk, which restores the Asterisk 11 behavior
for the originate manager action. This was causing the ACL tests for
SIP and IAX2 to fail since those tests expected originate failures
when ACLs would cause rejections. Also, this patch fixes crashes in
chan_sip when ACLs rejected peers during registration verification.
(closes issue ASTERISK-22212)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2753/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new res_ari_asterisk.so module presents several config options
from asterisk main. Unfortunately, they aren't exported, so the module
won't load on Linux.
This patch renames the variables, adding the ast_ prefix so they will
be exported.
Review: https://reviewboard.asterisk.org/r/2737
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It moves the pickup code out of features.c and into pickup.c
* It removes the vast majority of dead code out of features.c. In particular,
this includes the parking code.
(issue ASTERISK-22134)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 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
This adds CEL support for blind and attended transfers and call pickup.
During the course of adding this functionality I noticed that
CONF_ENTER, CONF_EXIT, and BRIDGE_TO_CONF events are particularly
useless without a bridge identifier, so I added that as well.
This adds tests for blind transfers, several types of attended
transfers, and call pickup.
The extra field in CEL records now consists of a JSON blob whose fields
are defined on a per-event basis.
Review: https://reviewboard.asterisk.org/r/2658/
(closes issue ASTERISK-21565)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It adds a new soft hangup flag AST_SOFTHANGUP_HANGUP_EXEC that is set when a
channel is executing dialplan hangup logic, i.e., the 'h' extension or a
hangup handler. Stasis messages now also convey the soft hangup flag so
consumers of the messages can know when a channel is executing said
hangup logic.
* It adds a new channel flag, AST_FLAG_DEAD, which is set when a channel is
well and truly dead. Not just a zombie, but dead, Jim. Manager, CEL, CDRs,
and other consumers of Stasis have been updated to look for this flag to
know when the channel should by lying six feet under.
* The CDR engine has been updated to better handle a channel entering and
leaving a bridge. Previously, a new CDR was automatically created when a
channel left a bridge and put into the 'Pending' state; however, this
way of handling CDRs made it difficult for the 'endbeforehexten' logic to
work correctly - there was always a new CDR waiting in the hangup logic
and, even if 'ended', wouldn't be the CDR people wanted to inspect in the
hangup routine. This patch completely removes the Pending state and instead
defers creation of the new CDR until it gets a new message that requires
a new CDR.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The originate APIs allow callers to provide a pointer to a channel that will
point to the originated channel if the function call succeeds. This is used by AMI
to provide channel information when the originate is performed synchronously.
Unfortunately, if the originate fails in certain ways, the outbound channel is
already disposed of during the dialing itself. This results in the channel being
improperly dereferenced by the internal originate function in pbx.c.
This patch ref bumps the channel to prevent this from occurring. Callers must now
unlock and unref the channel (which is more in line with general channel management
guidelines anyway).
This only affects manager, as it is the only consumer of this API function that
actually passes in a channel pointer.
Review: https://reviewboard.asterisk.org/r/2617/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. Security events
2. Websocket support
3. Diversion header + redirecting support
4. An anonymous endpoint identifier
5. Inbound extension state subscription support
6. PIDF notify generation
7. One touch recording support (special thanks Sean Bright!)
8. Blind and attended transfer support
9. Automatic inbound registration expiration
10. SRTP support
11. Media offer control dialplan function
12. Connected line support
13. SendText() support
14. Qualify support
15. Inband DTMF detection
16. Call and pickup groups
17. Messaging support
Thanks everyone!
Side note: I'm reminded of the song "How Far We've Come" by Matchbox Twenty.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the initial push to update Asterisk's CDR engine for the new
bridging framework. This patch guts the existing CDR engine and builds the new
on top of messages coming across Stasis. As changes in channel state and bridge
state are detected, CDRs are built and dispatched accordingly. This
fundamentally changes CDRs in a few ways.
(1) CDRs are now *very* reflective of the actual state of channels and bridges.
This means CDRs track well with what an actual channel is doing - which
is useful in transfer scenarios (which were previously difficult to pin
down). It does, however, mean that CDRs cannot be 'fooled'. Previous
behavior in Asterisk allowed for CDR applications, channels, and other
properties to be spoofed in parts of the code - this no longer works.
(2) CDRs have defined behavior in multi-party scenarios. This behavior will not
be what everyone wants, but it is a defined behavior and as such, it is
predictable.
(3) The CDR manipulation functions and applications have been overhauled. Major
changes have been made to ResetCDR and ForkCDR in particular. Many of the
options for these two applications no longer made any sense with the new
framework and the (slightly) more immutable nature of CDRs.
There are a plethora of other changes. For a full description of CDR behavior,
see the CDR specification on the Asterisk wiki.
(closes issue ASTERISK-21196)
Review: https://reviewboard.asterisk.org/r/2486/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This uses the channel state change events from Stasis-Core to determine
when channel-related CEL events should be raised. Those refactored in
this patch are:
* AST_CEL_CHANNEL_START
* AST_CEL_ANSWER
* AST_CEL_APP_START
* AST_CEL_APP_END
* AST_CEL_HANGUP
* AST_CEL_CHANNEL_END
Retirement of Linked IDs is also refactored.
CEL configuration has been refactored to use the config framework.
Note: Some HANGUP events are not generated correctly because the bridge
layer does not propagate hangupcause/hangupsource information yet.
Review: https://reviewboard.asterisk.org/r/2544/
(closes issue ASTERISK-21563)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Refactor some channel blob publishing code to use
ast_channel_publish_blob now that it is available and fix a JSON
reference leak that was occurring during varset publishing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390317 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The attended transfer API call can complete the attended transfer in a number of ways
depending on the current bridged states of the channels involved.
The hiding of masquerades is done in some bridging-related functions, such as the manager
Bridge action and the Bridge dialplan application. In addition, call pickup was edited
to "move" a channel rather than masquerade it.
Review: https://reviewboard.asterisk.org/r/2511
(closes issue ASTERISK-21334)
Reported by Matt Jordan
(closes issue Asterisk-21336)
Reported by Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389848 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch moves a number of AMI events over to the Stasis-Core message bus.
This includes:
* ChanSpyStart/Stop
* MonitorStart/Stop
* MusicOnHoldStart/Stop
* FullyBooted/Reload
* All Voicemail/MWI related events
In addition, it adds some Stasis-Core and AMI support for generic AMI messages,
refactors the message router in AMI to use a single router with topic
forwarding for the topics that AMI cares about, and refactors MWI message
types and topics to be more name compliant.
Review: https://reviewboard.asterisk.org/r/2532
(closes issue ASTERISK-21462)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389733 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This may alleviate some of the CDR woes with originated channels, as CDRs
do like to know when a channel was originated. Eventually this will get
converted to be a channel flag, so its location is still good to know
post the great CDR shakeup of 2013.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Scott Griepentrog
Corey Farrell
Matthew Jordan
Richard Mudgett
Kevin Harwell
Joshua Colp
David M. Lee
Mark Michelson
Jonathan Rose
Kinsey Moore
Walter Doekes