- Nov 09, 2023
-
-
Andreas Gnau authored
This reverts commit 3c8116c8. It has been a merge that has been acidentally squashed into one commit with the consequence that all history has been lost. The next commit will be a proper merge commit rectifying this.
-
- Oct 03, 2023
-
-
Our commits to the previous version have been rebased.
-
- May 22, 2022
-
-
Moritz Fain authored
This change exposes the channel driver's unique id (i.e. the Call-ID for chan_sip/chan_pjsip based channels) to ARI channel resources as `protocol_id`. ASTERISK-30027 Reported by: Moritz Fain Tested by: Moritz Fain Change-Id: I7cc6e7a9d29efe74bc27811d788dac20fe559b87
-
- Aug 02, 2021
-
-
Ben Ford authored
Bumped AMI and ARI versions for the next major Asterisk version (20). Change-Id: I2e65794f206d443178ab6895767fb53f04cc3e6a
-
- Jun 24, 2021
-
-
Andre Barbosa authored
When we try to play a list of sound files in the same Play command, we get only one PlaybackFinish event, after all sounds are played. But in the case where the Play fails (because channel is destroyed for example), Asterisk will send one PlaybackFinish event for each sound file still to be played. If the list is big, Asterisk is sending many events. This patch adds a failed state so we can understand that the play failed. On that case we don't send the event, if we still have a list of sounds to be played. When we reach the last sound, we send the PlaybackFinish with the failed state. ASTERISK-29464 #close Change-Id: I4c2e5921cc597702513af0d7c6c2c982e1798322
-
Andre Barbosa authored
When we try to play a list of sound files in the same Play command, we get only one PlaybackFinish event, after all sounds are played. But in the case where the Play fails (because channel is destroyed for example), Asterisk will send one PlaybackFinish event for each sound file still to be played. If the list is big, Asterisk is sending many events. This patch adds a failed state so we can understand that the play failed. On that case we don't send the event, if we still have a list of sounds to be played. When we reach the last sound, we send the PlaybackFinish with the failed state. ASTERISK-29464 #close Change-Id: I4c2e5921cc597702513af0d7c6c2c982e1798322
-
- Sep 10, 2020
-
-
Sungtae Kim authored
Currently, it was not possible to create bridge with video_mode single. This made hard to put the bridge in a vidoe_single mode. So, added video_single option for Bridge creation using the ARI. This allows create a bridge with video_mode single. ASTERISK-29055 Change-Id: I43e720e5c83fc75fafe10fe22808ae7f055da2ae
-
Sungtae Kim authored
Currently, it was not possible to create bridge with video_mode single. This made hard to put the bridge in a vidoe_single mode. So, added video_single option for Bridge creation using the ARI. This allows create a bridge with video_mode single. ASTERISK-29055 Change-Id: I43e720e5c83fc75fafe10fe22808ae7f055da2ae
-
- Jul 21, 2020
-
-
George Joseph authored
* Updated AMI version to 8.0.0 * Updated ARI version to 7.0.0 * Update make_ari_stubs.py to "Asterisk 19" Change-Id: I51fb38c2e29f2db785f64a8bbd5565d56bea5af5
-
- May 15, 2020
-
-
Joshua C. Colp authored
This change adds the same variable functionality that is available for originating a channel to the create call. Now when creating a channel you can specify dialplan variables to set instead of having to do another API call. ASTERISK-28896 Change-Id: If13997ba818136d7c070585504fc4164378aa992
-
- Mar 02, 2020
-
-
Kevin Harwell authored
When a text message was received any associated variable was not written to the ARI TextMessageReceived event. This occurred because Asterisk only wrote out "send" variables. However, even those "send" variables would fail ARI validation due to a TextMessageVariable formatting bug. Since it seems the TextMessageReceived event has never been able to include actual variables it was decided to remove the TextMessageVariable object type from ARI, and simply return a JSON object of key/value pairs for variables. This aligns more with how the ARI sendMessage handles variables, and other places in ARI. ASTERISK-28755 #close Change-Id: Ia6051c01a53b30cf7edef84c27df4ed4479b8b6f
-
- Jan 14, 2020
-
-
Seán C McCord authored
This commit adds support for [AudioSocket]( https://wiki.asterisk.org/wiki/display/AST/AudioSocket), a very simple bidirectional audio streaming protocol. There are both channel and application interfaces. A description of the protocol can be found on the above referenced GitHub page. A short talk about the reasons and implementation can be found on [YouTube](https://www.youtube.com/watch?v=tjduXbZZEgI), from CommCon 2019. ARI support has also been added via the existing "externalMedia" ARI functionality. The UUID is specified using the arbitrary "data" field. ASTERISK-28484 #close Change-Id: Ie866e6c4fa13178ec76f2a6971ad3590a3a588b5
-
- Jan 02, 2020
-
-
Jean Aunis authored
This patch adds a new flag "inhibitConnectedLineUpdates" to the 'addChannel' operation in the Bridges REST API. When set, this flag avoids generating COLP frames when the specified channels enter the bridge. ASTERISK-28629 Change-Id: Ib995d4f0c6106279aa448b34b042b68f0f2ca5dc
-
- Oct 18, 2019
-
-
George Joseph authored
When we created the External Media addition to ARI we created an ExternalMedia object to be returned from the channels/externalMedia REST endpoint. This object contained the channel object that was created plus local_address and local_port attributes (which are also in the Channel variables). At the time, we thought that creating an ExternalMedia object would give us more flexibility in the future but as we created the sample speech to text application, we discovered that it doesn't work so well with ARI client libraries that a) don't have the ExternalMedia object defined and/or b) can't promote the embedded channel structure to a first-class Channel object. This change causes the channels/externalMedia REST endpoint to return a Channel object (like channels/create and channels/originate) instead of the ExternalMedia object. Change-Id: If280094debd35102cf21e0a31a5e0846fec14af9
-
- Sep 10, 2019
-
-
George Joseph authored
The Channel resource has a new sub-resource "externalMedia". This allows an application to create a channel for the sole purpose of exchanging media with an external server. Once created, this channel could be placed into a bridge with existing channels to allow the external server to inject audio into the bridge or receive audio from the bridge. See https://wiki.asterisk.org/wiki/display/AST/External+Media+and+ARI for more information. Change-Id: I9618899198880b4c650354581b50c0401b58bc46
-
- Jul 29, 2019
-
-
George Joseph authored
Change-Id: I8b8ed97001446fab0c14d7c89391ee572fb29dd6
-
- Jun 27, 2019
-
-
sungtae kim authored
Currently, DELETE /ari/channels/<channelID> supports only few hangup reasons. It's good enough for simple use, but when it needs to set the detail reason, it comes challenges. Added reason_code query parameter for that. ASTERISK-28385 Change-Id: I1cf1d991ffd759d0591b347445a55f416ddc3ff2
-
- Mar 26, 2019
-
-
sungtae kim authored
It was difficult to check the channel's current application and parameters using ARI for current channels. Added app_name, app_data items to show the current application information. ASTERISK-28343 Change-Id: Ia48972b3850e5099deab0faeaaf51223a1f2f38c
-
- Mar 13, 2019
-
-
sungtae kim authored
Added ARI resource for channel statistics. GET /ari/channels/{channelId}/rtp_statistics : It returns given channel's rtp statistics detail. ASTERISK-28320 Change-Id: I4343eec070438cec13f2a4f22e7fd9e574381376
-
- Mar 11, 2019
-
-
sungtae kim authored
Changed to requirement to having timestamp for all of ARI events. The below ARI events were changed to having timestamp. PlaybackStarted, PlaybackContinuing, PlaybackFinished, RecordingStarted, RecordingFinished, RecordingFailed, ApplicationReplaced, ApplicationMoveFailed ASTERISK-28326 Change-Id: I382c2fef58f5fe107e1074869a6d05310accb41f
-
- Mar 07, 2019
-
-
Ben Ford authored
Added the ability to move between Stasis applications within Stasis. This can be done by calling 'move' in an application, providing (at minimum) the channel's id and the application to switch to. If the application is not registered or active, nothing will happen and the channel will remain in the current application, and an event will be triggered to let the application know that the move failed. The event name is "ApplicationMoveFailed", and provides the "destination" that the channel was attempting to move to, as well as the usual channel information. Optionally, a list of arguments can be passed to the function call for the receiving application. A full example of a 'move' call would look like this: client.channels.move(channelId, app, appArgs) The control object used to control the channel in Stasis can now switch which application it belongs to, rather than belonging to one Stasis application for its lifetime. This allows us to use the same control object instead of having to tear down the current one and create another. ASTERISK-28267 #close Change-Id: I43d12b10045a98a8d42541889b85695be26f288a
-
- Mar 03, 2019
-
-
sungtae kim authored
This small feature will help to checking the bridge's status to figure out which bridge is in old/zombie or not. Also added detail items for the 'bridge show *' cli to provide more detail info. And added creation item to the ARI as well. ASTERISK-28279 Change-Id: I460238c488eca4d216b9176576211cb03286e040
-
- Feb 20, 2019
-
-
Kevin Harwell authored
Event type filtering is now enabled, and configurable per application. An app is now able to specify which events are sent to the application by configuring an allowed and/or disallowed list(s). This can be done by issuing the following: PUT /applications/{applicationName}/eventFilter And then enumerating the allowed/disallowed event types as a body parameter. ASTERISK-28106 Change-Id: I9671ba1fcdb3b6c830b553d4c5365aed5d588d5b
-
- Jan 30, 2019
-
-
sungtae kim authored
Added ARI resource. GET /ari/asterisk/ping : It returns "pong" message with timestamp and asterisk id. It would be useful for simple heath check. Change-Id: I8d24e1dcc96f60f73437c68d9463ed746f688b29
-
- Dec 11, 2018
-
-
Sebastian Damm authored
The ARI DELETE /channels command takes a "reason" parameter Previously, there were only five reasons implemented This patch adds more reasons to choose from for more complex setups ASTERISK-28198 #close Change-Id: I85996f1076c9946d65c778413f040a845a90fecc
-
- Jul 18, 2018
-
-
Joshua Colp authored
ARI goes from 3.0.0 to 4.0.0 Change-Id: I0649fa34926dc4fc89a166f1d2e3bbd965ef9ebe
-
- Jan 22, 2018
-
-
Corey Farrell authored
I've audited all modules that include any header which includes asterisk/optional_api.h. All modules which use OPTIONAL_API now declare those dependencies in AST_MODULE_INFO using requires or optional_modules as appropriate. In addition ARI dependency declarations have been reworked. Instead of declaring additional required modules in res/ari/resource_*.c we now add them to an optional array "requiresModules" in api-docs for each module. This allows the AST_MODULE_INFO dependencies to include those missing modules. Change-Id: Ia0c70571f5566784f63605e78e1ceccb4f79c606
-
- Dec 11, 2017
-
-
Kevin Harwell authored
A couple of places were setting the status to "UNKNOWN" when qualifies were being disabled. Instead this should be set to the "CREATED" status that represents when a contact is given (uri available), but the qualify frequency is set to zero so we don't know the status. This patch updates the relevant places with "CREATED". It also updates the "CREATED" status description (value shown in CLI/AMI/ARI output) to a value of "NonQualified"/"NonQual" as this description is hopefully less confusing. ASTERISK-27467 Change-Id: Id67509d25df92a72eb3683720ad2a95a27b50c89
-
- Oct 11, 2017
-
-
Seán C McCord authored
Add bridge_features structure to bridge creation. Specifically, this implements mute and DTMF suppression, but others should be able to be easily added to the same structure. ASTERISK-27322 #close Reported by: Darren Sessions Sponsored by: AVOXI Change-Id: Id4002adfb65c9a8027ee9e1a5f477e0f01cf9d61
-
- Sep 28, 2017
-
-
Joshua Colp authored
This change adds 'video_sfu' as a requested bridge type when creating a bridge. By specifying this a mixing type bridge is created that exchanges video in an SFU fashion. Change-Id: I2ada47cf5f3fc176518b647c0b4aa39d55339606
-
- Jul 20, 2017
-
-
George Joseph authored
AMI goes from 3.2.0 to 4.0.0 ARI goes from 2.0.0 to 3.0.0 Copied UPGRADE.txt -> UPGRADE-15.txt Created new UPGRADE.txt Removed a log file that was accidentally checked in a while ago Change-Id: I1c794f910038459b13e16f9c3a12c44e56f142f7
-
- Nov 18, 2016
-
-
Mark Michelson authored
In order to not have version number overlap between different versions of Asterisk, each new major version of Asterisk will mean we also bump the ARI major version number. This particular change does NOT introduce any known breaking changes to ARI. For discussion relating to this topice, see: http://lists.digium.com/pipermail/asterisk-dev/2016-November/075964.html Change-Id: I712ee0df177a8fe1252da2bc029705268b97b665
-
- Nov 14, 2016
-
-
Matt Jordan authored
In multi-party bridges, Asterisk currently supports two video modes: * Follow the talker, in which the speaker with the most energy is shown to all participants but the speaker, and the speaker sees the previous video source * Explicitly set video sources, in which all participants see a locked video source Prior to this patch, ARI had no ability to manipulate the video source. This isn't important for two-party bridges, in which Asterisk merely relays the video between the participants. However, in a multi-party bridge, it can be advantageous to allow an external application to manipulate the video source. This patch provides two new routes to accomplish this: (1) setVideoSource: POST /bridges/{bridgeId}/videoSource/{channelId} Sets a video source to an explicit channel (2) clearVideoSource: DELETE /bridges/{bridgeId}/videoSource Removes any explicit video source, and sets the video mode to talk detection ASTERISK-26595 #close Change-Id: I98e455d5bffc08ea5e8d6b84ccaf063c714e6621
-
Sebastien Duthil authored
This works the same as for AMI manager variables. Set "channelvars=foo,bar" in your ari.conf general section, and then the channel variables "foo" and "bar" (along with their values), will appear in every Stasis websocket channel event. ASTERISK-26492 #close patches: ari_vars.diff submitted by Mark Michelson Change-Id: I5609ba239259577c0948645df776d7f3bc864229
-
- Oct 20, 2016
-
-
Mark Michelson authored
This is similar to what is done for origination, but for the 14 and up channel creation method. When attempting to create a channel, if a channel ID is specified and a channel already exists with that ID, then a 409 is returned. Change-Id: I77f9253278c6947939c418073b6b31065489187c
-
Mark Michelson authored
ARI and AMI allow for an explicit channel ID to be specified when originating channels. Unfortunately, there is nothing in place to prevent someone from using the same ID for multiple channels. Further complicating things, adding ID validation to channel allocation makes it impossible for ARI to discern why channel allocation failed, resulting in a vague error code being returned. The fix for this is to institute a new method for channel errors to be discerned. The method mirrors errno, in that when an error occurs, the caller can consult the channel errno value to determine what the error was. This initial iteration of the feature only introduces "unknown" and "channel ID exists" errors. However, it's possible to add more errors as needed. ARI uses this feature to determine why channel allocation failed and can return a 409 error during origination to show that a channel with the given ID already exists. ASTERISK-26421 Change-Id: Ibba7ae68842dab6df0c2e9c45559208bc89d3d06
-
- Oct 17, 2016
-
-
Matt Jordan authored
This patch adds the Asterisk EID field to all outgoing ARI events. Because this field should be added to all events as they are transmitted, it is appended to the JSON message just prior to it being handed off to the application message handler. This makes it somewhat resilient to both new events being added to ARI, as well as other potential event transport mechanisms. ASTERISK-26470 #close Change-Id: Ieff0ecc24464e83f3f44e9c3e7bd9a5d70b87a1d
-
- Aug 31, 2016
-
-
Jean Aunis authored
In ARI, the channels API allows to hangup a channel with a hangup reason. This commit adds a new reason "answered_elsewhere". When using a SIP channel, this will eventually allow Asterisk to add a proper "Reason" header to a CANCEL message. ASTERISK-26321 Change-Id: Ia97675bd4acd6a7f58eb467953dfb94559f6583d
-
- Jul 24, 2016
-
-
Joshua Colp authored
New functionality has been added so the version has been bumped to one over the 13 version. Change-Id: I5d30077f62640c0ac83599b4e9a9b657bf184f69
-
- Jun 09, 2016
-
-
Mark Michelson authored
ARI was recently outfitted with operations to create and dial channels. This leads to the ability to try funny stuff. You could create a channel and then immediately try to play back media on it. You could create a channel, dial it, and while it is ringing attempt to make it continue in the dialplan. This commit attempts to fix this by adding a channel state check to operations that should not be able to operate on outbound channels that have not yet answered. If a channel is in an invalid state, we will send a 412 response. ASTERISK-26047 #close Reported by Mark Michelson Change-Id: I2ca51bf9ef2b44a1dc5a73f2d2de35c62c37dfd8
-