This patch adds the ability to subscribe to all events. There are two possible
ways to accomplish this:
(1) On initial WebSocket connection. This patch adds a new query parameter,
    'subscribeAll'. If present and True, Asterisk will subscribe the
    applications to all ARI events.
(2) Via the applications resource. When subscribing in this manner, an ARI
    client should merely specify a blank resource name, i.e., 'channels:'
    instead of 'channels:12354'. This will subscribe the application to all
    resources of the 'channels' type.

ASTERISK-24870 #close

Change-Id: I4a943b4db24442cf28bc64b24bfd541249790ad6

This patch adds support for receiving events regarding Peer status changes
and Contact status changes. This is particularly useful in scenarios where
we are subscribed to all endpoints and channels, where we often want to know
more about the state of channel technology specific items than a single
endpoint's state.

ASTERISK-24870

Change-Id: I6137459cdc25ce27efc134ad58abf065653da4e9

An http request can be sent to get the existing Asterisk logs.

The command "curl -v -u user:pass -X GET 'http://localhost:8088
/ari/asterisk/logging'" can be run in the terminal to access the
newly implemented functionality.

* Retrieve all existing log channels

ASTERISK-25252

Change-Id: I7bb08b93e3b938c991f3f56cc5d188654768a808

An http request can be sent to create a log channel
in Asterisk.

The command "curl -v -u user:pass -X POST
'http://localhost:088/ari/asterisk/logging/mylog?
configuration=notice,warning'" can be run in the terminal
to access the newly implemented functionality for ARI.

* Ability to create log channels using ARI

ASTERISK-25252

Change-Id: I9a20e5c75716dfbb6b62fd3474faf55be20bd782

An http request can be sent to delete a log channel
in Asterisk.

The command "curl -v -u user:pass -X DELETE 'http://localhost:8088
/ari/asterisk/logging/mylog'" can be run in the terminal
to access the newly implemented functionally for ARI.

* Able to delete log channels using ARI

ASTERISK-25252

Change-Id: Id6eeb54ebcc511595f0418d586ff55914bc3aae6

An http request can be sent to rotate a specified log channel.
If the channel does not exist, an error response will be
returned.

The command "curl -v -u user:pass -X PUT 'http://localhost:8088
/ari/asterisk/logging/logChannelName/rotate'" can be run in the
terminal to access this new functionality.

* Added the ability to rotate log files through ARI

ASTERISK-25252

Change-Id: Iaefa21cbbc1b29effb33004ee3d89c977e76ab01

This patch adds support for push configuration of dynamic, i.e.,
sorcery, objects in Asterisk. It adds three new REST API calls to the
'asterisk' resource:
 * GET /asterisk/{configClass}/{objectType}/{id}: retrieve the current
   object given its ID. This returns back a list of ConfigTuples, which
   define the fields and their present values that make up the object.
 * PUT /asterisk/{configClass}/{objectType}/{id}: create or update an
   object. A body may be passed with the request that contains fields to
   populate in the object. The same format as what is retrieved using
   the GET operation is used for the body, save that we specify that the
   list of fields to update are contained in the "fields" attribute.
 * DELETE /asterisk/{configClass}/{objectType}/{id}: remove a dynamic
   object from its backing storage.

Note that the success/failure of these operations is somewhat
configuration dependent, i.e., you must be using a sorcery wizard that
supports the operation in question. If a sorcery wizard does not support
the create or delete mechanisms, then the REST API call will fail with a
403 forbidden.

ASTERISK-25238 #close

Change-Id: I28cd5c7bf6f67f8e9e437ff097f8fd171d30ff5c

An http request can be sent to reload an Asterisk module. If the
module can not be reloaded or is not already loaded, an error
response will be returned.

The command "curl -v -u user:pass -X PUT 'http://localhost:8088
/ari/asterisk/modules/{moduleName}'" (or something similar, based
on configuration) can be run in the terminal to access this new
functionality.

For more information, see:
https://wiki.asterisk.org/wiki.display/~bford/Asterisk+ARI+Resource

* Added new ARI functionality
* Asterisk modules can be reloaded through http requests

ASTERISK-25173

Change-Id: I289188bcae182b2083bdbd9ebfffd50b62f58ae1

An http request can be sent to unload an Asterisk module. If the
module can not be unloaded or is already unloaded, an error response
will be returned.

The command "curl -v -u user:pass -X DELETE 'http://localhost:8088
/ari/asterisk/modules/{moduleName}'" (or something similar, depending
on configuration) can be run in the terminal to access this new
functionality.

For more information, see:
https://wiki.asterisk.org/wiki.display/~bford/Asterisk+ARI+Resource

* Added new ARI functionality
* Asterisk modules can be unloaded through http requests

ASTERISK-25173

Change-Id: I535a95f5676deb02651522761ecbdc0b00b5ac57

An http request can be sent to load an Asterisk module. If the
module can not be loaded or is loaded already, an error response
will be returned.

The command curl -v -u user:pass -X POST 'http://localhost:8088/ari
/asterisk/modules/{moduleName}'" (or something similar, depending on
configuration) can be run in the terminal to access this new
functionality.

For more information, see:
https://wiki.asterisk.org/wiki.display/~bford/Asterisk+ARI+Resource

* Added new ARI functionality
* Asterisk modules can be loaded through http requests

ASTERISK-25173

Change-Id: I9e05d5b8c5c666ecfef341504f9edc1aa84fda33

An http request can be sent to retrieve information on a single
module, including the resource name, description, use count, status,
and support level.

The command "curl -v -u user:pass -X GET 'http://localhost:8088/ari
/asterisk/modules/{moduleName}'" (or something similar, depending on
configuration) can be run in the terminal to access this new
functionality.

For more information, see:
https://wiki.asterisk.org/wiki.display/~bford/Asterisk+ARI+Resource

* Added new ARI functionality
* Information on a single module can now be retrieved

ASTERISK-25173

Change-Id: Ibce5a94e70ecdf4e90329cf0ba66c33a62d37463

An http request can be sent to retrieve a list of all existing modules,
including the resource name, description, use count, status, and
support level.

The command "curl -v -u user:pass -X GET 'http://localhost:8088/ari/
asterisk/modules" (or something similar, depending on configuration)
can be run in the terminal to access this new functionality.

For more information, see:
https://wiki.asterisk.org/wiki.display/~bford/Asterisk+ARI+Resource

* Added new ARI functionality
* Information on modules can now be retrieved

Change-Id: I63cbbf0ec0c3544cc45ed2a588dceabe91c5e0b0

This patch updates the version of ARI to 1.7.0 to reflect the backwards
compatible changes that will be introduced in 13.4.0.

Change-Id: I6c36e6144da426412f25828a868e4df916bff60a
(cherry picked from commit 9d8a4623)

When the ChannelHold event was added, the 'musicclass' parameter was
erroneously removed. This caused the ChannelHold events to be rejected as
they failed model validation. This patch updates the Swagger schema such that
it now properly reflects the event that is being created.

Hooray for tests that catch things like this.
........

Merged revisions 434597 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434598 65c4cc65-6c06-0410-ace0-fbb531ad65f3

For some applications - such as SLA - a phone pressing hold should not behave
in the fashion that the Asterisk core would like it to. Instead, the hold
action has some application specific behaviour associated with it - such as
disconnecting the channel that initiated the hold; only playing MoH to channels
in the bridge if the channels are of a particular type, etc.

One way of accomplishing this is to use a framehook to intercept the
hold/unhold frames, raise an event, and eat the frame. Tasty. This patch
accomplishes that using a new dialplan function, HOLD_INTERCEPT.

In addition, some general cleanup of raising hold/unhold Stasis messages was
done, including removing some RAII_VAR usage.

Review: https://reviewboard.asterisk.org/r/4549/

ASTERISK-24922 #close
........

Merged revisions 434216 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434217 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Sending the following ARI commands caused Asterisk to crash if the JSON
body 'variables' object passes values of types other than strings.

POST /ari/channels
POST /ari/channels/{channelid}
PUT /ari/endpoints/sendMessage
PUT /ari/endpoints/{tech}/{resource}/sendMessage

* Eliminated RAII_VAR usage in ast_ari_channels_originate_with_id(),
ast_ari_channels_originate(), ast_ari_endpoints_send_message(), and
ast_ari_endpoints_send_message_to_endpoint().

ASTERISK-24751 #close
Reported by:  jeffrey putnam

Review: https://reviewboard.asterisk.org/r/4447/
........

Merged revisions 432404 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432405 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This change makes it so that if a channel variable is requested and it does not exist
a 404 response will be returned instead of an allocation failed response. This makes
it easier to debug and figure out what is going on for a user.

ASTERISK-24677 #close
Reported by: Joshua Colp
........

Merged revisions 432154 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432155 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.

*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.

*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
    only transfer channels to a SIP URI, i.e., you had to pass
    'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
    still supported, it is somewhat unintuitive - particularly in a world full
    of endpoints. As such, we now also support specifying the PJSIP endpoint to
    transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
    updating its Contact header. Alas, that resulted in the forwarding
    destination set by the dialplan application/ARI resource/whatever being
    rewritten with very incorrect information. Hence, we now don't bother
    updating an outgoing response if it is a 302. Since this took a looong time
    to find, some additional debug statements have been added to those modules
    that update the Contact headers.

Review: https://reviewboard.asterisk.org/r/4316/

ASTERISK-24015 #close
Reported by: Private Name

ASTERISK-24703 #close
Reported by: Matt Jordan
........

Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3

One of the canonical reasons for hanging up a channel is because the far end
failed to answer - or because someone else answered, and we want to get rid of
this channel. This patch adds the missing value to the 'reason' query parameter
for the DELETE /channels operation.

Review: https://reviewboard.asterisk.org/r/4400

ASTERISK-24745 #close
Reported by: Ben Merrills
patches:
  add_no_answer_ari_hangup_cause.diff uploaded by Ben Merrills (License 6678)
........

Merged revisions 431622 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431623 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch improves the documentation of ARI on the wiki. Specifically, it
addresses the following:
* Allowed values and allowed ranges weren't documented. This was particularly
  frustrating, as Asterisk would reject query parameters with disallowed values
  - but we didn't tell anyone what the allowed values were.
* The /play/id operation on /channels and /bridges failed to document all of
  the added media resource types.
* Documentation for creating a channel into a Stasis application failed to
  note when it occurred, and that creating a channel into Stasis conflicts with
  creating a channel into the dialplan.
* Some other minor tweaks in the mustache templates, including italicizing the
  parameter type, putting the default value on its own sub-bullet, and some
  other nicities.

Review: https://reviewboard.asterisk.org/r/4351
........

Merged revisions 431145 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431148 65c4cc65-6c06-0410-ace0-fbb531ad65f3

With this patch, the following two ARI commands

POST /channels
POST /channels/{id}/continue

Accept a new parameter, label, that can be used to continue to or originate
to a priority label in the dialplan.

Because this is adding a new parameter to ARI commands, the API version of
ARI has been bumped from 1.6.0 to 1.7.0.

This patch comes courtesy of Nir Simionovich from Greenfield Tech. Thanks!

ASTERISK-24412 #close
Reported by Nir Simionovich

Review: https://reviewboard.asterisk.org/r/4285
........

Merged revisions 430337 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430338 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The channel "language" was already part of a channel snapshot, however is was
not sent out over AMI or ARI. This patch makes it so the channel "language" is
included in the appropriate AMI or ARI events.

ASTERISK-24553 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4245/
........

Merged revisions 429204 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 429206 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429209 65c4cc65-6c06-0410-ace0-fbb531ad65f3

If an originator channel is specified when originating a channel the linked ID
of it will be applied to the newly originated outgoing channel. This allows
an association to be made between the two so it is known that the originator
has dialed the originated channel.

ASTERISK-24552 #close
Reported by: Matt Jordan

Review: https://reviewboard.asterisk.org/r/4243/
........

Merged revisions 429153 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429154 65c4cc65-6c06-0410-ace0-fbb531ad65f3

AMI/ARI are getting a few enhancements in the next release of Asterisk 13. Per
semantic versioning, that warrants a bump in the minor version number, as it
reflects a backwards compatible change. Hence, this commit.
........

Merged revisions 429091 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429092 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The AMI event is called NewConnectedLine and the ARI event is called
ChannelConnectedLine.

ASTERISK-24554 #close
Reported by Matt Jordan

Review: https://reviewboard.asterisk.org/r/4231
........

Merged revisions 429064 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429084 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Prior to the release of Swagger 1.2, the attribute 'extends' was being
promoted as a possible way to show that a particular object extends an existing
object. Instead, the Swagger specification went with the 'subTypes' attribute
in the base object. This patch removes the unsupported attribute; the object
that the offending objects proposed to extend already lists them in its
'subTypes' attribute.

ASTERISK-24300 #close
Reported by: Bradley Watkins
........

Merged revisions 423620 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 423621 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423622 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The resources.json file that defines the resource JSON files used with ARI
references a basePath of 'http://localhost:8088/ari'. This does not match what
is defined in the resource files themselves, 'http://localhost:8088/stasis'.
The correct base path is the one that includes 'ari' in the URL; this patch
updates the various resource JSON files to have the correct basePath.

ASTERISK-24339 #close
Reported by: Bradley Watkins
........

Merged revisions 423617 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 423618 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423619 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When a blind transfer occurs that is forced to create a local channel
pair to satisfy the transfer request, information about the local
channel pair is not published. This adds a field to describe that
channel to the blind transfer message struct so that this information
is conveyed properly to consumers of the blind transfer message.

This also fixes a bug in which Stasis() was unable to properly identify
the channel that was replacing an existing Stasis-controlled channel
due to a blind transfer.

Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3921/
........

Merged revisions 421537 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 421538 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421539 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This is to support the backwards compatible changes made in the next version
of Asterisk.
........

Merged revisions 420805 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 420808 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420811 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This fixes a class of issues where Stasis applications were not made
aware that their channels were being manipulated or replaced by
external entitiessuch as transfers, AMI commands, or dialplan
applications such as Bridge(). Inconsistent information such as
StasisEnd events with unknown channels as a result of masquerades has
also been corrected. To accomplish these fixes, several new fields
were added to blind and attended transfer messages as well as
StasisStart and BridgeAttendedTransfer Stasis events.

ASTERISK-23941 #close
Review: https://reviewboard.asterisk.org/r/3865/
Review: https://reviewboard.asterisk.org/r/3857/
Review: https://reviewboard.asterisk.org/r/3852/
Review: https://reviewboard.asterisk.org/r/3816/
Review: https://reviewboard.asterisk.org/r/3731/
Review: https://reviewboard.asterisk.org/r/3729/
Review: https://reviewboard.asterisk.org/r/3728/
........

Merged revisions 420325 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420338 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........
  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

........
  r419565 | mjordan | 2014-07-25 09:41:23 -0500 (Fri, 25 Jul 2014) | 21 lines
  
  ARI: report duration values in LiveRecording objects
  
  This patch adds three new fields to the LiveRecording model:
   - total_duration: the total length of the live recording
   - talking_duration: optional. The duration of talking energy that was
     detected while the recording was made.
   - silence_duration: optional. The duration of silence that was detected while
     the recording was made.
  
  These values are reported in the RecordingFinished ARI event.
  
  When a DSP is enabled on the channel during the recording - which occurs when
  the recording is created with max_silence_seconds (indicating that the user
  actually cares about how much silence is in the file), we will report the
  talking_duration and silence_duration in addition to the total_duration.
  
  Review: https://reviewboard.asterisk.org/r/3770/
  
  ASTERISK-24037 #close
  Reported by: Samuel Galarneau
........
  r419566 | mjordan | 2014-07-25 09:46:15 -0500 (Fri, 25 Jul 2014) | 1 line
  
  Update CHANGES for r419565
........

Merged revisions 419565-419566 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419567 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
    channel events
(2) It serves as the preliminary work needed for ASTERISK-23692, which allows
    for sending/receiving arbitrary out of call text messages through ARI in a
    technology agnostic fashion.

The messaging functionality described on ASTERISK-23692 requires two things:
(1) The ability to send/receive messages associated with an endpoint. This is
    relatively straight forwards with the endpoint core in Asterisk now.
(2) The ability to send/receive messages associated with a technology and an
    arbitrary technology defined URI. This is less straight forward, as
    endpoints are formed from a tech + resource pair. We don't have a
    mechanism to note that a technology that *may* have endpoints exists.

This patch provides such a mechanism, and fixes a few bugs along the way.

The first major bug this patch fixes is the forwarding of channel messages
to their respective endpoints. Prior to this patch, there were two problems:
(1) Channel caching messages weren't forwarded. Thus, the endpoints missed
    most of the interesting bits (such as channel creation, destruction, state
    changes, etc.)
(2) Channels weren't associated with their endpoint until after creation.
    This resulted in endpoints missing the channel creation message, which
    limited the usefulness of the subscription in the first place (a major use
    case being 'tell me when this endpoint has a channel'). Unfortunately,
    this meant another parameter to ast_channel_alloc. Since not all channel
    technologies support an ast_endpoint, this patch makes such a call
    optional and opts for a new function, ast_channel_alloc_with_endpoint.

When endpoints are created, they will implicitly create a technology endpoint
for their technology (if one does not already exist). A technology endpoint is
special in that it has no state, cannot have channels created for it, cannot
be created explicitly, and cannot be destroyed except on shutdown. It does,
however, have all messages from other endpoints in its technology forwarded to
it.

Combined with the bug fixes, we now have Stasis messages being properly
forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar),
where bar has a single channel associated with it and foo has two channels
associated with it. The messages would be forwarded as follows:

channel PJSIP/foo-1 --
                      \
                       --> endpoint PJSIP/foo --
                      /                         \
channel PJSIP/foo-2 --                           \
                                                  ---- > endpoint PJSIP
                                                /
channel PJSIP/bar-1 -----> endpoint PJSIP/bar --

ARI, through the applications resource, can:
 - subscribe to endpoint:PJSIP/foo and get notifications for channels
   PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo
 - subscribe to endpoint:PJSIP/bar and get notifications for channels
   PJSIP/bar-1 and endpoint PJSIP/bar
 - subscribe to endpoint:PJSIP and get notifications for channels
   PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar

Note that since endpoint PJSIP never changes, it never has events itself. It
merely provides an aggregation point for all other endpoints in its technology
(which in turn aggregate all channel messages associated with that endpoint).

This patch also adds endpoints to res_xmpp and chan_motif, because the actual
messaging work will need it (messaging without XMPP is just sad).

Review: https://reviewboard.asterisk.org/r/3760/

ASTERISK-23692
........

Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch adds a new operation for stored recordings, copy. It takes an
existing stored recording and makes a copy of it in the same directory
or a relative directory under the stored recording directory.

/ari/recordings/stored/{recordingName}/copy?destinationRecordingName={copy_name}

This is particularly useful for voicemail-esque applications, which may need to
copy or move recordings around a directory structure.

Review: https://reviewboard.asterisk.org/r/3768/

ASTERISK-24036 #close
Reported by: Sam Galarneau
Tested by: Sam Galarneau
........

Merged revisions 419021 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419022 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........

Merged revisions 418182 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418183 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The variables body parameter under the originate and originate with id
operations of the channel resource showed invalid JSON in its description.

The variables body parameter under the userEvent operation of the event
resource made no mention that the custom key/value pairs should be wrapped
in a variables key in order to be added to the custom user event.

ASTERISK-23975 #close

Review: https://reviewboard.asterisk.org/r/3692/
........

Merged revisions 417878 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417879 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch adds a new channel function TALK_DETECT that, when set on a
channel, causes events indicating the start/stop of talking on a channel to be
emitted to both AMI and ARI clients. 

The function allows setting both the silence threshold (the length of silence
after which we decide no one is talking) as well as the talking threshold (the
amount of energy that counts as talking). Parameters can be updated on a channel
after talk detection has been enabled, and talk detection can be removed at
any time.

The events raised by the function use a nomenclature similar to existing AMI/ARI
events.
For AMI: ChannelTalkingStart/ChannelTalkingStop
For ARI: ChannelTalkingStarted/ChannelTalkingFinished

Review: https://reviewboard.asterisk.org/r/3563/

#ASTERISK-23786 #close
Reported by: Matt Jordan
........

Merged revisions 414934 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414935 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Update the semantic versioning of ARI to 1.3.0 and AMI to 2.3.0 to account for
backwards compatible changes going from 12.2.0 to 12.3.0.
........

Merged revisions 414765 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414766 65c4cc65-6c06-0410-ace0-fbb531ad65f3

User events can now be generated from ARI.  Events can be signalled with
arbitrary json variables, and include one or more of channel, bridge, or
endpoint snapshots.  An application must be specified which will receive
the event message (other applications can subscribe to it).  The message
will also be delivered via AMI provided a channel is attached.  Dialplan
generated user event messages are still transmitted via the channel, and
will only be received by a stasis application they are attached to or if
the channel is subscribed to.

This change also introduces the multi object blob mechanism used to send
multiple snapshot types in a single message.  The dialplan app UserEvent
was also changed to use multi object blob, and a new stasis message type
created to handle them.

ASTERISK-22697 #close
Review: https://reviewboard.asterisk.org/r/3494/
........

Merged revisions 414405 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414406 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Previously multiple play actions against a bridge at one time would cause
the sounds to play simultaneously on the bridge. Now if a sound is already
playing, the play action will queue playback to occur after the completion
of other sounds currently on the queue.

(closes issue ASTERISK-22677)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/3379/
........

Merged revisions 412639 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412641 65c4cc65-6c06-0410-ace0-fbb531ad65f3