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.

Grzegorz Sluja authored 1 year ago and Yalu Zhang committed 1 year ago

Our commits to the previous version have been rebased.

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

Bumped AMI and ARI versions for the next major Asterisk version (20).

Change-Id: I2e65794f206d443178ab6895767fb53f04cc3e6a

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

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

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

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

* 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

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

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

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

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

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

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

Change-Id: I8b8ed97001446fab0c14d7c89391ee572fb29dd6

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

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

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

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

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

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

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

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

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

ARI goes from 3.0.0 to 4.0.0

Change-Id: I0649fa34926dc4fc89a166f1d2e3bbd965ef9ebe

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

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

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

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

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

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

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

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

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

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

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

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

New functionality has been added so the version has been
bumped to one over the 13 version.

Change-Id: I5d30077f62640c0ac83599b4e9a9b657bf184f69

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