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
This patch fixes two memory leaks:
* A memory leak in packing channels into a multi-channel blob payload when
publishing dial messages. The multi-channel blob payload does not steal
the references - this approach was chosen because it works well with the
RAII_VAR macro. Unfortunately, this does mean that you actually have to use
the RAII_VAR macro (or manually deref it yourself)
* RTP instances returned as a result of one of the glue operations are ref
counted and have to be de-ref'd appropriately. We now do that, as saying
that we should do it and then not would be silly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a Stasis message type is defined in a loadable module, handling
those messages for AMI and res_stasis events can be cumbersome.
This patch adds a vtable to stasis_message_type, with to_ami and
to_json virtual functions. These allow messages to be handled
abstractly without putting module-specific code in core.
As an example, the VarSet AMI event was refactored to use the to_ami
virtual function.
(closes issue ASTERISK-21817)
Review: https://reviewboard.asterisk.org/r/2579/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391403 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Stasis cache clear message payloads now consist of a stasis_message
representative of the message to be cleared from the cache. This allows
multiple parallel caches to coexist and be cleared properly by the same
cache clear message even when keyed on different fields.
This change fixes a bug where multiple cache clears could be posted for
channels. The cache clear is now produced in the destructor instead of
ast_hangup.
Additionally, dummy channels are no longer capable of producing channel
snapshots.
Review: https://reviewboard.asterisk.org/r/2596
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390830 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
* DTMF attended and blind transfers have hold/unhold behavior restored.
* External attended and blind transfers unhold the transfered party when
the transfer is initiated.
* Made prohibit blind transferring a bridge marked as masquerade only.
(ConfBridge bridges)
* Made running an application or playing a file inside a bridge post the
hold/unhold messages if MOH is requested.
Review: https://reviewboard.asterisk.org/r/2574/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses issues during immediate shutdowns, where modules
are not unloaded, but Asterisk atexit handlers are run.
In the typical case, this usually isn't a big deal. But the
introduction of the Stasis message bus makes it much more likely for
asynchronous activity to be happening off in some thread during
shutdown.
During an immediate shutdown, Asterisk skips unloading modules. But
while it is processing the atexit handlers, there is a window of time
where some of the core message types have been cleaned up, but the
message bus is still running. Specifically, it's still running
module subscriptions that might be using the core message types. If a
message is received by that subscription in that window, it will
attempt to use a message type that has been cleaned up.
To solve this problem, this patch introduces ast_register_cleanup().
This function operates identically to ast_register_atexit(), except
that cleanup calls are not invoked on an immediate shutdown. All of
the core message type and topic cleanup was moved from atexit handlers
to cleanup handlers.
This ensures that core type and topic cleanup only happens if the
modules that used them are first unloaded.
This patch also changes the ast_assert() when accessing a cleaned up
or uninitialized message type to an error log message. Message type
functions are actually NULL safe across the board, so the assert was a
bit heavy handed. Especially for anyone with DO_CRASH enabled.
Review: https://reviewboard.asterisk.org/r/2562/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390122 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When ast_channel_cached_blob_create was merged,
ast_channel_blob_create_from_cache was partially removed in an
unresolved merge conflict. This restores ast_channel_blob_create_from_cache
and refactors usage of ast_channel_cached_blob_create (requires an
ast_channel) to use ast_channel_blob_create_from_cache (requires a
channel uniqueid) instead.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389974 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
and GET /playback/{playbackId}.
This allows an external application to initiate playback of a sound on a
channel while the channel is in the Stasis application.
/play commands are issued asynchronously, and return immediately with
the URL of the associated /playback resource. Playback commands queue up,
playing in succession. The /playback resource shows the state of a
playback operation as enqueued, playing or complete. (Although the
operation will only be in the 'complete' state for a very short time,
since it is almost immediately freed up).
(closes issue ASTERISK-21283)
(closes issue ASTERISK-21586)
Review: https://reviewboard.asterisk.org/r/2531/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389587 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r388005, macros were introduced to consistently define message
types. This added an assert if a message type was used either before
it was initialized or after it had been cleaned up. It turns out that
this assertion fires during shutdown.
This actually exposed a hidden shutdown ordering problem. Since
unsubscribing is asynchronous, it's possible that the message types
used by the subscription could be freed before the final message of
the subscription was processed.
This patch adds stasis_subscription_join(), which blocks until the
last message has been processed by the subscription. Since joining was
most commonly done right after an unsubscribe, a
stasis_unsubscribe_and_join() convenience function was also added.
Similar functions were also added to the stasis_caching_topic and
stasis_message_router, since they wrap subscriptions and have similar
problems.
Other code in trunk was refactored to join() where appropriate, or at
least verify that the subscription was complete before being
destroyed.
Review: https://reviewboard.asterisk.org/r/2540
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does two things:
* It fixes a bug where the outbound channel's application/data set by the
dialing API/app_dial is not communicated until the channel is hung up.
If that happens, AMI would incorrectly send a NewExten event immediately
after a Hangup. This isn't really AMI's fault, as the dialing APIs never
communicated the 'helpful' app/data on the outbound channel until it was
hungup.
* It makes public sending a stasis message about a change in channel state.
This is useful enough that - for now at least - it should be public. If
operations on a channel go to being more coarse-grained, this function
could be made private again.
Review: https://reviewboard.asterisk.org/r/2548
Note that this problem was found and reported by Matt DiMeo.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds a framework in res_stasis for handling events from
channel topics. JSON event generation and validation code is created
from event documentation in rest-api/api-docs/events.json to assist in
JSON event generation, ensure consistency, and ensure that accurate
documentation is available for ALL events that are received by
res_stasis applications.
The userevent application has been refactored along with the code that
handles userevent channel blob events to pass the headers as key/value
pairs in the JSON blob. As a side-effect, app_userevent now handles
duplicate keys by overwriting the previous value.
Review: https://reviewboard.asterisk.org/r/2428/
(closes issue ASTERISK-21180)
Patch-By: Kinsey Moore <kmoore@digium.com>
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388275 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we first introduced the channel blob types, the JSON blobs were
self identifying by a required "type" field in the JSON object
itself. This, as it turns out, was a bad idea.
When we introduced the message router, it was useless for routing based
on the JSON type. And messages had two type fields to check: the
stasis_message_type() of the message itself, plus the type field in the
JSON blob (but only if it was a blob message).
This patch corrects that mistake by removing the required type field
from JSON blobs, and introducing first class stasis_message_type objects
for the actual message type.
Since we now will have a proliferation of message types, I introduced a
few macros to help reduce the amount of boilerplate necessary to set
them up.
Review: https://reviewboard.asterisk.org/r/2509
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After some discussion on asterisk-dev, it was decided that the bulk of
the logic in app_stasis actually belongs in a resource module instead
of the application module.
This patch does that, leaves the app specific stuff in app_stasis, and
fixes up everything else to be consistent with that change.
* Renamed test_app_stasis to test_res_stasis
* Renamed app_stasis.h to stasis_app.h
* This is still stasis application support, even though it's no
longer in an app_ module. The name should never have been tied to
the type of module, anyways.
* Now that json isn't a resource module anymore, moved the
ast_channel_snapshot_to_json function to main/stasis_channels.c,
where it makes more sense.
Review: https://reviewboard.asterisk.org/r/2430/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For the events that have been ported to Stasis, this was broken in
r384910, when a couple of lines of code was lost in a merge.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385236 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* A new Stasis payload has been defined for multi-channel messages. This
payload can store multiple ast_channel_snapshot objects along with a single
JSON blob. The payload object itself is opaque; the snapshots are stored
in a container keyed by roles. APIs have been provided to query for and
retrieve the snapshots from the payload object.
* The Dial AMI events have been refactored onto Stasis. This includes dial
messages in app_dial, as well as the core dialing framework. The AMI events
have been modified to send out a DialBegin/DialEnd events, as opposed to
the subevent type that was previously used.
* Stasis messages, types, and other objects related to channels have been
placed in their own file, stasis_channels. Unit tests for some of these
objects/messages have also been written.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3