When passing a JSON body to the 'create' channel route
it would be converted into Asterisk variables, but never
freed resulting in a memory leak.

This change makes it so that the variables are freed in
all cases.

ASTERISK-30344

Change-Id: I924dbd866a01c6073e2d6fb846ccaa27ef72d49d

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

Change-Id: I5b5cf9c9cbbe00ba8b379a8d162ac67445d39016

ASTERISK-29756

Change-Id: I2f1c1eea1c902492b77b74de9950f20ebbb7e758

Correct typos of the following word families:

identifying
structures
actcount
initializer
attributes
statement
enough
locking
declaration
userevent
provides
unregister
session
execute
searches
verification
suppressed
prepared
passwords
recipients
event
because
brief
unidentified
redundancy
character
the
module
reload
operation
backslashes
accurate
incorrect
collision
initializing
instance
interpreted
buddies
omitted
manually
requires
queries
generator
scheduler
configuration has
owner
resource
performed
masquerade
apparently
routable

ASTERISK-29714

Change-Id: I88485116d2c59b776aa2e1f8b4ce8239a21decda

When listing bridges we go through the ones present in
ARI, get their snapshot, turn it into JSON, and add it
to the payload we ultimately return.

An invisible "dial bridge" exists within ARI that would
also try to be added to this payload if the channel
"create" and "dial" routes were used. This would ultimately
fail due to invisible bridges having no snapshot
resulting in the listing of bridges failing.

This change makes it so that the listing of bridges
ignores invisible ones.

ASTERISK-29668

Change-Id: I14fa4b589b4657d1c2a5226b0f527f45a0cd370a

Fixed the external media creation handle to handle the 'data' option correctly.

ASTERISK-29629

Change-Id: I22e57fe8ebf3d3e08fb2121aa4a8a52cc62e8129

Fixed ARI external media handler to accept body parameters.

ASTERISK-29622

Change-Id: I49509c48a6cbc0fb4165bfa4f834b5e8b9ace20d

Add check that data parameter specified when audiosocket used for externalMedia.

ASTERISK-29514 #close

Change-Id: Ie562f03c5d6c3835a3631f376b3d43e75b8f9617

When handling a send_message request to a non-existing endpoint, the response's
body is overriden and not properly freed.

ASTERISK-29108

Change-Id: Ie1d3d70065f80793445b60f5e4a7eb31b4b9c5c8

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

If channelId parameters were passed in the body, the Asterisk doesn't parsing it correctly.

Fixed it to parse the channelId, other_channel_id parameter correclty.

ASTERISK-28948

Change-Id: I59b49161a94869169ee19c1ffab5afcef7026157

If parameters were passed in the body as JSON to the
create route they were not being parsed before checking
to ensure that required fields were set.

This change moves the parsing so it occurs before
checking.

ASTERISK-28940

Change-Id: I898b4c3c7ae1cde19a6840e59f498822701cf5cf

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

Fixed it to copy the entire string from the requested endpoint body except tech-prefix.

ASTERISK-28847

Change-Id: I91b5f6708a1200363f3267b847dd6a0915222c25

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

This patch fixes several issues reported by the lgtm code analysis tool:

https://lgtm.com/projects/g/asterisk/asterisk

Not all reported issues were addressed in this patch. This patch mostly fixes
confirmed reported errors, potential problematic code points, and a few other
"low hanging" warnings or recommendations found in core supported modules.
These include, but are not limited to the following:

* innapropriate stack allocation in loops
* buffer overflows
* variable declaration "hiding" another variable declaration
* comparisons results that are always the same
* ambiguously signed bit-field members
* missing header guards

Change-Id: Id4a881686605d26c94ab5409bc70fcc21efacc25

resource_events:stasis_app_message_handler() was locking the session,
then attempting to determine if the app had debug enabled which
locked the app_registry container.  res_stasis:__stasis_app_register
was locking the app_registry container then calling app_update
which caused app_handler (which locks the session) to run.
The result was a deadlock.

* Updated resource_events:stasis_app_message_handler() to determine
  if debug was set (which locks the app_registry) before obtaining the
  session lock.

* Updated res_stasis:__stasis_app_register to release the app_registry
  container lock before calling app_update (which locks the sesison).

ASTERISK-28423
Reported by Ross Beer

Change-Id: I58c69d08cb372852a63933608e4d6c3e456247b4

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

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

An earlier contributor apparently forgot to run 'make ari-stubs'
before committing after making ARI model changes.

Change-Id: I7813e5638e2821d11f4b968dc2aeab4f725190a6

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

When listing the applications the apps lock was incorrectly
locked twice instead of being locked and then unlocked.

ASTERISK-28302

Change-Id: If7d064592a9e88c0f1049214c50e02be6dabf79e

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

Testing revealed that the cache added no benefit but that it could
consume excessive memory.

Two new index related functions were created:
ast_sounds_get_index_for_file() and ast_media_index_update_for_file()
which restrict index updating to specific sound files.

The original ast_sounds_get_index() and ast_media_index_update()
calls are still available but since they no longer cache the results
internally, developers should re-use an index they may already have
instead of calling ast_sounds_get_index() repeatedly.  If information
for only a single file is needed, ast_sounds_get_index_for_file()
should be called instead of ast_sounds_get_index().

The media_index directory scan code was elimininated in favor of
using the existing ast_file_read_dirs() function.

Since there's no more cache, ast_sounds_index_init now only
registers the sounds cli commands instead of generating the
initial index and subscribing to stasis format register/unregister
messages.

"sounds" is no longer a valid target for the "module reload"
command.

Both the sounds cli commands and the sounds ari resources were
refactored to only call ast_sounds_get_index() once per invocation
and to use ast_sounds_get_index_for_file() when a specific sound
file is requested.

Change-Id: I1cef327ba1b0648d85d218b70ce469ad07f4aa8d

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

* The bridging core no longer uses the stasis cache for bridge
  snapshots.  The latest bridge snapshot is now stored on the
  ast_bridge structure itself.

* The following APIs are no longer available since the stasis cache
  is no longer used:
    ast_bridge_topic_cached()
    ast_bridge_topic_all_cached()

* A topic pool is now used for individual bridge topics.

* The ast_bridge_cache() function was removed since there's no
  longer a separate container of snapshots.

* A new function "ast_bridges()" was created to retrieve the
  container of all bridges.  Users formerly calling
  ast_bridge_cache() can use the new function to iterate over
  bridges and retrieve the latest snapshot directly from the
  bridge.

* The ast_bridge_snapshot_get_latest() function was renamed to
  ast_bridge_get_snapshot_by_uniqueid().

* A new function "ast_bridge_get_snapshot()" was created to retrieve
  the bridge snapshot directly from the bridge structure.

* The ast_bridge_topic_all() function now returns a normal topic
  not a cached one so you can't use stasis cache functions on it
  either.

* The ast_bridge_snapshot_type() stasis message now has the
  ast_bridge_snapshot_update structure as it's data.  It contains
  the last snapshot and the new one.

* cdr, cel, manager and ari have been updated to use the new
  arrangement.

Change-Id: I7049b80efa88676ce5c4666f818fa18ad1985369

When a channel snapshot was created it used to be done
from scratch, copying all data (many strings). This incurs
a cost when doing so.

This change segments the channel snapshot into different
components which can be reused if unchanged from the
previous snapshot creation, reducing the cost. In normal
cases this results in some pointers being copied with
reference count being bumped, some integers being set,
and a string or two copied. The other benefit is that it
is now possible to determine if a channel snapshot update
is redundant and thus stop it before a message is published
to stasis.

The specific segments in the channel snapshot were split up
based on whether they are changed together, how often they
are changed, and their general grouping. In practice only
1 (or 0) of the segments actually get changed in normal
operation.

Invalidation is done by setting a flag on the channel when
the segment source is changed, forcing creation of a new
segment when the channel snapshot is created.

ASTERISK-28119

Change-Id: I5d7ef3df963a88ac47bc187d73c5225c315f8423

Channels no longer use the Stasis cache for channel snapshots. Instead
they are stored in a hash table in stasis_channels which reduces the
number of Stasis messages created and allows better storage.

As a result the following APIs are no longer available since the stasis
cache is no longer used:
ast_channel_topic_cached()
ast_channel_topic_all_cached()

The ast_channel_cache_all() and ast_channel_cache_by_name() functions
now return an ao2_container of ast_channel_snapshots rather than
a container of stasis_messages therefore you can't (and don't need
to) call stasis_cache functions on it.

The ast_channel_topic_all() function now returns a normal topic not
a cached one so you can't use stasis cache functions on it either.

The ast_channel_snapshot_type() stasis message now has the
ast_channel_snapshot_update structure as it's data. It contains the
last snapshot and the new one.

ast_channel_snapshot_get_latest() still returns the latest snapshot.

The latest snapshot is now stored on the channel itself to eliminate
cache hits when Stasis messages that have the snapshot as a payload
are created.

ASTERISK-28102

Change-Id: I9334febff60a82d7c39703e49059fa3a68825786

Replace usage of ao2_container_alloc with ao2_container_alloc_hash or
ao2_container_alloc_list.  Remove ao2_container_alloc macro.

Change-Id: I0907d78bc66efc775672df37c8faad00f2f6c088

The res_ari(POST /channels/create handler) deos not check the endpoint
parameter length. And it causes core
dump.
Fixed it to check the parameter length. Also fixed memory leak.

ASTERISK-28169

Change-Id: Ibf10a9eb8a2e3a9ee1e13fbe748b2ecf955c3993

Fixed an issue that resulted in "Allocation failed" each time an ARI
request was made to start playing MOH on a bridge.

In bridge_moh_create() we were attaching the after bridge callbacks to
chan which is the ;1 channel of the unreal channel pair.  We should have
attached them to the ;2 channel which is pushed into the bridge by
ast_unreal_channel_push_to_bridge().  The callbacks are called when the
specific channel leaves the bridging system.  Since the ;1 channel is
never put into a bridge the callbacks never get called.  The callbacks
then never remove the moh_wrapper from the app_bridges_moh container.  As
a result we cannot find the channel associated with the wrapper to start
MOH because it has hungup.  This is the reason causing the reported issue.

* Rather than using after bridge callbacks to cleanup, we now have
moh_channel_thread() doing the cleanup when the channel hangs up.

* Fixed moh_channel_thread() accumulating control frames on the stasis
bridge MOH channel until MOH is stopped.  Control frames are no longer
accumulated while MOH is playing.

* Fixed channel ref counting issue.  stasis_app_bridge_moh_channel() may
or may not return a channel ref.  As a result ast_ari_bridges_start_moh()
wouldn't know it may have a channel ref to release.
stasis_app_bridge_moh_channel() will now return a ref with the channel it
returns.

* Eliminated RAII_VAR in bridge_moh_create().

ASTERISK-26094 #close

Change-Id: Ibff479e167b3320c68aaabfada7e1d0ef7bd548c