(belongs with r419970)

ASTERISK-24040 #close
Patches:
	func_channel.c.diff uploaded by dtryba

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


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

This introduces stasis.conf and a mechanism to prevent certain message
types from being published. Internally, this works by preventing the
chosen message types from being created which ensures that those
message types can never be published. This patch also adjusts message
publishers such that message payloads are not created if the related
message type is not available.

ASTERISK-23943 #close
Review: https://reviewboard.asterisk.org/r/3823/


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

........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420100 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

........
format.c: Add reason comments for the format_list ordering.
........

Merged revisions 420054 from http://svn.asterisk.org/svn/asterisk/branches/11


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

Or any combination of codecs that includes Opus.

ASTERISK-24107 #close
Review: https://reviewboard.asterisk.org/r/3885/


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

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

This adds the ability to call CHANNEL(recvport) on chan_sip
channels to see the port on which an INVITE was received.

ASTERISK-24040 #close
Reported by dtryba
Patches:
	dialplan_functions.patch uploaded by dtryba (License #6628)

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



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

The documentation for these commands did not make it clear that they could
accept expressions and functions. Modified to make this clear, but tried
not to be overly explicit.

ASTERISK-21178 #close
Reported by: Rusty Newton
Tested by: Rusty Newton

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

Merged revisions 419942 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 419943 from http://svn.asterisk.org/svn/asterisk/branches/11
........

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


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

This adds a large swath of response documentation for PJSIPShowEndpoint
and PJSIPShowEndpoints AMI commands. It relies heavily on the existing
text in the configInfo documentation via xi:include tags to avoid
documentation duplication.

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


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

Now when running PJSIPShowEndpoint, you will receive a
ContactStatusDetail for each bound contact that Asterisk
is qualifying. This information includes the URI of the
contact, current reachability, and roundtrip time.

AFS-91 #close
Reported by Mark Michelson

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



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

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


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

This patch adds a new module to Asterisk, res_hep_rtcp. The module subscribes
to the RTCP topics in Stasis and receives RTCP information back from the
message bus. It encodes into HEPv3 packets and sends the information to the
res_hep module for transmission.

Using this, someone with a Homer server can get live call quality monitoring
for all RTP-based channels in their Asterisk 12+ systems.

In addition, there were a few bugs in the RTP engine, res_rtp_asterisk, and
chan_pjsip that were uncovered by the tests written for the Asterisk Test
Suite. This patch fixes the following:
1) chan_pjsip failed to set its channel unique ids on its RTP instance on
   outbound calls. It now does this in the appropriate location, in the
   serialized call callback.
2) The rtp_engine was overflowing some values when packed into JSON.
   Specifically, some longs and unsigned ints can't be be packed into integer
   values, for obvious reasons. Since libjansson only supports integers,
   floats, strings, booleans, and objects, we print these values into strings.
3) res_rtp_asterisk had a few problems:
   (a) it would emit a source IP address of 0.0.0.0 if bound to that IP
       address. We now use ast_find_ourip to get a better IP address, and
       properly marshal the result into an ast_strdupa'd string.
   (b) Reports can be generated with no report bodies. In particular, this
       occurs when a sender is transmitting information to a receiver (who
       will send no RTP back to the sender). As such, the sender has no report
       body for what it received. We now properly handle this case, and the
       sender will emit SR reports with no body. Likewise, if we receive an
       RTCP packet with no report body, we will still generate the appropriate
       events.

ASTERISK-24119 #close
........

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


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

This patch adds support for an <example /> tag in the XML documentation schema.

For CLI help, this doesn't change the formatting too much:
 - Preceeding white space is removed
 - Unlike with para elements, new lines are preserved

However, having an <example /> tag in the XML schema allows for the wiki
documentation generation script to surround the documentation with {code} or
{noformat} tags, generating much better content for the wiki - and allowing us
to put dialplan examples (and other code snippets, if desired) into the
documentation for an application/function/AMI command/etc.

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


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

This patch adds three new AMI commands:
 * ExtensionStateList (pbx.c) - list all known extension state hints
   and their current statuses. Events emitted by the list action are
   equivalent to the ExtensionStatus events.
 * PresenceStateList (res_manager_presencestate) - list all known
   presence state values. Events emitted are generated by the stasis
   message type, and hence are PresenceStateChange events.
 * DeviceStateList (res_manager_devicestate) - list all known device
   state values. Events emitted are generated by the stasis message
   type, and hence are DeviceStateChange events.

Patch-by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3799/


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

ASTERISK-24124 #close
Reported by Matt Jordan

AFS-131 #close
Reported by Matt Jordan

Patches:
	userevent.patch uploaded by Matt Jordan (License #6283)



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

Since the PJSIP INVITE session module is invoked before any session supplements it was
possible for it to handle a redirect before the res_pjsip_diversion module interpreted
and set redirecting information on the channel. This would cause the redirecting
information to get lost.

This patch ensures that session supplements are *always* invoked before a redirect occurs
by explicitly calling them in the redirect handler.

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

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


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

The local entity as provided by PJSIP is quoted within '<' and '>'. As a result placing
this value into XML will result in malformed XML being produced. This patch now unquotes
the local entity so it can go safely into the XML.

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

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


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

Audit of v1.8 usage of ast_channel_datastore_remove() for datastore memory
leaks.

* Fixed leaks in app_speech_utils and func_frame_trace.

* Fixed app_speech_utils not locking the channel when accessing the
channel datastore list.

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

Audit of v11 usage of ast_channel_datastore_remove() for datastore memory
leaks.

* Fixed leak in func_jitterbuffer.  (Was not in v12)

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

Audit of v12 usage of ast_channel_datastore_remove() for datastore memory
leaks.

* Fixed leaks in abstract_jb.

* Fixed leak in ast_channel_unsuppress().  Used by ARI mute control and
res_mutestream.

* Fixed ref leak in ast_channel_suppress().  Used by ARI mute control and
res_mutestream.

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

Merged revisions 419684 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 419685 from http://svn.asterisk.org/svn/asterisk/branches/11
........

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


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

When creating the alphabetical sorted list each module is added to a list
temporarily. On the second iteration each module already has a pointer to
another module, causing stuff to go into a loop.

ASTERISK-24123 #close
Reported by: Malcolm Davenport


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

ASTERISK-23919 #close
Reported by Malcolm Davenport

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



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 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

When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.

Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.

While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.

1. The linked list of modules has been replaced with a doubly linked list. This
   allows traversal of the module list to occur backwards. The module shutdown
   routine now walks the global list backwards when it attempts to unload
   modules.
2. The alphabetic reorganization of the module list on startup has been
   removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
   the modules - now does the sorting alphabetically itself. It creates its own
   linked list and inserts the modules into it in alphabetic order. This allows
   for the intent of the previous code to be maintained.

This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.

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


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

Bridges created by app_bridgewait previously had the "dissolve when empty" flag set.
This caused the bridge core to destroy them when the last channel had left. This
introduced a race condition where we may have a reference to the bridge but it is
not actually joinable when we try to join it. This flag has now been removed and the
bridge is guaranteed to be joinable at all times.

ASTERISK-23987 #close
Reported by: Matt Jordan

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

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


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

The "bridge destroy" CLI command is invasive to bridges and can leave them in an unexpected
state for the users of them. Since this command may be useful for developers it is now
only available when developer mode is available. To take its place "all" has been added
as a valid option to the "bridge kick" CLI command. It will kick all of the channels
in the bridge out.

ASTERISK-23987
Reported by: Matt Jordan

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

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


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

The previous behavior was to simply set the accountcode of an outgoing
channel to the accountcode of the channel initiating the call.  It was
done this way a long time ago to allow the accountcode set on the SIP/100
channel to be propagated to a local channel so the dialplan execution on
the Local;2 channel would have the SIP/100 accountcode available.

SIP/100 -> Local;1/Local;2 -> SIP/200

Propagating the SIP/100 accountcode to the local channels is very useful.
Without any dialplan manipulation, all channels in this call would have
the same accountcode.

Using dialplan, you can set a different accountcode on the SIP/200 channel
either by setting the accountcode on the Local;2 channel or by the Dial
application's b(pre-dial), M(macro) or U(gosub) options, or by the
FollowMe application's b(pre-dial) option, or by the Queue application's
macro or gosub options.  Before Asterisk v12, the altered accountcode on
SIP/200 will remain until the local channels optimize out and the
accountcode would change to the SIP/100 accountcode.

Asterisk v1.8 attempted to add peeraccount support but ultimately had to
punt on the support.  The peeraccount support was rendered useless because
of how the CDR code needed to unconditionally force the caller's
accountcode onto the peer channel's accountcode.  The CEL events were thus
intentionally made to always use the channel's accountcode as the
peeraccount value.

With the arrival of Asterisk v12, the situation has improved somewhat so
peeraccount support can be made to work.  Using the indicated example, the
the accountcode values become as follows when the peeraccount is set on
SIP/100 before calling SIP/200:

SIP/100 ---> Local;1 ---- Local;2 ---> SIP/200
acct: 100 \/ acct: 200 \/ acct: 100 \/ acct: 200
peer: 200 /\ peer: 100 /\ peer: 200 /\ peer: 100

If a channel already has an accountcode it can only change by the
following explicit user actions:

1) A channel originate method that can specify an accountcode to use.

2) The calling channel propagating its non-empty peeraccount or its
non-empty accountcode if the peeraccount was empty to the outgoing
channel's accountcode before initiating the dial.  e.g., Dial and
FollowMe.  The exception to this propagation method is Queue.  Queue will
only propagate peeraccounts this way only if the outgoing channel does not
have an accountcode.

3) Dialplan using CHANNEL(accountcode).

4) Dialplan using CHANNEL(peeraccount) on the other end of a local
channel pair.

If a channel does not have an accountcode it can get one from the
following places:

1) The channel driver's configuration at channel creation.

2) Explicit user action as already indicated.

3) Entering a basic or stasis-mixing bridge from a peer channel's
peeraccount value.

You can specify the accountcode for an outgoing channel by setting the
CHANNEL(peeraccount) before using the Dial, FollowMe, and Queue
applications.  Queue adds the wrinkle that it will not overwrite an
existing accountcode on the outgoing channel with the calling channels
values.

Accountcode and peeraccount values propagate to an outgoing channel before
dialing.  Accountcodes also propagate when channels enter or leave a basic
or stasis-mixing bridge.  The peeraccount value only makes sense for
mixing bridges with two channels; it is meaningless otherwise.

* Made peeraccount functional by changing accountcode propagation as
described above.

* Fixed CEL extracting the wrong ie value for the peeraccount.  This was
done intentionally in Asterisk v1.8 when that version had to punt on
peeraccount.

* Fixed a few places dealing with accountcodes that were reading from
channels without the lock held.

AFS-65 #close

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


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

Reverting the patch since it was causing a regression and after fixing the
regression, there were no performance gains.  At least based on my method
for measurement.

ASTERISK-24050

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


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

These change was applied to trunk in r419438

........
chan_sip: sip_subscribe_mwi_destroy should not call sip_destroy

sip_subscribe_mwi_destroy calls sip_destroy on the reference counted
mwi->call.  This results in the fields of mwi->call being freed, but
mwi->call itself it leaked.  If other code is still using mwi->call
it can cause problems.  This change uses dialog_unref instead, to
balance the ref provided by sip_alloc().

ASTERISK-24087 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/3834/
........

Merged revisions 419440 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 419441 from http://svn.asterisk.org/svn/asterisk/branches/11


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

This flags astobj.h as deprecated, warns people to use astobj2.h instead.
Only netsock.c (also deprecated) still uses astobj.h.

ASTERISK-24069 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/3818/


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

This change upgrades sip_registry and sip_subscription_mwi to astobj2.

ASTERISK-24067 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/3759/


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

(closes issue ASTERISK-23814)
........

Merged revisions 419374 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 419375 from http://svn.asterisk.org/svn/asterisk/branches/11
........

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


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

In Asterisk, it is possible for a device to have a status of ONHOLD. This is
not typically an easy thing to determine, as a channel being on hold is not
a direct channel state. Typically, this has to be calculated outside of the
core independently in channel drivers, notably, chan_sip and chan_pjsip. Both
of these channel drivers already have to calculate device state in a fashion
more complex than the core can handle, as they aggregate all state of all
channels associated with a peer/endpoint; they also independently track
whether or not one of those channels is currently on hold and mark the device
state appropriately.

In 12+, we now have the ability to report an AST_DEVICE_ONHOLD state for all
channels that defer their device state to the core. This is due to channel hold
state actually now being tracked on the channel itself. If a channel driver
defers its device state to the core (which many, such as DAHDI, IAX2, and
others do in most situations), the device state core already goes out to get a
channel associated with the device. As such, it can now also factor the channel
hold state in its calculation.

This patch adds this logic to the device state core. It also uses an existing
mapping between device state and channel state to handle more channel states.
chan_pjsip has been updated slightly as well to make use of this (as it was,
for some reason, reporting a channel state of BUSY as a device state of INUSE,
which feels slightly wrong).

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

ASTERISK-24038 #close


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

Allow for responses to AMI actions/commands to be documented properly
in XML and displayed via the CLI. Response events are documented
exactly as standard AMI events are documented.

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


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

This patch does two things:
(1) It updates the unit tests to expect additional stasis messages. More
    messages are now sent to the endpoint topic, due to forwarding all
    channel messages and the forwarding relationship set up between
    endpoints themselves.
(2) Remove the technology forwarding subscription during
    ast_endpoint_shutdown. This prevents an improper double shutdown of
    an endpoint from occurring.
........

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


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

........
res_pjsip_refer: remove stray debugging line

How'd those @ symbols get in there...


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

When updating voicemail.conf when a user changes
their pin, change the generator string to be the
same as the module name when reading so that the
same config_hook will be called.

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

Merged revisions 419284 from http://svn.asterisk.org/svn/asterisk/branches/11
........

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


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

* Unregister manager actions FAXSessions, FAXSession and FAXStats at unload.
* Update ast_manager_register2 use ao2_t_alloc tagged with the action name.

ASTERISK-24058 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/3831/


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

Say you wanted to include variables in an application map and have those
variables substituted and passed along to the application being executed;
currently this does not happen.

This patch adds this ability to pass channel variable values to an
application before being executed.

ASTERISK-22608 #close
Reported by: Michael L. Young
patches:
  features_substitute_arguments_v2.diff
                                     uploaded by Michael L. Young (license 5026)

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


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

We have a new periodic beep feature but sometimes a user needs some sort of
feedback, without the need to have a periodic beep during the recording, to let
them know that MixMonitor started recording or ended the recording.  The use
case where this patch is being used is when using Dynamic Features to start and
end MixMonitor.

This patch adds an option to play a beep when MixMonitor starts and an option to
play a beep when MixMonitor ends.

ASTERISK-24051 #close
Reported by: Michael L. Young
patches:
  mixmonitor-play-beep-start-stop.diff
                                     uploaded by Michael L. Young (license 5026)

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


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

When updating a row, we are currently doing an INSERT OR REPLACE INTO.  The
downside to this is that the row is deleted if it exists and then a new row is
inserted.  So, we are hitting the disk twice.  One for the deletion and one for
the insertion.

This patch changes this statement to an INSERT INTO and if the insert fails
because a row with that key exists, we will IGNORE the failure.  Then we will
attempt to perform an UPDATE on the existing row if that row wasn't just
INSERTed.

ASTERISK-24050 #close
Reported by: Michael L. Young
patches:
  astdb-insert-update-io-help_trunk_v2.diff
                                     uploaded by Michael L. Young (license 5026)

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


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