When checking compatability for the native RTP bridge technology there is a
race condition between clearing framehooks that are destroyed when leaving
certain bridges with certain technologies (such as bridge_native_rtp) and
joining bridges with the bridge_native_rtp technology. Yes, that means a
channel in a native RTP bridge could move to another native RTP bridge and
be considered incompatible with the new native RTP bridge causing it to
revert to a simple bridge technology0. This fixes that bug by ignoring
framehooks that have been marked for destruction when checking for
compatibility with the bridge_native_rtp technology.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391453 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
This adds support for Stasis applications to receive bridge-related
messages when the application shows interest in a given bridge.
To supplement this work and test it, this also adds support for the
following bridge-related Stasis-HTTP functionality:
* GET stasis/bridges
* GET stasis/bridges/{bridgeId}
* POST stasis/bridges
* DELETE stasis/bridges/{bridgeId}
* POST stasis/bridges/{bridgeId}/addChannel
* POST stasis/bridges/{bridgeId}/removeChannel
Review: https://reviewboard.asterisk.org/r/2572/
(closes issue ASTERISK-21711)
(closes issue ASTERISK-21621)
(closes issue ASTERISK-21622)
(closes issue ASTERISK-21623)
(closes issue ASTERISK-21624)
(closes issue ASTERISK-21625)
(closes issue ASTERISK-21626)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch allows astmm to access the backtrace generation code in Asterisk.
When memory is allocated, a backtrace is created and stored with the memory
region that tracks the allocation. If a memory corruption is detected, the
backtrace is printed to the astmm log. The backtrace will make use of the
BETTER_BACKTRACES build option if available.
As a result, this patch moves the backtrace generation code into its own file
and uses the non-wrapped versions of the C library memory allocation routines.
This allows the memory allocation code to safely use the backtrace generation
routines without infinitely recursing.
Review: https://reviewboard.asterisk.org/r/2567
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391012 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added a start technology callback that technologies can use to start
bridging operations. It is expected that native bridges will find this
useful.
* Factored out bridge_channel_complete_join().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A three party bridge uses the softmix bridging technology. This
technology has a dedicated thread used to perform the analog mixing. When
one of these parties leaves the bridge, the bridge technology is changed
from the softmix technology to a two-party mixing technology. Changing
technologies is done by removing channels from the old technology and
adding them to the new technology. Since the remaining channels do not
leave the bridge, the softmix mixing thread could continue to process all
channels in the bridge. If the bridge code is not able to start
destruction of the softmix technology before the softmix mixing thread
wakes up, a crash happens.
* Added a stop technology callback that technologies can use to request
any helper threads to stop in preparation for being destroyed.
(closes issue AST-1156)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390975 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
* 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
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
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
* 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
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
Asterisk REST interface.
This adds the /playback/{playbackId}/control resource, which may be
POSTed to to pause, unpause, reverse, forward or restart the media
playback.
Attempts to control a playback that is not currently playing will
either return a 404 Not Found (because the playback object no longer
exists) or a 409 Conflict (because the playback object is still in the
queue to be played).
This patch also adds skipms and offsetms parameters to the
/channels/{channelId}/play resource.
(closes issue ASTERISK-21587)
Review: https://reviewboard.asterisk.org/r/2559
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389603 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
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
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
When implementing playback for stasis-http, the monolithicedness of
res_stasis really started to get in my way.
This patch breaks the major components of res_stasis.c into individual
files.
* res/stasis/app.c - Stasis application tracking
* res/stasis/control.c - Channel control objects
* res/stasis/command.c - Channel command object
This refactoring also allows res_stasis applications to be loaded as
independent modules, such as the new res_stasis_answer module.
The bulk of this patch is simply moving code from one file to another,
adjusting names and adding accessors as necessary.
Review: https://reviewboard.asterisk.org/r/2530/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388729 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The debug versions of ao2_ref() should only be used if REF_DEBUG is
enabled so nothing is written to /tmp/refs unexpectedly.
(closes issue ASTERISK-21785)
Reported by: abelbeck
Patches:
jira_asterisk_21785_v11.patch (license #5621) patch uploaded by rmudgett
Tested by: abelbeck
........
Merged revisions 388700 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I've noticed when doing a graceful shutdown that the res_stasis_http.so
module gets unloaded before the modules that use it, which causes some
asserts during their unload.
While r386928 was a quick hack to get it to not assert and die, this
patch increases the use counts on res_stasis.so and res_stasis_http.so
properly. It's a bigger change than I expected, hence the review instead
of just committing it.
Review: https://reviewboard.asterisk.org/r/2489/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388350 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
A GCC bug[1] can, in some cases, pop up an unsuppressible pedwarn when
using a static inline standard library function from a non-static
inline function.
This normally doesn't show up, but can occur if you're running an
upgrade version of GCC (such as GCC 4.8 on OS X, which normally runs
GCC 4.2).
[1]: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47816
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388046 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
An endpoint is an external device/system that may offer/accept
channels to/from Asterisk. While this is a very useful concept for end
users, it is surprisingly not a core concept within Asterisk itself.
This patch defines ast_endpoint as a separate object, which channel
drivers may use to expose their concept of an endpoint. As the channel
driver creates channels, it can use ast_endpoint_add_channel() to
associate channels to the endpoint. This updated the endpoint
appropriately, and forwards all of the channel's events to the
endpoint's topic.
In order to avoid excessive locking on the endpoint object itself, the
mutable state is not accessible via getters. Instead, you can create a
snapshot using ast_endpoint_snapshot_create() to get a consistent
snapshot of the internal state.
This patch also includes a set of topics and messages associated with
endpoints, and implementations of the endpoint-related RESTful
API. chan_sip was updated to create endpoints with SIP peers, but the
state of the endpoints is not updated with the state of the peer.
Along for the ride in this patch is a Stasis test API. This is a
stasis_message_sink object, which can be subscribed to a Stasis
topic. It has functions for blocking while waiting for conditions in
the message sink to be fulfilled.
(closes issue ASTERISK-21421)
Review: https://reviewboard.asterisk.org/r/2492/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds the ability for modules to add themselves as observers
to sorcery object types. Observers can be notified when objects are
created, updated, or deleted as well as when the object type is loaded or
reloaded. Observer notifications are done using a thread pool in a serialized
fashion so the caller of the sorcery API calls is minimally impacted.
This also adds the ability to create JSON changesets of a sorcery object.
Tests are also present to confirm all of the above functionality.
Review: https://reviewboard.asterisk.org/r/2477/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch:
* Cleans up some doxygen
* Prevents leaking the system level Stasis topics and messages
on exit (users of valgrind will be happier)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change does the following:
1. Adds the sorcery realtime module
2. Adds unit tests for the sorcery realtime module
3. Changes the realtime core to use an ast_variable list instead of variadic arguments
4. Changes all realtime drivers to accept an ast_variable list
Review: https://reviewboard.asterisk.org/r/2424/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In order to get people familiar with the Stasis message bus, it would
be useful to have something of a tutorial. Since I'm not clever enough
to think of some cool integration we could do with Twitter, I settled
for something that might actually be useful.
This patch adds a res_statsd.so module, which implements a basic
statsd[1] client. Statsd is a very simple statistics gathering server,
which can publish its results to a backend graphing engine, like
Graphite[2]. There are several different Statsd server
implementations[3], so you can pick what works best for your
environment.
The actual example of how to use the Stasis message bus is in
res_chan_stats.so. This module demonstrates how to use subscriptions
and the message router by monitoring messages and posting channels
stats to the statsd server.
A wiki page walking through res_chan_stats.so is forthcoming.
[1]: https://github.com/etsy/statsd/
[2]: http://graphite.readthedocs.org/en/latest/
[3]: http://joemiller.me/2011/09/21/list-of-statsd-server-implementations/
Review: https://reviewboard.asterisk.org/r/2460/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386624 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The pimp_my_sip branch is being merged at this point because
it offers basic functionality, and from an API standpoint, things
are complete.
SIP work is *not* feature-complete; however, with the completion
of the SUBSCRIBE/NOTIFY API, all APIs (except a PUBLISH API) have
been created, and thus it is possible for developers to attempt
to create new SIP work.
API documentation can be found in the doxygen in the code, but
usability documentation is still lacking.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386540 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The API itself is documented using Swagger, a lightweight mechanism for
documenting RESTful API's using JSON. This allows us to use swagger-ui
to provide executable documentation for the API, generate client
bindings in different languages, and generate a lot of the boilerplate
code for implementing the RESTful bindings. The API docs live in the
rest-api/ directory.
The RESTful bindings are generated from the Swagger API docs using a set
of Mustache templates. The code generator is written in Python, and
uses Pystache. Pystache has no dependencies, and be installed easily
using pip. Code generation code lives in rest-api-templates/.
The generated code reduces a lot of boilerplate when it comes to
handling HTTP requests. It also helps us have greater consistency in the
REST API.
(closes issue ASTERISK-20891)
Review: https://reviewboard.asterisk.org/r/2376/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386232 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the concept of ast_websocket_server to
res_http_websocket, allowing WebSocket connections on URL's more more
than /ws.
The existing funcitons for managing the WebSocket subprotocols on /ws
still work, so this patch should be completely backward compatible.
(closes issue ASTERISK-21279)
Review: https://reviewboard.asterisk.org/r/2453/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386020 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the move from Asterisk's event system to Stasis, this makes
distributed device state aggregation always-on, removes unnecessary
task processors where possible, and collapses aggregate and
non-aggregate states into a single cache for ease of retrieval. This
also removes an intermediary step in device state aggregation.
Review: https://reviewboard.asterisk.org/r/2389/
(closes issue ASTERISK-21101)
Patch-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385860 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
refactored to use these events rather than producing the events directly
in channel.c. Finally, the code was added to app_stasis to produce
DTMF events on the WebSocket.
The AMI events are completely backward compatible, including sending
events on transmitted DTMF, and sending DTMF start events.
The Stasis-HTTP events are somewhat simplified. Since DTMF start and
DTMF send events are generally less useful, Stasis-HTTP will only send
events on received DTMF end.
(closes issue ASTERISK-21282)
(closes issue ASTERISK-21359)
Review: https://reviewboard.asterisk.org/r/2439
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385734 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These functions are already used in one branch (jrose's parking branch)
and will soon be used in other branches as well.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385522 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
This is the API that binds the Stasis dialplan application to external
Stasis applications. It also adds the beginnings of WebSocket
application support.
This module registers a dialplan function named Stasis, which is used
to put a channel into the named Stasis app. As a channel enters and
leaves the Stasis diaplan application, the Stasis app receives a
'stasis-start' and 'stasis-end' events.
Stasis apps register themselves using the stasis_app_register and
stasis_app_unregister functions. Messages are sent to an application
using stasis_app_send.
Finally, Stasis apps control channels through the use of the
stasis_app_control object, and the family of stasis_app_control_*
functions.
Other changes along for the ride are:
* An ast_frame_dtor function that's RAII_VAR safe
* Some common JSON encoders for name/number, timeval, and
context/extension/priority
Review: https://reviewboard.asterisk.org/r/2361/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a bug introduced in r76703, wherein Asterisk could only parse
arguments in the so-called 'recommended' way, e.g., NoOp(foo,bar). The proper
syntax of NoOp,foo|bar is now parsed correctly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch migrates the TestEvent AMI events to first be dispatched over the
Stasis-Core message bus. This helps to preserve the ordering of the events
with other events in the AMI system, such as the various channel related
events.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384389 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Updated test_uuid.c to test the new API call.
* Made system use the new API call to eliminate "10's of lines" where
used.
* Fixed untested ast_strdup() return in stasis_subscribe() by eliminating
the need for it. struct stasis_subscription now contains the uniqueid[]
string.
* Fixed some issues in exchangecal_write_event():
Create uid with enough space for a UUID string to avoid a realloc.
Fix off by one error if the calendar event provided a UUID string.
There is no need to check for NULL before calling ast_free().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
HangupRequest and SoftHangupRequest are now ast_channel_blob Stasis
messages, with the cause code as an optional field in the blob.
NewCallerid now simply watches for changes in the callerid information
in channel snapshots, and creates the AMI event appropriately.
Since the original NewCallerid event honored the channelvars setting
in manager.conf, the channel variables configured there had to become
a part of the channel snapshot. These are now a part of every snapshot
based event, making the configuration description "every time a
channel-oriented event is emitted" less of a lie.
There a a few other changes wrapped up in here as well.
* When ast_channel_topic() is given NULL for a channel, it returns
the ast_channel_topic_all() topic instead of NULL. This can clean
up a lot of NULL checking we're doing currently.
* The fields Cause and Cause-txt were removed from the base channel
information and put only on the Hangup events, since those fields
are meaningless outside of a Hangup event.
* Removed the pipe-delimiter processing of the channelvars field,
since that's been deprecated forever.
(closes issue ASTERISK-21096)
Review: https://reviewboard.asterisk.org/r/2405/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383726 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When I moved res_json.c to json.c, I left the MODULE_INFO stuff in there,
which was interesting if you ran module show. I also forgot to call what
was in module_load() from asterisk main().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383611 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch started out simply as fixing the bouncing tests introduced
in r382685, but required some other changes to give it a decent
implementation.
To fix the bouncing tests, the UserEvent and Newexten AMI events
needed to be refactored to dispatch via Stasis. Dispatching directly
to AMI resulted in those events sometimes getting ahead of the
associated Newchannel events, which would understandably confuse anyone.
I found that instead of creating a zillion different message types and
structures associated with them, it would be preferable to define a
message type that has a channel snapshot and a blob of structured data
with a small bit of additional information. The JSON object model
provides a very nice way of representing structured data, so I went
with that.
* Move JSON support from res_json.c to main/json.c
* Made libjansson-dev a required dependency
* Added an ast_channel_blob message type, which has a channel
snapshot and JSON blob of data.
* Changed UserEvent and Newexten events so that they are dispatched
via ast_channel_blob messages on the channel's topic.
* Got rid of the ast_channel_varset message; used ast_channel_blob
instead.
* Extracted the manager functions converting Stasis channel events to
AMI events into manager_channel.c.
(issue ASTERISK-21096)
Review: https://reviewboard.asterisk.org/r/2381/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383579 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Remove MWI's dependency on the event system by moving it to
Stasis-core. This also introduces forwarding topic pools in Stasis-core
which aggregate many dynamically allocated topics into a single primary
topic.
Review: https://reviewboard.asterisk.org/r/2368/
(closes issue ASTERISK-21097)
Patch-by: Kinsey Moore
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Often times, when subscribing to a topic, one wants to handle
different message types differently. While one could cascade if/else
statements through the subscription handler, it is much cleaner to
specify a different callback for each message type. The
stasis_message_router is here to help!
A stasis_message_router is constructed for a particular stasis_topic,
which is subscribes to. Call stasis_message_router_unsubscribe() to
cancel that subscription.
Once constructed, routes can be added using
stasis_message_router_add() (or stasis_message_router_set_default()
for any messages not handled by other routes). There may be only one
route per stasis_message_type. The route's callback is invoked just as
if it were a callback for a subscription; but it only gets called for
messages of the specified type.
(issue ASTERISK-20887)
Review: https://reviewboard.asterisk.org/r/2390/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383242 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unsubscribing things in Asterisk seems to very commonly follow with
NULLing out the variable that was unsubscribed. This change makes that
a bit simpler.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The cache dump mechanism allows the developer to retreive multiple
items of a given type (or of all types) from the cache residing in a
stasis caching topic in addition to the existing single-item cache
retreival mechanism. This also adds to the caching unit tests to
ensure that the new cache dump mechanism is functioning properly.
Review: https://reviewboard.asterisk.org/r/2367/
(issue ASTERISK-21097)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For the initial use of this bus, I took some work kmoore did creating
channel snapshots. So rather than create AMI events directly in the
channel code, this patch generates Stasis events, which manager.c uses
to then publish the AMI event.
This message bus provides a generic publish/subscribe mechanism within
Asterisk. This message bus is:
- Loosely coupled; new message types can be added in seperate modules.
- Easy to use; publishing and subscribing are straightforward
operations.
In addition to basic publish/subscribe, the patch also provides
mechanisms for message forwarding, and for message caching.
(issue ASTERISK-20887)
(closes issue ASTERISK-20959)
Review: https://reviewboard.asterisk.org/r/2339/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Often, Asterisk may realize that a change in the source of an RTP stream is
about to occur and ask that the RTP engine reset it's lock on the current RTP
source. In certain scenarios, it may take awhile for the new remote system to
send RTP packets, while the old remote system may continue providing RTP during
that time period. This causes Asterisk to re-lock onto the old source, thereby
rejecting the new source when the old source stops sending RTP and the new
source begins.
This patch prevents that by having a constant secondary, 'secret' probation
mode enabled when an RTP source has been chosen. RTP packets from other sources
are always considered, but never chosen unless the current RTP source stops
sending RTP.
Review: https://reviewboard.asterisk.org/r/2364
(closes issue AST-1124)
Reported by: John Bigelow
Tested by: John Bigelow
(closes issue AST-1125)
Reported by: John Bigelow
Tested by: John Bigelow
........
Merged revisions 382573 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Jonathan Rose
David M. Lee
Kinsey Moore
Matthew Jordan
Richard Mudgett
Mark Michelson
Jason Parker
Joshua Colp
Sean Bright
Olle Johansson
Andrew Latham