These problems were all caught by a test in the Asterisk Test Suite that
originated some Local channels and attempted to move the ;2 half of the Local
channel into a bridge using the Bridge AMI action.

(1) When originating a channel, the Newchannel event is emitted quickly;
    however, the ;2 channel will not have a pbx thread assigned to it until
    after the outbound 'dialing' for the ;1 is complete. Thus, there is a period
    of time where the outside world "knows" of the channel's existence and can
    influence it but Asterisk has not yet started the dialplan execution thread.
    If a Bridge AMI action is taken on the channel, the channel appears to be a
    Dialed channel with no PBX thread; hence, the channel will be imparted into
    the Bridge by first 'yanking' the channel. At the same time, a race condition
    can occur after the yank (but before entering the bridge) when ;1 answers
    and starts a PBX on the ;2. The end result currently is an assertion failure
    in the Bridging API, as a channel with a PBX is imparted into the Bridge.

    There's no way to prevent AMI from attempting to Bridge a channel
    immediately after creation; likewise, holding the channel lock through the
    entire Dial operation is unwise (and impossible). Instead of treating the
    presence of a PBX thread as an error, we simply bail out of the adding the
    channel to the bridge through ast_bridge_impart. The Bridge action will
    then fail - but we avoid a situation where the channel is both executing
    a PBX thread and simultaneously being given a separate thread in the
    bridging system (which would be a "bad thing"). Since imparting a channel
    with a PBX *can* occur and is not a programming error, the asserts have been
    removed.

(2) When the first condition occurs, we have to take one of two actions: either
    hangup the yanked channel as it did not enter the bridge, or deref it
    because we don't own it. We can determine if we own it or not by testing
    for the presence of the PBX thread. If we hung it up directly, we'd crash.

(3) bridge_find_channel does not increase the reference count of the
    ast_bridge_channel object. The RAII_VAR usage in ast_bridge_add_channel
    thus created a ticking time bomb in whatever bridge the channel moved into,
    as the destructor for the ast_bridge_channel object would be called.

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



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

If the thread servicing the dial request isn't created successfully, the
outgoing dial lock will still be held when the function returns. This patch
unlocks the lock on this off nominal path.


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

If a dial operation fails, the pbx_outgoing_attempt routine will exit without
first having unlocked the outgoing dial lock. This would be a "bad thing".


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

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


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

This makes it so that we can detect failures to originate as with
earlier versions of Asterisk, which restores the Asterisk 11 behavior
for the originate manager action. This was causing the ACL tests for
SIP and IAX2 to fail since those tests expected originate failures
when ACLs would cause rejections. Also, this patch fixes crashes in
chan_sip when ACLs rejected peers during registration verification.

(closes issue ASTERISK-22212)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2753/


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

The lonely flag is an optional flag for bridge channels that will
make them leave a bridge when a channel leaves if only lonely
channels are in the bridge at that point. This is useful for things
like ending recording and playback channels when they cease to be
interacting with other channels in the bridge.

(closes issue ASTERISK-22117)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2721/


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

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

* Changed ast_manager_build_bridge_state_string() to assume an empty
prefix string just like ast_manager_build_channel_state_string().

* Created ast_manager_build_bridge_state_string_prefix() to work just like
ast_manager_build_channel_state_string_prefix().

* Made BridgeMerge AMI event use To/From prefixes.


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

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

This patch does three things:
1. It provides a Surrogate channel technology with a consolidated
   "implementation detail flag" on the channel technology. This tells
   consumers of Stasis that the creation of this channel is an implementation
   detail in Asterisk and can be ignored (if they so choose). This
   consolidates the conference recorder/announcer flags as well - these flags
   had no additional meaning beyond "ignore this channel please".

2. It modifies allocation of a channel in two ways:
   (a) If a channel technology can be determined from the name, we set it
       directly in the allocation routine. This prevents the initial
       publication of the message from going out with a NULL channel technology
       where possible. This lets Stasis consumers get the right channel
       technology on the first publication.
   (b) It reorganizes allocation to make use of the 'finalized' property on the
       channel. This was already used to know that a channel had completely
       finished its construction in the masquerade routine; now we also use it
       to know whether or not the setting of certain channel properties is
       occurring during or post construction. The various set routines were
       modified accordingly as well.

3. The masquerade event is now dead, Jim. It no longer served any purpose
   whatsoever - if you perform a call pickup you'll get a Pickup event;
   if you perform an attended transfer you will still get those events; if you
   steal a channel to put it elsewhere you'll get the corresponding NewExten or
   BridgeEnter events.

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


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

Backtraces are allocated outside of the usual memory tracking performed by
MALLOC_DEBUG. This allows them to be used by the memory tracking enabled
by that build option; however, it also means that when backtraces are
disposed of they have to be done so outside of the re-defined free.

This patch undef's free prior to disposing of the allocated backtrace when
a backtrace is appended as a result of 'core show locks'.


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

This prevents unreal channel optimization during the prequalification
phase when either channel is involved in DTMF emulation. This prevents
a situation where an emulated digit would be missed because the
emulation was never completed.

Review: https://reviewboard.asterisk.org/r/2747/
(closes issue ASTERISK-22214)


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

Depending on when a Surrogate channel replaces an existing channel, it is
possible to get a Dial message for the Surrogate channel. When this occurs, no
CDR will exist for the channel as Surrogate channels are ignored. Safely handle
the case when a CDR doesn't exist for a Dial message.


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

This patch implements the controls from ARI recordings. The controls
are:

 * DELETE /recordings/live/{recordingName} - stop recording and
   discard it
 * POST /recordings/live/{recordingName}/stop - stop recording
 * POST /recordings/live/{recordingName}/pause - pause recording
 * POST /recordings/live/{recordingName}/unpause - resume recording
 * POST /recordings/live/{recordingName}/mute - mute recording (record
   silence to the file)
 * POST /recordings/live/{recordingName}/unmute - unmute recording.

Since this underlying functionality did not already exist, is was
added to app.c by a set of control frames, similar to how playback
control works. The pause/mute control frames are toggles, even though
the ARI controls are idempotent, to be consistent with the playback
control frames.

(closes issue ASTERISK-22181)
Review: https://reviewboard.asterisk.org/r/2697/


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

The Stasis changes in r395954 had an unanticipated side effect: messages
published directly to an _all topic does not get forwarded to the
corresponding caching topic.

This patch fixes that by changing how caching topics forward messages,
and how the caching pattern forwards are setup.

For the caching pattern, the all_topic is forwarded to the
all_topic_cached. This forwards messages published directly to the
all_topic to all_topic_cached.

In order to avoid duplicate messages on all_topic_cached, caching topics
were changed to no longer forward uncached messages. Subscribers to an
individual caching topic should only expect to receive cache updates,
and subscription change messages. Since individual caching topics are
new, this shouldn't be a problem.

There are a few minor changes to the pre-cache split behavior.

 * For topics changed to use the caching pattern, the all_topic_cached
   will forward snapshots in addition to cache updates. Since
   subscribers by design ignore unexpected messages, this should be
   fine.

 * Caching topics that don't use the caching pattern no longer forward
   non-cache updates. This makes no difference for the current caching
   topics.

   * mwi_topic_cached, channel_by_name_topic and
     presence_state_topic_cached have no subscribers

   * device_state_topic_cached's only subscriber only processes cache
     udpates

(issue ASTERISK-22243)
Review: https://reviewboard.asterisk.org/r/2738


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

Fix refcount bugs and a possible locking problem in the CDR engine
relating to use of ao2_iterators.

Review: https://reviewboard.asterisk.org/r/2724/
(closes issue ASTERISK-22126)


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

We try to keep the system running even when all available memory is
spent.

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

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

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


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

Dial and Queue would previously apply a new set of features whenever
bridging. These options would be based purely on the options supplied
to the dial/queue applications. This patch changes the function those
applications use to bridge calls so that the features will be added
to the set of existing features for each channel rather than having
them override the existing features.

(closes issue ASTERISK-22209)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2713/


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

Roles are now cleared with each entry into a bridge with addChannel.
If the roles parameter is present, the role specified will be applied
to all channels being added with the addChannel command.

(closes issue ASTERISK-21973)
Reported by: Matt Jordan
https://reviewboard.asterisk.org/r/2691/


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

The new res_ari_asterisk.so module presents several config options
from asterisk main. Unfortunately, they aren't exported, so the module
won't load on Linux.

This patch renames the variables, adding the ast_ prefix so they will
be exported.

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


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

The AMI message router is owned wholly by manager.c. Previously, each of the
manager_{item} source files had their own message router and they unsubscribed
from each; once they moved over to using a single message router only a single
unsubscribe became necessary.


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

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

In tracking down some unit tests failures, I ended up reading the fine
print[1] regarding Jansson's thread safety.

In short:
 1. Ref-counting is non-atomic.
 2. json_dumps() and friends are not thread safe.

This patch adds locking where necessary to our ast_json_* wrapper API,
with documentation in json.h describing the thread safety limitations of
the API.

 [1]: http://www.digip.org/jansson/doc/2.4/portability.html#thread-safety

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


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

* BridgeEnter now contains the unique ID of the channel that is to be swapped out, if applicable.
* There is a ParkedCallSwap event that is sent when a parked channel has a new channel take its place.

(closes issue ASTERISK-22193)
reported by Mark Michelson

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



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

This moves ast_str_container_alloc, ast_str_container_add,
ast_str_container_remove, and related private functions into
strings.c/h since they really don't belong in astobj2.c/h.

As a result of this move, utils also had to be updated.

Review: https://reviewboard.asterisk.org/r/2719/
(closes issue ASTERISK-22041)


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

This commit is smaller than the initial review placed on review board. This is because
a change to allow for channel drivers to access parking functionality externally was
committed and invalidated quite a few of the changes initially made.

(closes issue ASTERISK-22039)
reported by Matt Jordan

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



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

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

This patch does the following:
 * It moves the pickup code out of features.c and into pickup.c
 * It removes the vast majority of dead code out of features.c. In particular,
   this includes the parking code.

(issue ASTERISK-22134)



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

Some regex implementations won't compile an empty string. Assuming that
it's equivalent of a regex that will match anything, use ".?" instead.


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

This patch does the following:
 * It adds support for externally initiated parking requests. In particular,
   chan_skinny has a protocol level message that initiates a call park.
   This patch now supports that option, as well as the protocol specific
   mechanisms in chan_dahdi/sig_analog and chan_mgcp.
 * A parking bridge features virtual table has been added that provides
   access to the parking functionality that the Bridging API needs. This
   includes requests to park an entire 'call' (with little or no additional
   information, thank you chan_skinny), perform a blind transfer to a parking
   extension, determine if an extension is a parking extension, as well as the
   actual "do the parking" request from the Bridging API.
 * Refactoring in chan_mgcp, chan_skinny, and chan_dahdi to make use of the new
   functions
 * The removal of some - but not all - dead parking code from features.c

This also fixed blind transferring a multi-party bridge to a parking lot (which
was implemented, but had at least one code path where using the parking features
kK might not have worked)

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

(closes issue ASTERISK-22134)
Reported by: Matt Jordan



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

This prevents XML documentation duplication by expanding channel and
bridge snapshot tags into channel and bridge snapshot parameter sets
with a given prefix or defaulting to no prefix. This also prevents
documentation from becoming fractured and out of date by keeping all
variations of the documentation in template form such that it only
needs to be updated once and keeps maintenance to a minimum.

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


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

In working with res_stasis, I discovered a significant limitation to
the current structure of stasis_caching_topics: you cannot subscribe
to cache updates for a single channel/bridge/endpoint/etc.

To address this, this patch splits the cache away from the
stasis_caching_topic, making it a first class object. The stasis_cache
object is shared amongst individual stasis_caching_topics that are
created per channel/endpoint/etc. These are still forwarded to global
whatever_all_cached topics, so their use from most of the code does
not change.

In making these changes, I noticed that we frequently used a similar
pattern for bridges, endpoints and channels:

     single_topic  ---------------->  all_topic
           ^
           |
     single_topic_cached  ----+---->  all_topic_cached
                              |
                              +---->  cache

This pattern was extracted as the 'Stasis Caching Pattern', defined in
stasis_caching_pattern.h. This avoids a lot of duplicate code between
the different domain objects.

Since the cache is now disassociated from its upstream caching topics,
this also necessitated a change to how the 'guaranteed' flag worked
for retrieving from a cache. The code for handling the caching
guarantee was extracted into a 'stasis_topic_wait' function, which
works for any stasis_topic.

(closes issue ASTERISK-22002)
Review: https://reviewboard.asterisk.org/r/2672/


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

Interestingly, this only happens in dead code.



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

Subversion doesn't do quote processing, so it actually thinks that the
closing quote in 'Revision"' is a part of the keyword.


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

Mea culpa...


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

Performing a module reload of core components causes specific functions
compiled into the Asterisk binary to be reloaded. The table of said functions
was still pointing to the old features reload mechanism, and not the new one.

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

This renames all files and API calls from several variants of
Stasis-HTTP to ARI including:
* Stasis-HTTP -> ARI
* STASIS_HTTP -> ARI
* stasis_http -> ari (ast_ari for global symbols, file names as well)
* stasis http -> ARI

Review: https://reviewboard.asterisk.org/r/2706/
(closes issue ASTERISK-22136)


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

Most hook callbacks did not need the bridge parameter.  The pointer value
could become invalid if the channel is moved to another bridge while it is
executing.

* Fixed some issues in feature_attended_transfer() as a result.

* Reduce the bridge inhibit count in
attended_transfer_properties_shutdown() after it has restored the bridge
channel hooks.

* Removed basic bridge requirement on feature_blind_transfer().  It does
not require the basic bridge like feature_attended_transfer().


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

* Fixed feature limits to not use special members of struct
ast_bridge_features.

* Fixed memory leak in off nominal paths of bridge_builtin_set_limits().

* Fixed off nominal path in ast_bridge_features_limits_construct() freeing
unallocated memory if it was not called by bridge_builtin_set_limits().

* Made bridge_builtin_interval_features.so unloadable.

* Simplified parking's use of its duration interval hook.

* Made BridgeWait S option not depend upon another module being loaded.

(closes issue ASTERISK-22107)
Reported by: Matt Jordan

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


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

Changes arguments for BridgeWait from BridgeWait(role, options) to
BridgeWait(bridge_name, role, options). Now multiple holding bridges may
be created and referenced by this application.

(closes issue ASTERISK-21922)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2642/


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