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
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
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
This moves the JSON event generators out of the Stasis-HTTP modules and
into standalone JSON-related counterparts so that Stasis-HTTP and
res_stasis can depend on them without creating dependency cycles. This
also provides a future location for Swagger Model validator functions
once the generators for that code are written.
Review: https://reviewboard.asterisk.org/r/2534/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388668 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
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
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
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
