| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds error checking to ARI bridge operations, when
adding/removing channels to/from bridges.
In general, the error codes fall out as follows:
* Bridge not found - 404 Not Found
* Bridge not in Stasis - 409 Conflict
* Channel not found - 400 Bad Request
* Channel not in Stasis - 422 Unprocessable Entity
* Channel not in this bridge (on remove) - 422 Unprocessable Entity
(closes issue ASTERISK-22036)
Review: https://reviewboard.asterisk.org/r/2769/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In the shuffling around of res_stasis, control_continue was renamed to
stasis_app_control_continue, but the call in res_stasis wasn't updated.
In looking into it, it turns out it wasn't really the right thing to do
in res_stasis anyways.
This patch changes the handling of received a AST_CONTROL_HANGUP frame
to be the same as receiving a NULL frame, and removed the declaration of
control_continue(), since it doesn't exist any more.
(closes issue ASTERISK-22292)
Reported by: Denis Smirnov
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch changes ARI bridging to allow other channel operations to
happen while the channel is bridged.
ARI channel operations are designed to queue up and execute
sequentially. This meant, though, that while a channel was bridged,
any other channel operations would queue up and execute only after the
channel left the bridge.
This patch changes ARI bridging so that channel commands can execute
while the channel is bridged. For most operations, things simply work
as expected. The one thing that ended up being a bit odd is recording.
The current recording implementation will fail when one attempts to
record a channel that's in a bridge. Note that the bridge itself may
be recording; it's recording a specific channel in the bridge that
fails. While this is an annoying limitation, channel recording is
still very useful for use cases such as voice mail, and bridge
recording makes up much of the difference for other use cases.
(closes issue ASTERISK-22084)
Review: https://reviewboard.asterisk.org/r/2726/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396568 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Roles are now cleared with each entry into a bridge with addChannel.
If the roles parameter is present, the role specified will be applied
to all channels being added with the addChannel command.
(closes issue ASTERISK-21973)
Reported by: Matt Jordan
https://reviewboard.asterisk.org/r/2691/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396182 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
|
|
A typo in recent changes caused the JSON ApplicationReplaced message to
fail to build, so the message wasn't being sent out the WebSocket.
Related, the replaced application would also unregister itself when it
disconnected, which would actually unregister the new application. This
was also fixed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395527 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch addresses a bug in the /ari/events WebSocket in handling
reconnects.
When a Stasis application's associated WebSocket was disconnected and
reconnected, it would not receive events for any channels or bridges
it was subscribed to.
The fix was to lazily clean up Stasis application registrations,
instead of removing them as soon as the WebSocket goes away.
When an application is unregistered at the WebSocket level, the
underlying application is simply deactivated. If the application
WebSocket is reconnected, the application is reactivated for the new
connection.
To avoid memory leaks from lingering, unused application, the
application list is cleaned up whenever new applications are
registered/unregistered.
(closes issue ASTERISK-21970)
Review: https://reviewboard.asterisk.org/r/2678/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(issue ASTERISK-21974)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2680/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394810 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Adds a new channel driver for creating channels for specific purposes
in bridges, primarily to act as either recorders or announcers. Adds
ARI commands for playing announcements to ever participant in a bridge
as well as for recording a bridge. This patch also includes some
documentation/reponse fixes to related ARI models such as playback
controls.
(closes issue ASTERISK-21592)
Reported by: Matt Jordan
(closes issue ASTERISK-21593)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2670/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Also convert res_mutestream to use the core feature behind this.
(closes issue ASTERISK-21618)
Review: https://reviewboard.asterisk.org/r/2652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This allows for reading and writing of functions on channels.
(closes issue ASTERISK-21868)
Review: https://reviewboard.asterisk.org/r/2641/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393806 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This puts the channel on hold (rather than queueing a frame from the channel).
(closes issue ASTERISK-21619)
Review: https://reviewboard.asterisk.org/r/2647/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393332 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This creates a new outbound channel, and bridges it to a channel already in
the Stasis application.
(closes issue ASTERISK-21620)
Review: https://reviewboard.asterisk.org/r/2634/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This allows going elsewhere in the dialplan, so that the location can be
specified after exiting the Stasis application.
(closes issue ASTERISK-21870)
Review: https://reviewboard.asterisk.org/r/2644/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392987 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
|
|
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
|
|
Also added some missing doc comments for stasis/app.h.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388896 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
|
