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

As they're not actively used, they only grow stale. The moduleinfo field itself
is kept in Asterisk 13/15 for ABI compatibility.

ASTERISK-28046 #close

Change-Id: I8df66a7007f807840414bb348511a8c14c05a9fc

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

Change-Id: I873c1c6d00f447269bd841494459efccdd2c19c0

Remove nearly all use of regex from ACO users.  Still remaining:
* app_confbridge has a legitamate use of option name regex.
* ast_sorcery_object_fields_register is implemented with regex, all
  callers use simple prefix based regex.  I haven't decided the best
  way to fix this in both 13/15 and master.

Change-Id: Ib5ed478218d8a661ace4d2eaaea98b59a897974b

The patch for ASTERISK_24560 inverted a test checking if the bridge name
is being updated to a different name.

* Fix the test to return "Changing bridge name is not implemented" when
someone attempts to change the bridge name.

ASTERISK-27445

Change-Id: I4b70bf08b0e02e016108b077ff75b345dec12fc9

When stasis_app_message_handler needs to queue a message for a later
connection it needs to bump the message reference so it doesn't get
freed when the caller releases it's reference.

Change-Id: I82696df8fe723b3365c15c3f7089501da8daa892

When (v)asprintf() fails, the state of the allocated buffer is undefined.
The library had better not leave an allocated buffer as a result or no one
will know to free it.  The most likely way it can return failure is for an
allocation failure.  If the printf conversion fails then you actually have
a threading problem which is much worse because another thread modified
the parameter values.

* Made __ast_asprintf()/__ast_vasprintf() set the returned buffer to NULL
on failure.  That is much more useful than either an uninitialized pointer
or a pointer that has already been freed.  Many uses won't have to check
for failure to ensure that the buffer won't be double freed or prevent an
attempt to free an uninitialized pointer.

* stasis.c: Fixed memory leak in multi_object_blob_to_ami() allocated by
ast_asprintf().

* ari/resource_bridges.c:ari_bridges_play_helper(): Remove assignment to
the wrong thing which is now not needed even if assigning to the right
thing.

Change-Id: Ib5252fb8850ecf0f78ed0ee2ca0796bda7e91c23

Change-Id: Id569c624c426e3b22a99936473c730592d8b83fb

This adds menuselect dependencies for modules that use symbols of other
modules.

ASTERISK-27390

Change-Id: Ia2d2849f5b87a72af7324a82edc3f283eafb5385

A comment was updated when I ran 'make ari-stubs'.

Change-Id: Ib5154ae3ad72aff53374c28ead540fe349c42175

channel_state_invalid leaked a reference to the channel snapshot any
time it was aquired.

ASTERISK-27067 #close

Change-Id: I8c653f00416b39978513c5605c4be0f03b1df29a

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

The periodic doc job does a make ari-stubs and checks that
there are no changes before generating the docs.  Since I changed
the mustache template (and the generated code directly) recently
and forgot to regenerate the stubs, the doc job thinks they're out
of date.

Change-Id: I94b97035311eccf52b0101b8590223265a7881d4

The 'ari set debug' command has been enhanced to accept 'all' as an
application name.  This allows dumping of all apps even if an app
hasn't registered yet.  To accomplish this, a new global_debug global
variable was added to res/stasis/app.c and new APIs were added to
set and query the value.

'ari set debug' now displays requests and responses as well as events.
This required refactoring the existing debug code.

* The implementation for 'ari set debug' was moved from stasis/cli.{c,h}
  to ari/cli.{c,h}, and stasis/cli.{c,h} were deleted.
* In order to print the body of incoming requests even if a request
  failed, the consumption of the body was moved from the ari stubs
  to ast_ari_callback in res_ari.c and the moustache templates were
  then regenerated.  The body is now passed to ast_ari_invoke and then
  on to the handlers.  This results in code savings since that template
  was inserted multiple times into all the stubs.

An additional change was made to the ao2_str_container implementation
to add partial key searching and a sort function.  The existing cli
code assumed it was already there when it wasn't so the tab completion
was never working.

Change-Id: Ief936f747ce47f1fb14035fbe61152cf766406bf
(cherry picked from commit 1d890874)

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 patch adds three new CLI commands:
 - ari show apps: list the registered ARI applications
 - ari show app: show detailed information about an ARI application
 - ari set debug: dump events being sent to an ARI application

Note that while these CLI commands live in the res_stasis module, we use
the 'ari' family for these commands. This was done as most users of
Asterisk aren't aware of the semantic differences between ARI and
res_stasis, and some 'ari' CLI commands already exist.

ASTERISK-26488 #close

Change-Id: I51ad6ff0cabee0d69db06858c13f18b1c513c9f5

ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.

Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename

This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled.  This variable was only used in lock.c so it
is now initialized in that file only.

ASTERISK-26480 #close

Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966

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

ASTERISK-26470

Change-Id: I9c386f7a1c7d969161b28f189eb6298bbc5b7541

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

This file was out of sync with the current ARI definitions.

Change-Id: Ie7cb7d6d3c2eeb9cc9d683ca87b43b117e713d0a

* We weren't properly subscribing to the channel and it's originator
  on create.
* We weren't doing a publish_dial after calling ast_call on dial.
* We weren't calling depart_bridge when a channel left the dial bridge.

The first 2 issues were causing events to not be generated and the third
was actually causing channels to not get properly destroyed when hung up.

Together these 3 issues were causing the new
rest_apichannels/create_dial_bridge tests to fail.

As a result of the fixes, the cdr state machine had to be slightly
tweaked to allow bridge leave events without asserting and the tests
themselves had to be updated to account for the channels now cleaning
themselves up.

Change-Id: Ibf23abf5a62de76e82afb4461af5099c961b97d8

Announcer channels were not being destroyed because the
stasis_app_control structure that referenced them was not being
destroyed. The control structure was not being destroyed because it was
not being unlinked from its container. It was not being unlinked from
its container because the after bridge callback for the announcer
channel was not being run. The after bridge callback was not being run
because the after bridge datastore was not being removed from the
channel on destruction. The channel was not being destroyed because the
hangup that used to destroy the channel was now only reducing the
reference count to one. The reference count of the channel was only
being reduced to one because the stasis_app_control structure was
holding the final reference...

The control structure used to not keep a reference to the channel, so
that loop described above did not happen.

The solution is to manually remove the control structure from its
container when the playback on a bridge is complete.

ASTERISK-26083 #close
Reported by Joshua Colp

Change-Id: I0ddc0f64484ea0016245800b409b567dfe85cfb4

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

If you create a local channel and don't specify an originator channel
to take capabilities from, we automatically add all audio formats to
the new channel's capabilities. When we try to make the channel
compatible with another, the "best format" functions pick the best
format available, which in this case will be slin192.  While this is
great for preserving quality, it's the worst for performance and
overkill for the vast majority of applications.

In the absense of any other information, adding all formats is the
correct thing to do and it's not always possible to supply an
originator so a new parameter 'formats' has been added to the channel
create/originate functions. It's just a comma separated list of formats
to make availalble for the channel. Example: "ulaw,slin,slin16".
'formats' and 'originator' are mutually exclusive.

To facilitate determination of format names, the format name has been
added to "core show codecs".

ASTERISK-26070 #close

Change-Id: I091b23ecd41c1b4128d85028209772ee139f604b

ARI dial had been implemented using the Dial API. This made great sense
when dialing was 100% separate from bridging. However, if a channel were
to be added to a bridge during the dial attempt, there would be a
conflict between the dialing thread and the bridging thread. Each would
be attempting to read frames from the dialed channel and act on them.

The initial attempt to make the two play nice was to have the Dial API
suspend the channel in the bridge and stay in charge of the channel
until the dial was complete. The problem with this was that it was
riddled with potential race conditions. It also was not well-suited for
the case where the channel changed which bridge it was in during the
dial.

This new approach removes the use of the Dial API altogether. Instead,
the channel we are dialing is placed into an invisible ARI dialing
bridge. The bridge channel thread handles incoming frames from the
channel. If the channel is added to a real bridge, it is departed from
the invisible bridge and then added to the real bridge. Similarly, if
the channel is removed from the real bridge, it is automatically added
back to the invisible bridge if the dial attempt is still active.

This approach keeps the threading simple by always having the channel
being handled by bridge channel threads.

ASTERISK-25925

Change-Id: I7750359ddf45fcd45eaec749c5b3822de4a8ddbb