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
* Change applicationmap and featuregroup to replace duplicate config items
rather than reject them.
* Remove some unneeded warning messages when getting the applicationmap
allows duplicates from DYNAMIC_FEATURES.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390803 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When reading from a config file, it's important to reject duplicates. Otherwise,
featuregroups will have ambiguity when pointing to applicationmap items. However,
when constructing the channel's current applicationmap, we don't care about duplicate
names since it's the DTMF that identifies a feature, not the name.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* The channel variable ATTENDED_TRANSFER_COMPLETE_SOUND is no longer
channel driver specific. If the channel variable is set on the
transferrer channel, the sound will be played to the target of an attended
transfer.
* The channel variable BRIDGEPEER becomes a comma separated list of peers
in a multi-party bridge. The BRIDGEPEER value can have a maximum of 10
peers listed. Any more peers in the bridge will not be included in the
list. BRIDGEPEER is not valid in holding bridges like parking since those
channels do not talk to each other even though they are in a bridge.
* The channel variable BRIDGEPVTCALLID is only valid for two party bridges
and will contain a value if the BRIDGEPEER's channel driver supports it.
* The channel variable DYNAMIC_PEERNAME is redundant with BRIDGEPEER and
is removed. The more useful DYNAMIC_WHO_ACTIVATED gives the channel name
that activated the dynamic feature.
* The channel variables DYNAMIC_FEATURENAME and DYNAMIC_WHO_ACTIVATED are
set only on the channel executing the dynamic feature. Executing a
dynamic feature on the bridge peer in a multi-party bridge will execute it
on all peers of the activating channel.
(closes issue ASTERISK-21555)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2582/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Features configuration is handled in its own API in
features_config.h and features_config.c. This way, features
configuration is accessible to anything that needs it.
In addition, features configuration has been altered to
be more channel-oriented. Most callers of features API
code will be supplying a channel so that the individual
channel's settings will be acquired rather than the global
setting.
Missing from this commit is XML documentation for the
features configuration. That will be handled in a separate
commit.
Review: https://reviewboard.asterisk.org/r/2578/
(issue ASTERISK-21542)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390751 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix external attended transfer bridge move/swap method. One of the
transferrer channels was not kicked out of the bridge.
* Fix several off-nominal extended attended transfer paths. Mainly the
channels involved needed to be hung up or kicked out of the bridge.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_multi_channel_blob_get_channel function does not bump the refcount on
the channel snapshot that it returns. This is typical for Stasis message
payloads, since being immutable means that the object won't get unreffed out
from underneath you.
The manager code for chanspy was unreffing the snapshots it got out of the
multi-channel blob, which was one unref too many.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change is used to make bridge hook removal more generic. This way,
depending on the circumstance, the appropriate bridge hooks may be
removed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When channels are added to an endpoint, the code originally posted a channel
snapshot to the endoint's topic directly. Turns out, this is a bad idea.
This causes the endpoint to see an inconsistent view of the channel, since it
will later receive in-flight messages with old channel snapshots.
This patch instead just publishes channel state immediately after setting up
the forward to the endpoint's topic. This gives the endpoints a consistent
view of the channel's state.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390472 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The library that provides UUID support varies greatly from system to
system. On most Linux distros, it's in libuuid. On OpenBSD, it's in
libe2fs-uuid. On OS X, it is in libsystem.
This patch plays hide-and-seek with UUID support, looking for it in the
three places we know about. It also corrects the Makefile so that it uses
the configured library name and include path.
(closes issue ASTERISK-21816)
Reported by: Brad Latus (snuffy)
Tested by: Brad Latus (snuffy)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390352 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
Check the returned bridged pointer for NULL to avoid a crash. It looks
like chan_agent is returning a NULL pointer when it probably should be
returning a pointer to the channel the Agent channel is pretending to be.
(closes issue ASTERISK-21793)
Reported by: Rodrigo P. Telles
Patches:
jira_asterisk_21793_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Rodrigo P. Telles
........
Merged revisions 390044 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 390047 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code was still attempting to pack an additional item into the blobs
that didn't exist. Crashes ensued. This patch modifies the publishing of
these messages so that the correct number of items are packed in the JSON.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389990 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
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
In r389799, a number of fax errors in gateway mode were fixed by using the
appropriate function to get a channel's peer while in a bridge. This patch
does two things:
(1) It uses the same function in res_fax_spandsp while starting the fax
gateway. Without this, the fax gateway will not actually start up, as
res_fax_spandsp also must inspect the channel's peer in a two-party
bridge
(2) It refactors some ao2 objects in sendfax_exec to use RAII_VAR. This was
reverted in r389799 as some off nominal paths were getting hit without
the fix in (1) that indicated an ao2 object issue; this turned out to
be a red herring (which is an odd phrase)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389827 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Caching topics will during initialization attempt to reference
their message type. The message type therefore has to be
initialized prior to the topic to prevent the dreaded assertion.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389813 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fax gateway requires knowledge of a channel's peer in a bridge. This patch
now uses the supported mechanisms to get this information.
This is acceptable for a few reasons:
* Fax gateway can only ever work in a 2-party bridge
* Fax gateway cannot work when not in a bridge
* Fax gateway cannot work without knowledge of the capabilities of both
channels in the fax operation (it is, after all, a gateway)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Initialize a Stasis-Core message type prior to initializing a caching topic.
The caching topic will attempt to use the message type.
* Don't attempt to publish Stasis-Core messages from remote console connections.
They aren't the main process; they shouldn't attempt to behave as it (they also
don't have the infrastructure to do so)
* Don't treat a JSON object as an ao2 object (whoops)
* In asterisk.c, ref bump the JSON even package that is distributed with the
event meta data. The callers assume that they own the reference, and the packing
routine steals references.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
