Adds a tones URI type to the playback resource. The tone can be specified by
name (from indications.conf) or by a tone pattern. In addition, tonezone can
be specified in the URI (by appending ;tonezone=<zone>). Tones must be
stopped manually in order for a stasis control to move on from playback of
the tone. Tones may be paused, resumed, restarted, and stopped. They may
not be rewound or fast forwarded (tones can't be controlled in a way that
lets you skip around from note to note and pausing and resuming will also
restart the tone from the beginning). Tests are currently in development
for this feature (https://reviewboard.asterisk.org/r/3428/).
(closes issue ASTERISK-23433)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3427/
........
Merged revisions 412535 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It updates the AMI version to 2.2.0 to indicate backwards compatible
changes have been made since the last release
* It updates the ARI version to 1.2.0 to indicate backwards compatible
changes have been made since the last release
* It updates the UPGRADE/CHANGES files with changes that were not
mentioned
........
Merged revisions 411529 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds back in support for specifying channel variables during an
originate without compromising the ability to specify query parameters
in the JSON body. This was accomplished by generating the body-parsing
code in a separate function instead of being integrated with the URI
query parameter parsing code such that it could be called by paths with
body parameters. This is transparent to the user of the API and
prevents manual duplication of code or data structures.
(closes issue ASTERISK-23051)
Review: https://reviewboard.asterisk.org/r/3122/
Reported by: Matt Jordan
........
Merged revisions 406003 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we added support for specifying channel variables for an
origination, we didn't consider how that would interact with another
feature, namely specifying request parameters in a JSON request body.
The method of specifying channel variables (as a flat JSON object passed
in the JSON body) interferes with parsing parameters out of the request
body.
Unfortunately, fixing this would be a backward incompatible change. In
the interest of keeping the API sane and keeping our release schedule,
we're dropping the feature for specifying channel variables in the
origination request.
We will bring the feature back soon, as a backward compatible addition
to the API.
(closes issue ASTERISK-23051)
Review: https://reviewboard.asterisk.org/r/3088
........
Merged revisions 404509 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404512 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the ability to specify channel variables when creating/originating a
channel in ARI. The variables are sent in the body of the request and should
be formatted as a single level JSON object. No nested objects allowed.
For example: {"variable1": "foo", "variable2": "bar"}.
(closes issue ASTERISK-22872)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3052/
........
Merged revisions 403752 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While working on building client libraries from the Swagger API, I
noticed a problem with the nicknames.
channel.deleteChannel()
channel.answerChannel()
channel.muteChannel()
Etc. We put the object name in the nickname (since we were generating C
code), but it makes OO generators redundant.
This patch makes the nicknames more OO friendly. This resulted in a lot
of name changing within the res_ari_*.so modules, but not much else.
There were a couple of other fixed I made in the process.
* When reversible operations (POST /hold, POST /unhold) were made more
RESTful (POST /hold, DELETE /unhold), the path for the second operation
was left in the API declaration. This worked, but really the two
operations should have been on the same API.
* The POST /unmute operation had still not been REST-ified.
Review: https://reviewboard.asterisk.org/r/2940/
........
Merged revisions 402528 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ring operation sends ringing to the specified channel it is invoked on.
The dtmf operation can be used to send DTMF digits to the specified channel
of a specific length with a wait time in between. Finally hangup reasons
allow you to specify why a channel is being hung up (busy, congestion).
Early media behavior has also been tweaked slightly. When playing media to a channel
it will no longer automatically answer. If it has not been answered a progress indication
is sent instead.
(closes issue ASTERISK-22701)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2916/
........
Merged revisions 402358 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This makes it clear that the ARI API calls for listing channels and
bridges will list all channels or bridges in the system and not just
those that are in or are controlled by a Stasis application.
(closes issue ASTERISK-22635)
Reported by: Kevin Harwell
........
Merged revisions 401087 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401088 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Both /asterisk/variable and /channel/{channelId}/variable requires a
?variable parameter to be passed into the query. But we weren't checking
for the parameter being missing, which caused a segfault.
All calls now properly return 400 Bad Request errors when the parameter
is missing. The Swagger api-docs were updated accordingly.
(closes issue ASTERISK-22273)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Swagger allows parameters to be specified as 'allowMultiple', meaning
that the parameter may be specified as a comma separated list of
values.
I had written some of the API docs using that, but promptly forgot
about implementing it. This patch finally fills in that gap.
The codegen template was updated to represent 'allowMultiple' fields
as array/size fields in the _args structs. It also parses the comma
separated list using ast_app_separate_args(), so quoted strings in the
argument will be handled properly.
Review: https://reviewboard.asterisk.org/r/2698/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396122 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
This patch is the first step in adding recording support to the
Asterisk REST Interface.
Recordings are stored in /var/spool/recording. Since recordings may be
destructive (overwriting existing files), the API rejects attempts to
escape the recording directory (avoiding issues if someone attempts to
record to ../../lib/sounds/greeting, for example).
(closes issue ASTERISK-21594)
(closes issue ASTERISK-21581)
Review: https://reviewboard.asterisk.org/r/2612/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393550 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 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
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
Matthew Jordan
Jonathan Rose
Scott Griepentrog
Kinsey Moore
David M. Lee
Kevin Harwell
Joshua Colp
Paul Belanger
Jason Parker