2013-04-22 14:58:53 +00:00
{
"_copyright" : "Copyright (C) 2012 - 2013, Digium, Inc." ,
"_author" : "David M. Lee, II <dlee@digium.com>" ,
"_svn_revision" : "$Revision$" ,
2016-11-18 09:46:48 -06:00
"apiVersion" : "2.0.0" ,
2013-10-24 20:48:17 +00:00
"swaggerVersion" : "1.2" ,
2014-09-20 23:41:55 +00:00
"basePath" : "http://localhost:8088/ari" ,
2013-04-22 14:58:53 +00:00
"resourcePath" : "/api-docs/events.{format}" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2018-01-18 10:01:26 -05:00
"requiresModules" : [
"res_http_websocket"
] ,
2013-04-22 14:58:53 +00:00
"apis" : [
{
"path" : "/events" ,
"description" : "Events from Asterisk to applications" ,
"operations" : [
{
"httpMethod" : "GET" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-07-03 16:32:00 +00:00
"upgrade" : "websocket" ,
"websocketProtocol" : "ari" ,
2013-04-22 14:58:53 +00:00
"summary" : "WebSocket connection for events." ,
"nickname" : "eventWebsocket" ,
2013-07-05 19:15:27 +00:00
"responseClass" : "Message" ,
2013-04-22 14:58:53 +00:00
"parameters" : [
{
"name" : "app" ,
2013-08-02 14:36:32 +00:00
"description" : "Applications to subscribe to." ,
2013-04-22 14:58:53 +00:00
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : true ,
"dataType" : "string"
2015-09-04 12:25:07 -05:00
} ,
{
"name" : "subscribeAll" ,
"description" : "Subscribe to all Asterisk events. If provided, the applications listed will be subscribed to all events, effectively disabling the application specific subscriptions. Default is 'false'." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "boolean"
2013-04-22 14:58:53 +00:00
}
]
}
]
2014-05-22 16:09:51 +00:00
} ,
{
"path" : "/events/user/{eventName}" ,
"description" : "Stasis application user events" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.3.0"
] ,
2014-05-22 16:09:51 +00:00
"summary" : "Generate a user event." ,
"nickname" : "userEvent" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "eventName" ,
"description" : "Event name" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "application" ,
"description" : "The name of the application that will receive this event" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "source" ,
"description" : "URI for event source (channel:{channelId}, bridge:{bridgeId}, endpoint:{tech}/{resource}, deviceState:{deviceName}" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : true ,
"dataType" : "string"
} ,
{
"name" : "variables" ,
2014-07-03 16:14:39 +00:00
"description" : "The \"variables\" key in the body object holds custom key/value pairs to add to the user event. Ex. { \"variables\": { \"key\": \"value\" } }" ,
2014-05-22 16:09:51 +00:00
"paramType" : "body" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "containers"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Application does not exist."
} ,
{
"code" : 422 ,
"reason" : "Event source not found."
} ,
{
"code" : 400 ,
"reason" : "Invalid even tsource URI or userevent data."
}
]
}
]
2013-04-22 14:58:53 +00:00
}
] ,
"models" : {
2013-07-05 19:15:27 +00:00
"Message" : {
"id" : "Message" ,
"description" : "Base type for errors and events" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"discriminator" : "type" ,
2013-04-22 14:58:53 +00:00
"properties" : {
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"type" : {
"type" : "string" ,
"required" : true ,
2013-07-05 19:15:27 +00:00
"description" : "Indicates the type of this message."
2016-10-15 20:05:05 -05:00
} ,
"asterisk_id" : {
"type" : "string" ,
"required" : false ,
"description" : "The unique ID for the Asterisk instance that raised this event."
2013-07-05 19:15:27 +00:00
}
2013-10-24 20:48:17 +00:00
} ,
"subTypes" : [
"MissingParams" ,
"Event"
]
2013-07-05 19:15:27 +00:00
} ,
"MissingParams" : {
"id" : "MissingParams" ,
"description" : "Error event sent when required params are missing." ,
"properties" : {
"params" : {
"required" : true ,
"type" : "List[string]" ,
"description" : "A list of the missing parameters"
}
}
} ,
"Event" : {
"id" : "Event" ,
"description" : "Base type for asynchronous events from Asterisk." ,
"properties" : {
2013-04-22 14:58:53 +00:00
"application" : {
"type" : "string" ,
"description" : "Name of the application receiving the event." ,
"required" : true
} ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"timestamp" : {
"type" : "Date" ,
"description" : "Time at which this event was created." ,
2019-03-06 23:21:42 +01:00
"required" : true
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
}
2013-10-24 20:48:17 +00:00
} ,
"subTypes" : [
2013-11-23 17:48:28 +00:00
"DeviceStateChanged" ,
2013-10-24 20:48:17 +00:00
"PlaybackStarted" ,
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
"PlaybackContinuing" ,
2013-10-24 20:48:17 +00:00
"PlaybackFinished" ,
2013-11-30 14:12:50 +00:00
"RecordingStarted" ,
"RecordingFinished" ,
"RecordingFailed" ,
2019-03-07 07:52:20 -06:00
"ApplicationMoveFailed" ,
2013-10-24 20:48:17 +00:00
"ApplicationReplaced" ,
"BridgeCreated" ,
"BridgeDestroyed" ,
"BridgeMerged" ,
2014-02-01 16:26:57 +00:00
"BridgeBlindTransfer" ,
"BridgeAttendedTransfer" ,
2016-11-08 10:11:41 -06:00
"BridgeVideoSourceChanged" ,
2013-10-24 20:48:17 +00:00
"ChannelCreated" ,
"ChannelDestroyed" ,
"ChannelEnteredBridge" ,
"ChannelLeftBridge" ,
"ChannelStateChange" ,
"ChannelDtmfReceived" ,
"ChannelDialplan" ,
"ChannelCallerId" ,
"ChannelUserevent" ,
"ChannelHangupRequest" ,
"ChannelVarset" ,
2024-07-18 12:13:25 +02:00
"ChannelToneDetected" ,
2014-05-30 12:42:57 +00:00
"ChannelTalkingStarted" ,
"ChannelTalkingFinished" ,
2015-04-07 15:22:42 +00:00
"ChannelHold" ,
"ChannelUnhold" ,
2015-09-03 21:19:21 -05:00
"ContactStatusChange" ,
2013-10-24 20:48:17 +00:00
"EndpointStateChange" ,
2013-12-14 17:19:41 +00:00
"Dial" ,
2013-10-24 20:48:17 +00:00
"StasisEnd" ,
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
This patch adds the ability to send and receive text messages from various
technology stacks in Asterisk through ARI. This includes chan_sip (sip),
res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There
Both forms are available for message technologies that allow for arbitrary
destinations, such as chan_sip.
Inbound messages can now be received over ARI as well. An ARI application that
subscribes to endpoints will receive messages from those endpoints:
{
"type": "TextMessageReceived",
"timestamp": "2014-07-12T22:53:13.494-0500",
"endpoint": {
"technology": "PJSIP",
"resource": "alice",
"state": "online",
"channel_ids": []
},
"message": {
"from": "\"alice\" <sip:alice@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
The above was made possible due to some rather major changes in the message
core. This includes (but is not limited to):
- Users of the message API can now register message handlers. A handler has
two callbacks: one to determine if the handler has a destination for the
message, and another to handle it.
- All dialplan functionality of handling a message was moved into a message
handler provided by the message API.
- Messages can now have the technology/endpoint associated with them.
Various other properties are also now more easily accessible.
- A number of ao2 containers that weren't really needed were replaced with
vectors. Iteration over ao2_containers is expensive and pointless when
the lifetime of things is well defined and the number of things is very
small.
res_stasis now has a new file that makes up its structure, messaging. The
messaging functionality implements a message handler, and passes received
messages that match an interested endpoint over to the app for processing.
Note that inadvertently while testing this, I reproduced ASTERISK-23969.
res_pjsip_messaging was incorrectly parsing out the 'to' field, such that
arbitrary SIP URIs mangled the endpoint lookup. This patch includes the
fix for that as well.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
"StasisStart" ,
2014-12-08 16:24:36 +00:00
"TextMessageReceived" ,
2015-09-03 21:19:21 -05:00
"ChannelConnectedLine" ,
2024-06-15 16:01:58 +08:00
"PeerStatusChange" ,
2025-03-12 15:58:51 -06:00
"ChannelTransfer" ,
"RESTResponse"
2013-10-24 20:48:17 +00:00
]
2013-05-23 20:11:35 +00:00
} ,
2015-09-03 21:19:21 -05:00
"ContactInfo" : {
"id" : "ContactInfo" ,
"description" : "Detailed information about a contact on an endpoint." ,
"properties" : {
"uri" : {
"type" : "string" ,
"description" : "The location of the contact." ,
"required" : true
} ,
"contact_status" : {
"type" : "string" ,
"description" : "The current status of the contact." ,
"required" : true ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"Unreachable" ,
"Reachable" ,
"Unknown" ,
2017-12-11 15:27:29 -06:00
"NonQualified" ,
2015-09-03 21:19:21 -05:00
"Removed"
]
}
} ,
"aor" : {
"type" : "string" ,
"description" : "The Address of Record this contact belongs to." ,
"required" : true
} ,
"roundtrip_usec" : {
"type" : "string" ,
"description" : "Current round trip time, in microseconds, for the contact." ,
"required" : false
}
}
} ,
"Peer" : {
"id" : "Peer" ,
"description" : "Detailed information about a remote peer that communicates with Asterisk." ,
"properties" : {
"peer_status" : {
"type" : "string" ,
"description" : "The current state of the peer. Note that the values of the status are dependent on the underlying peer technology." ,
"required" : true
} ,
"cause" : {
"type" : "string" ,
"description" : "An optional reason associated with the change in peer_status." ,
"required" : false
} ,
"address" : {
"type" : "string" ,
"description" : "The IP address of the peer." ,
"required" : false
} ,
"port" : {
"type" : "string" ,
"description" : "The port of the peer." ,
"required" : false
} ,
"time" : {
"type" : "string" ,
"description" : "The last known time the peer was contacted." ,
"required" : false
}
}
} ,
2013-11-23 17:48:28 +00:00
"DeviceStateChanged" : {
"id" : "DeviceStateChanged" ,
"description" : "Notification that a device state has changed." ,
"properties" : {
"device_state" : {
"type" : "DeviceState" ,
"description" : "Device state object" ,
"required" : true
}
}
} ,
2013-05-23 20:11:35 +00:00
"PlaybackStarted" : {
"id" : "PlaybackStarted" ,
"description" : "Event showing the start of a media playback operation." ,
"properties" : {
"playback" : {
"type" : "Playback" ,
"description" : "Playback control object" ,
"required" : true
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
}
}
} ,
"PlaybackContinuing" : {
"id" : "PlaybackContinuing" ,
"description" : "Event showing the continuation of a media playback operation from one media URI to the next in the list." ,
"properties" : {
"playback" : {
"type" : "Playback" ,
"description" : "Playback control object" ,
"required" : true
2013-05-23 20:11:35 +00:00
}
}
} ,
"PlaybackFinished" : {
"id" : "PlaybackFinished" ,
"description" : "Event showing the completion of a media playback operation." ,
"properties" : {
"playback" : {
"type" : "Playback" ,
"description" : "Playback control object" ,
"required" : true
}
2013-04-22 14:58:53 +00:00
}
} ,
2013-10-25 21:28:32 +00:00
"RecordingStarted" : {
"id" : "RecordingStarted" ,
"description" : "Event showing the start of a recording operation." ,
"properties" : {
"recording" : {
"type" : "LiveRecording" ,
"description" : "Recording control object" ,
"required" : true
}
}
} ,
"RecordingFinished" : {
"id" : "RecordingFinished" ,
"description" : "Event showing the completion of a recording operation." ,
"properties" : {
"recording" : {
"type" : "LiveRecording" ,
"description" : "Recording control object" ,
"required" : true
}
}
} ,
"RecordingFailed" : {
"id" : "RecordingFailed" ,
"description" : "Event showing failure of a recording operation." ,
"properties" : {
"recording" : {
"type" : "LiveRecording" ,
"description" : "Recording control object" ,
"required" : true
}
}
} ,
2019-03-07 07:52:20 -06:00
"ApplicationMoveFailed" : {
"id" : "ApplicationMoveFailed" ,
"description" : "Notification that trying to move a channel to another Stasis application failed." ,
"properties" : {
"channel" : {
"required" : true ,
"type" : "Channel"
} ,
"destination" : {
"required" : true ,
"type" : "string"
} ,
"args" : {
"required" : true ,
"type" : "List[string]" ,
"description" : "Arguments to the application"
}
}
} ,
2013-04-22 14:58:53 +00:00
"ApplicationReplaced" : {
"id" : "ApplicationReplaced" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"description" : "Notification that another WebSocket has taken over for an application.\n\nAn application may only be subscribed to by a single WebSocket at a time. If multiple WebSockets attempt to subscribe to the same application, the newer WebSocket wins, and the older one receives this event." ,
"properties" : { }
2013-04-22 14:58:53 +00:00
} ,
2013-05-21 18:00:22 +00:00
"BridgeCreated" : {
"id" : "BridgeCreated" ,
"description" : "Notification that a bridge has been created." ,
"properties" : {
"bridge" : {
"required" : true ,
"type" : "Bridge"
}
}
} ,
"BridgeDestroyed" : {
"id" : "BridgeDestroyed" ,
"description" : "Notification that a bridge has been destroyed." ,
"properties" : {
"bridge" : {
"required" : true ,
"type" : "Bridge"
}
}
} ,
2013-06-10 13:07:11 +00:00
"BridgeMerged" : {
"id" : "BridgeMerged" ,
"description" : "Notification that one bridge has merged into another." ,
"properties" : {
"bridge" : {
"required" : true ,
"type" : "Bridge"
} ,
"bridge_from" : {
"required" : true ,
"type" : "Bridge"
}
}
} ,
2016-11-08 10:11:41 -06:00
"BridgeVideoSourceChanged" : {
"id" : "BridgeVideoSourceChanged" ,
"description" : "Notification that the source of video in a bridge has changed." ,
"properties" : {
"bridge" : {
"required" : true ,
"type" : "Bridge"
} ,
"old_video_source_id" : {
"required" : false ,
"type" : "string"
}
}
} ,
2014-02-01 16:26:57 +00:00
"BridgeBlindTransfer" : {
"id" : "BridgeBlindTransfer" ,
"description" : "Notification that a blind transfer has occurred." ,
"properties" : {
"channel" : {
"description" : "The channel performing the blind transfer" ,
"required" : true ,
"type" : "Channel"
} ,
2014-08-20 13:06:33 +00:00
"replace_channel" : {
"description" : "The channel that is replacing transferer when the transferee(s) can not be transferred directly" ,
"required" : false ,
"type" : "Channel"
} ,
2014-08-07 15:30:19 +00:00
"transferee" : {
"description" : "The channel that is being transferred" ,
"required" : false ,
"type" : "Channel"
} ,
2014-02-01 16:26:57 +00:00
"exten" : {
"description" : "The extension transferred to" ,
"required" : true ,
"type" : "string"
} ,
"context" : {
"description" : "The context transferred to" ,
"required" : true ,
"type" : "string"
} ,
"result" : {
"description" : "The result of the transfer attempt" ,
"required" : true ,
"type" : "string"
} ,
"is_external" : {
"description" : "Whether the transfer was externally initiated or not" ,
"required" : true ,
"type" : "boolean"
} ,
"bridge" : {
"description" : "The bridge being transferred" ,
"type" : "Bridge"
}
}
} ,
"BridgeAttendedTransfer" : {
"id" : "BridgeAttendedTransfer" ,
"description" : "Notification that an attended transfer has occurred." ,
"properties" : {
"transferer_first_leg" : {
"description" : "First leg of the transferer" ,
"required" : true ,
"type" : "Channel"
} ,
"transferer_second_leg" : {
"description" : "Second leg of the transferer" ,
"required" : true ,
"type" : "Channel"
} ,
2014-08-07 15:30:19 +00:00
"replace_channel" : {
"description" : "The channel that is replacing transferer_first_leg in the swap" ,
"required" : false ,
"type" : "Channel"
} ,
"transferee" : {
"description" : "The channel that is being transferred" ,
"required" : false ,
"type" : "Channel"
} ,
"transfer_target" : {
"description" : "The channel that is being transferred to" ,
"required" : false ,
"type" : "Channel"
} ,
2014-02-01 16:26:57 +00:00
"result" : {
"description" : "The result of the transfer attempt" ,
"required" : true ,
"type" : "string"
} ,
"is_external" : {
"description" : "Whether the transfer was externally initiated or not" ,
"required" : true ,
"type" : "boolean"
} ,
"transferer_first_leg_bridge" : {
"description" : "Bridge the transferer first leg is in" ,
"type" : "Bridge"
} ,
"transferer_second_leg_bridge" : {
"description" : "Bridge the transferer second leg is in" ,
"type" : "Bridge"
} ,
"destination_type" : {
"description" : "How the transfer was accomplished" ,
"required" : true ,
"type" : "string"
} ,
"destination_bridge" : {
"description" : "Bridge that survived the merge result" ,
"type" : "string"
} ,
"destination_application" : {
"description" : "Application that has been transferred into" ,
"type" : "string"
} ,
"destination_link_first_leg" : {
"description" : "First leg of a link transfer result" ,
"type" : "Channel"
} ,
"destination_link_second_leg" : {
"description" : "Second leg of a link transfer result" ,
"type" : "Channel"
} ,
"destination_threeway_channel" : {
"description" : "Transferer channel that survived the threeway result" ,
"type" : "Channel"
} ,
"destination_threeway_bridge" : {
"description" : "Bridge that survived the threeway result" ,
"type" : "Bridge"
}
}
} ,
2013-05-10 13:13:06 +00:00
"ChannelCreated" : {
"id" : "ChannelCreated" ,
"description" : "Notification that a channel has been created." ,
2013-04-22 14:58:53 +00:00
"properties" : {
2013-05-10 13:13:06 +00:00
"channel" : {
"required" : true ,
"type" : "Channel"
2013-04-22 14:58:53 +00:00
}
}
} ,
2013-05-10 13:13:06 +00:00
"ChannelDestroyed" : {
"id" : "ChannelDestroyed" ,
"description" : "Notification that a channel has been destroyed." ,
2013-04-22 14:58:53 +00:00
"properties" : {
2013-05-10 13:13:06 +00:00
"cause" : {
"required" : true ,
"description" : "Integer representation of the cause of the hangup" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"type" : "int"
2013-05-10 13:13:06 +00:00
} ,
"cause_txt" : {
"required" : true ,
"description" : "Text representation of the cause of the hangup" ,
"type" : "string"
2013-04-22 14:58:53 +00:00
} ,
"channel" : {
2013-05-10 13:13:06 +00:00
"required" : true ,
2013-04-22 14:58:53 +00:00
"type" : "Channel"
}
}
} ,
2013-05-21 18:00:22 +00:00
"ChannelEnteredBridge" : {
"id" : "ChannelEnteredBridge" ,
"description" : "Notification that a channel has entered a bridge." ,
"properties" : {
"bridge" : {
"required" : true ,
"type" : "Bridge"
} ,
"channel" : {
"type" : "Channel"
}
}
} ,
"ChannelLeftBridge" : {
"id" : "ChannelLeftBridge" ,
"description" : "Notification that a channel has left a bridge." ,
"properties" : {
"bridge" : {
"required" : true ,
"type" : "Bridge"
} ,
"channel" : {
"required" : true ,
"type" : "Channel"
}
}
} ,
2013-04-22 14:58:53 +00:00
"ChannelStateChange" : {
"id" : "ChannelStateChange" ,
"description" : "Notification of a channel's state change." ,
"properties" : {
2013-05-10 13:13:06 +00:00
"channel" : {
"required" : true ,
2013-04-22 14:58:53 +00:00
"type" : "Channel"
}
}
} ,
2013-05-10 13:13:06 +00:00
"ChannelDtmfReceived" : {
"id" : "ChannelDtmfReceived" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"description" : "DTMF received on a channel.\n\nThis event is sent when the DTMF ends. There is no notification about the start of DTMF" ,
2013-04-22 14:58:53 +00:00
"properties" : {
"digit" : {
2013-05-10 13:13:06 +00:00
"required" : true ,
2013-04-22 14:58:53 +00:00
"type" : "string" ,
"description" : "DTMF digit received (0-9, A-E, # or *)"
} ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"duration_ms" : {
"required" : true ,
"type" : "int" ,
"description" : "Number of milliseconds DTMF was received"
} ,
2013-04-22 14:58:53 +00:00
"channel" : {
2013-05-10 13:13:06 +00:00
"required" : true ,
2013-04-22 14:58:53 +00:00
"type" : "Channel" ,
"description" : "The channel on which DTMF was received"
}
}
} ,
2013-05-10 13:13:06 +00:00
"ChannelDialplan" : {
"id" : "ChannelDialplan" ,
"description" : "Channel changed location in the dialplan." ,
"properties" : {
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"channel" : {
2013-05-10 13:13:06 +00:00
"required" : true ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"type" : "Channel" ,
"description" : "The channel that changed dialplan location."
2013-05-10 13:13:06 +00:00
} ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"dialplan_app" : {
2013-05-10 13:13:06 +00:00
"required" : true ,
"type" : "string" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"description" : "The application about to be executed."
2013-05-10 13:13:06 +00:00
} ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"dialplan_app_data" : {
2013-05-10 13:13:06 +00:00
"required" : true ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"type" : "string" ,
"description" : "The data to be passed to the application."
2013-05-10 13:13:06 +00:00
}
}
} ,
"ChannelCallerId" : {
"id" : "ChannelCallerId" ,
"description" : "Channel changed Caller ID." ,
"properties" : {
"caller_presentation" : {
"required" : true ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"type" : "int" ,
2013-05-10 13:13:06 +00:00
"description" : "The integer representation of the Caller Presentation value."
} ,
"caller_presentation_txt" : {
"required" : true ,
"type" : "string" ,
"description" : "The text representation of the Caller Presentation value."
} ,
"channel" : {
"required" : true ,
"type" : "Channel" ,
"description" : "The channel that changed Caller ID."
}
}
} ,
"ChannelUserevent" : {
"id" : "ChannelUserevent" ,
"description" : "User-generated event with additional user-defined fields in the object." ,
"properties" : {
"eventname" : {
"required" : true ,
"type" : "string" ,
"description" : "The name of the user event."
} ,
"channel" : {
2014-05-22 16:09:51 +00:00
"required" : false ,
2013-05-10 13:13:06 +00:00
"type" : "Channel" ,
2014-05-22 16:09:51 +00:00
"description" : "A channel that is signaled with the user event."
} ,
"bridge" : {
"required" : false ,
"type" : "Bridge" ,
"description" : "A bridge that is signaled with the user event."
} ,
"endpoint" : {
"required" : false ,
"type" : "Endpoint" ,
"description" : "A endpoint that is signaled with the user event."
2013-10-04 16:01:48 +00:00
} ,
"userevent" : {
"required" : true ,
"type" : "object" ,
"description" : "Custom Userevent data"
2013-05-10 13:13:06 +00:00
}
}
} ,
"ChannelHangupRequest" : {
"id" : "ChannelHangupRequest" ,
"description" : "A hangup was requested on the channel." ,
"properties" : {
"cause" : {
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"type" : "int" ,
2013-05-10 13:13:06 +00:00
"description" : "Integer representation of the cause of the hangup."
} ,
"soft" : {
"type" : "boolean" ,
"description" : "Whether the hangup request was a soft hangup request."
} ,
"channel" : {
"required" : true ,
"type" : "Channel" ,
"description" : "The channel on which the hangup was requested."
}
}
} ,
"ChannelVarset" : {
"id" : "ChannelVarset" ,
"description" : "Channel variable changed." ,
"properties" : {
"variable" : {
"required" : true ,
"type" : "string" ,
"description" : "The variable that changed."
} ,
"value" : {
"required" : true ,
"type" : "string" ,
"description" : "The new value of the variable."
} ,
"channel" : {
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"required" : false ,
2013-05-10 13:13:06 +00:00
"type" : "Channel" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
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
2013-07-03 16:32:41 +00:00
"description" : "The channel on which the variable was set.\n\nIf missing, the variable is a global variable."
2013-05-10 13:13:06 +00:00
}
}
} ,
2015-04-07 15:22:42 +00:00
"ChannelHold" : {
"id" : "ChannelHold" ,
"description" : "A channel initiated a media hold." ,
"properties" : {
"channel" : {
"required" : true ,
"type" : "Channel" ,
"description" : "The channel that initiated the hold event."
2015-04-10 14:56:05 +00:00
} ,
"musicclass" : {
"required" : false ,
"type" : "string" ,
"description" : "The music on hold class that the initiator requested."
2015-04-07 15:22:42 +00:00
}
}
} ,
"ChannelUnhold" : {
"id" : "ChannelUnhold" ,
"description" : "A channel initiated a media unhold." ,
"properties" : {
"channel" : {
"required" : true ,
"type" : "Channel" ,
"description" : "The channel that initiated the unhold event."
}
}
} ,
2024-07-18 12:13:25 +02:00
"ChannelToneDetected" : {
"id" : "ChannelToneDetected" ,
"description" : "Tone was detected on the channel." ,
"properties" : {
"channel" : {
"required" : true ,
"type" : "Channel" ,
"description" : "The channel the tone was detected on."
}
}
} ,
2014-05-30 12:42:57 +00:00
"ChannelTalkingStarted" : {
"id" : "ChannelTalkingStarted" ,
"description" : "Talking was detected on the channel." ,
"properties" : {
"channel" : {
"required" : true ,
"type" : "Channel" ,
"description" : "The channel on which talking started."
}
}
} ,
"ChannelTalkingFinished" : {
"id" : "ChannelTalkingFinished" ,
"description" : "Talking is no longer detected on the channel." ,
"properties" : {
"channel" : {
"required" : true ,
"type" : "Channel" ,
"description" : "The channel on which talking completed."
} ,
"duration" : {
"required" : true ,
"type" : "int" ,
"description" : "The length of time, in milliseconds, that talking was detected on the channel"
}
}
} ,
2015-09-03 21:19:21 -05:00
"ContactStatusChange" : {
"id" : "ContactStatusChange" ,
"description" : "The state of a contact on an endpoint has changed." ,
"properties" : {
"endpoint" : {
"required" : true ,
"type" : "Endpoint"
} ,
"contact_info" : {
"required" : true ,
"type" : "ContactInfo"
}
}
} ,
"PeerStatusChange" : {
"id" : "PeerStatusChange" ,
"description" : "The state of a peer associated with an endpoint has changed." ,
"properties" : {
"endpoint" : {
"required" : true ,
"type" : "Endpoint"
} ,
"peer" : {
"required" : true ,
"type" : "Peer"
}
}
} ,
2013-10-04 16:01:48 +00:00
"EndpointStateChange" : {
"id" : "EndpointStateChange" ,
"description" : "Endpoint state changed." ,
"properties" : {
"endpoint" : {
"required" : true ,
"type" : "Endpoint"
}
}
} ,
2013-12-14 17:19:41 +00:00
"Dial" : {
"id" : "Dial" ,
"description" : "Dialing state has changed." ,
"properties" : {
"caller" : {
"required" : false ,
"type" : "Channel" ,
"description" : "The calling channel."
} ,
"peer" : {
"required" : true ,
"type" : "Channel" ,
"description" : "The dialed channel."
} ,
"forward" : {
"required" : false ,
"type" : "string" ,
"description" : "Forwarding target requested by the original dialed channel."
} ,
"forwarded" : {
"required" : false ,
"type" : "Channel" ,
"description" : "Channel that the caller has been forwarded to."
} ,
"dialstring" : {
"required" : false ,
"type" : "string" ,
"description" : "The dial string for calling the peer channel."
} ,
"dialstatus" : {
"required" : true ,
"type" : "string" ,
"description" : "Current status of the dialing attempt to the peer."
}
}
} ,
2013-04-22 14:58:53 +00:00
"StasisEnd" : {
"id" : "StasisEnd" ,
2013-11-12 15:27:00 +00:00
"description" : "Notification that a channel has left a Stasis application." ,
2013-04-22 14:58:53 +00:00
"properties" : {
2013-05-10 13:13:06 +00:00
"channel" : {
"required" : true ,
2013-04-22 14:58:53 +00:00
"type" : "Channel"
}
}
} ,
"StasisStart" : {
"id" : "StasisStart" ,
2013-11-12 15:27:00 +00:00
"description" : "Notification that a channel has entered a Stasis application." ,
2013-04-22 14:58:53 +00:00
"properties" : {
"args" : {
2013-05-10 13:13:06 +00:00
"required" : true ,
2013-04-22 14:58:53 +00:00
"type" : "List[string]" ,
"description" : "Arguments to the application"
} ,
2013-05-10 13:13:06 +00:00
"channel" : {
"required" : true ,
2013-04-22 14:58:53 +00:00
"type" : "Channel"
2014-08-07 15:30:19 +00:00
} ,
"replace_channel" : {
"required" : false ,
"type" : "Channel"
2013-04-22 14:58:53 +00:00
}
}
Multiple revisions 420089-420090,420097
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
This patch adds the ability to send and receive text messages from various
technology stacks in Asterisk through ARI. This includes chan_sip (sip),
res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There
Both forms are available for message technologies that allow for arbitrary
destinations, such as chan_sip.
Inbound messages can now be received over ARI as well. An ARI application that
subscribes to endpoints will receive messages from those endpoints:
{
"type": "TextMessageReceived",
"timestamp": "2014-07-12T22:53:13.494-0500",
"endpoint": {
"technology": "PJSIP",
"resource": "alice",
"state": "online",
"channel_ids": []
},
"message": {
"from": "\"alice\" <sip:alice@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
The above was made possible due to some rather major changes in the message
core. This includes (but is not limited to):
- Users of the message API can now register message handlers. A handler has
two callbacks: one to determine if the handler has a destination for the
message, and another to handle it.
- All dialplan functionality of handling a message was moved into a message
handler provided by the message API.
- Messages can now have the technology/endpoint associated with them.
Various other properties are also now more easily accessible.
- A number of ao2 containers that weren't really needed were replaced with
vectors. Iteration over ao2_containers is expensive and pointless when
the lifetime of things is well defined and the number of things is very
small.
res_stasis now has a new file that makes up its structure, messaging. The
messaging functionality implements a message handler, and passes received
messages that match an interested endpoint over to the app for processing.
Note that inadvertently while testing this, I reproduced ASTERISK-23969.
res_pjsip_messaging was incorrectly parsing out the 'to' field, such that
arbitrary SIP URIs mangled the endpoint lookup. This patch includes the
fix for that as well.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-05 21:44:09 +00:00
} ,
"TextMessageReceived" : {
"id" : "TextMessageReceived" ,
"description" : "A text message was received from an endpoint." ,
"properties" : {
"message" : {
"required" : true ,
"type" : "TextMessage"
} ,
"endpoint" : {
"required" : false ,
"type" : "Endpoint"
}
}
2014-12-08 16:24:36 +00:00
} ,
"ChannelConnectedLine" : {
"id" : "ChannelConnectedLine" ,
"description" : "Channel changed Connected Line." ,
"properties" : {
"channel" : {
"required" : true ,
"type" : "Channel" ,
"description" : "The channel whose connected line has changed."
}
}
2024-06-15 16:01:58 +08:00
} ,
"ChannelTransfer" : {
"id" : "ChannelTransfer" ,
"description" : "transfer on a channel." ,
"properties" : {
"state" : {
"required" : false ,
"type" : "string" ,
"description" : "Transfer State"
} ,
"refer_to" : {
"required" : true ,
"type" : "ReferTo" ,
"description" : "Refer-To information with optionally both affected channels"
} ,
"referred_by" : {
"required" : true ,
"type" : "ReferredBy" ,
"description" : "Referred-By SIP Header according rfc3892"
}
}
} ,
"ReferTo" : {
"id" : "ReferTo" ,
"description" : "transfer destination requested by transferee" ,
"properties" : {
"requested_destination" : {
"required" : true ,
"type" : "RequiredDestination"
} ,
"destination_channel" : {
"required" : false ,
"type" : "Channel" ,
"description" : "The Channel Object, that is to be replaced"
} ,
"connected_channel" : {
"required" : false ,
"type" : "Channel" ,
"description" : "Channel, connected to the to be replaced channel"
} ,
"bridge" : {
"required" : false ,
"type" : "Bridge" ,
"description" : "Bridge connecting both destination channels"
}
}
} ,
"ReferredBy" : {
"id" : "ReferredBy" ,
"description" : "transfer destination requested by transferee" ,
"properties" : {
"source_channel" : {
"required" : true ,
"type" : "Channel" ,
"description" : "The channel on which the refer was received"
} ,
"connected_channel" : {
"required" : false ,
"type" : "Channel" ,
"description" : "Channel, Connected to the channel, receiving the transfer request on."
} ,
"bridge" : {
"required" : false ,
"type" : "Bridge" ,
"description" : "Bridge connecting both Channels"
}
}
} ,
"RequiredDestination" : {
"id" : "RequiredDestination" ,
"description" : "Information about the requested destination" ,
"properties" : {
"protocol_id" : {
"required" : false ,
"type" : "string" ,
"description" : "the requested protocol-id by the referee in case of SIP channel, this is a SIP Call ID, Mutually exclusive to destination"
} ,
"destination" : {
"required" : false ,
"type" : "string" ,
"description" : "Destination User Part. Only for Blind transfer. Mutually exclusive to protocol_id"
} ,
"additional_protocol_params" : {
"required" : false ,
"type" : "List[AdditionalParam]" ,
"description" : "List of additional protocol specific information"
}
}
} ,
"AdditionalParam" : {
"id" : "AdditionalParam" ,
"description" : "Protocol specific additional parameter" ,
"properties" : {
"parameter_name" : {
"required" : true ,
"type" : "string" ,
"description" : "Name of the parameter"
} ,
"parameter_value" : {
"required" : true ,
"type" : "string" ,
"description" : "Value of the parameter"
}
}
2025-03-12 15:58:51 -06:00
} ,
"RESTHeader" : {
"id" : "RESTHeader" ,
"description" : "REST over Websocket header" ,
"properties" : {
"name" : {
"type" : "string" ,
"description" : "Header name" ,
"required" : true
} ,
"value" : {
"required" : true ,
"type" : "string" ,
"description" : "Header value"
}
}
} ,
"RESTQueryStringParameter" : {
"id" : "RESTQueryStringParameter" ,
"description" : "REST over Websocket Query String Parameter" ,
"properties" : {
"name" : {
"type" : "string" ,
"description" : "Parameter name" ,
"required" : true
} ,
"value" : {
"required" : true ,
"type" : "string" ,
"description" : "Parameter value"
}
}
} ,
"RESTRequest" : {
"id" : "RESTRequest" ,
"description" : "REST over Websocket Request." ,
"properties" : {
"type" : {
"type" : "string" ,
"description" : "Message type. Must be 'RESTRequest'" ,
"required" : true
} ,
"transaction_id" : {
"type" : "string" ,
"description" : "Opaque transaction id. Can be any valid string. Will be returned in any response to this request." ,
"required" : true
} ,
"request_id" : {
"type" : "string" ,
"description" : "Opaque request id. Can be any valid string. Will be returned in any response to this request." ,
"required" : true
} ,
"method" : {
"required" : true ,
"type" : "string" ,
"description" : "HTTP method (GET, PUT, POST, DELETE, etc.)"
} ,
"uri" : {
"required" : true ,
"type" : "string" ,
"description" : "Resource URI with optional query string parameters."
} ,
"content_type" : {
"required" : false ,
"type" : "string" ,
"description" : "The Content-Type of the message body."
} ,
"query_strings" : {
"required" : false ,
"type" : "List[RESTQueryStringParameter]" ,
"description" : "Request query string parameters."
} ,
"message_body" : {
"required" : false ,
"type" : "string" ,
"description" : "Request message body. Only content types application/json and application/x-www-form-urlencoded are supported."
}
}
} ,
"RESTResponse" : {
"id" : "RESTResponse" ,
"description" : "REST over Websocket Response." ,
"properties" : {
"transaction_id" : {
"type" : "string" ,
"description" : "Opaque transaction id. Will be whatever was specified on the original request." ,
"required" : true
} ,
"request_id" : {
"type" : "string" ,
"description" : "Opaque request id. Will be whatever was specified on the original request." ,
"required" : true
} ,
"status_code" : {
"required" : true ,
"type" : "int" ,
"description" : "HTTP status code"
} ,
"reason_phrase" : {
"required" : true ,
"type" : "string" ,
"description" : "HTTP reason phrase"
} ,
"uri" : {
"required" : true ,
"type" : "string" ,
"description" : "Original request resource URI"
} ,
"content_type" : {
"required" : false ,
"type" : "string" ,
"description" : "The Content-Type of the message body."
} ,
"message_body" : {
"required" : false ,
"type" : "string" ,
"description" : "Response message body"
}
}
2013-04-22 14:58:53 +00:00
}
}
}
