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

Added or modified text in the xml doc for the 'aor' config object to address a few issues:
* help for the 'mailboxes' option didn't make it clear how the "list" should be formatted.
* AoR object's involvement in inbound registration wasn't mentioned.
* help for the 'contact' option didn't describe how to specify multiple contacts.
* help for the 'max_contacts' option didn't tell whether it limited the amount of contacts defined through static configuration.

(issue ASTERISK-22118)
(closes issue ASTERISK-22118)


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

'domain_alias' config object XML help doesn't make it clear that the name used for the object is the domain alias

(issue ASTERISK-22114)
(closes issue ASTERISK-22114)


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

(issue ASTERISK-22108)
(closes issue ASTERISK-22108)


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

xml doc change for transport config object - remove non-applicable warning and add text regarding Asterisk restart 

(closes issue ASTERISK-22105)


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

This change protects accesses of res_parking such that it can unload
safely once transient uses of its registered functions are complete.
The parking API has been restructured such that its consumers do not
have access to the vtable exposed by the parking provider, but instead
route through stubs to prevent consumers from holding on to function
pointers.

This adds calls to all the parking unload functions and moves
application loading and unloading into functions in
parking_applications.c similar to the rest of the parts of res_parking.

Review: https://reviewboard.asterisk.org/r/2763/
(closes issue ASTERISK-22142)


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

This removes usage of the event system for CEL backend data
distribution and strips unused pieces out of the event system.

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


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

This removes unused code, event types, IE pltypes, and event IE types
where possible and makes several functions private that were once
public. This includes a renumbering of the remaining event and IE types
which breaks binary compatibility with previous versions. The last
remaining consumers of the old event system (or parts thereof) are
main/security_events.c, res/res_security_log.c, tests/test_cel.c,
tests/test_event.c, main/cel.c, and the CEL backends.

Review: https://reviewboard.asterisk.org/r/2703/
(closes issue ASTERISK-22139)


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

SIP/foo -- Local;1==Local;2 -- .... -- Local;1==Local;2 -- SIP/bar
Kick a ;1 channel and the chain toward SIP/foo goes away.
Kick a ;2 channel and the chain toward SIP/bar goes away.

This can leave a local channel chain between the kicked ;1 and ;2 channels
that are orphaned until you manually request one of those channels to
hangup or request the bridge to dissolve.

* Added ast_bridge_kick() as a companion to ast_bridge_remove().  The
functional difference is that ast_bridge_kick() may dissolve the bridge as
a result of the channel leaving the bridge.

* Made CLI "bridge kick <bridge> <channel>" use ast_bridge_kick() instead
of ast_bridge_remove() so the bridge can dissolve if needed.

* Renamed bridge_channel_handle_hangup() to ast_bridge_channel_kick() and
made it accessible to other files.


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

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

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

The horrid structure of the source in the utils directory strikes again.
Moved the _ast_mem_backtrace_buffer[] definition from the logical location
in utils.c to hashtab.c so the aelparse and conf2ael utilities can link.


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

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

Change r395954 reordered some stasis object destruction, which should
have been fine. Unfortunately, it caused some hard to reproduce issues
related to objects being accessed after they had been destroyed. The
patch in r396329 fixed the destruction order problem; this patch
addresses the underlying issue. A few other stasis-related fixes were
also added.

 * Add ref-bumps around areas where objects may get transitively
   destroyed. (For example, where we lock a topic, unref a subscription,
   which unrefs the topic, which explodes the topic when we try to
   unlock it.)

 * Wrote an extensive doxygen page about Stasis implementation,
   relationships between objects, lifecycles of objects, how the
   refcounting works, etc. Many other comments were added, corrected, or
   cleaned up.

 * Added an assert to the topic dtor to catch extra ref decrements.

 * Fixed type used after destruction errors for graceful shutdown in
   stasis_channels.c.

 * I added two unit tests in an attempt to catch destruction order
   issues. Since the underlying cause is a race condition, though, the
   tests rarely failed even when the code was wrong.

 * Fixed a leak in stasis_cache_pattern.c.

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


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

This reworks the CLI commands used to access sounds information from
"sounds show[ soundid]" to "core show sounds" and
"core show sound <soundid>". This also reworks the "sounds reload" CLI
command to fall under normal module reloading ("module reload sounds").

Also, make trunk build when DEBUG_MALLOC is not enabled.

Review: https://reviewboard.asterisk.org/r/2745/
(closes issue ASTERISK-22141)


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

When asterisk has run out of memory (for whatever reason), the alloc
function logs a message. Logging requires memory. A recipe for
infinite recursion.

Stop the recursion by comparing the function call depth for sane values
before attempting another OOM log message.

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


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

By their nature, the connected line and redirecting interception routines
are not supposed to affect the channel's media.  Therefore, they should
not suspend and unsuspend the channel while running.  The
suspend/unsuspend operations could be expensive depending upon the bridge
and channel technology involved.


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

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

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


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

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

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

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

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

If you've mistakenly put a space before typing in a command, the
leading space will be included as part of the command, and the command
parser will not find the corresponding command. This patch rectifies
that situation by stripping the leading spaces on commands.

Review: https://reviewboard.asterisk.org/r/2709/
Patch-by: Tilghman Lesher
........

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

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


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

Remove some dead code dealing with: AST_BRIDGE_REC_CHANNEL_0, AST_BRIDGE_REC_CHANNEL_1, and AST_BRIDGE_IGNORE_SIGS.

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

The Bridge API DTMF hook matching would not deal with DTMF end events
only.  It required a DTMF begin event to start matching the DTMF hooks.
There are many places in Asterisk where code only generates DTMF end
events without the corresponding begin event.  One such place is the AMI
action Atxfer.

* Fixed DTMF hook matching if there is a string of DTMF frames in the read
queue.  We could potentially miss some of them before.

* Fixed AMI Atxfer action documentation.

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

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


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

The feature_attended_transfer test is failing due to Asterisk not
passing DTMF in the bridges created for internal attended transfers.
This sets the features initialization routine to set this flag by
default and adjusts the basic bridge and confbridge's use of the
bridging system accordingly as per Richard's suggestion instead of
adjusting this individual case. This change allows the necessary DTMF
to pass through the attended transfer bridge and complete the test
successfully.

Review: https://reviewboard.asterisk.org/r/2759/
(closes issue ASTERISK-22222)


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

This resolves several deadlocks in chan_sip relating to usage of
ast_channel_bridge_peer and improves accessibility of lock debugging
function calls.

Review: https://reviewboard.asterisk.org/r/2756/
(closes issue ASTERISK-22215)


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

This prevents swap optimization, merges, and transfers involving Stasis
application bridges. It wouldn't be nice if the bridge you thought you
owned disappeared from under you.

Reported-by: Richard Mudgett


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

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

chan_vpb: Effectively remove native support.  Left enough bread crumbs to be able to convert later if needed.

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

(issue ASTERISK-21944)


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

chan_misdn: Effectively remove native support.  Left enough bread crumbs to be able to convert later if needed.

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

Holding bridges can allow local channel move/swap optimization to the
bridge.  However, we cannot allow it for the BridgeWait holding bridge
because the call will lose the channel roles and dialplan location as a
result.


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

........

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

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


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

Depending on certain conditions it was possible for the hashtab counting thread
to starve other threads, preventing them from executing in the expected fashion.
This change adds a sleep to allow the others to do what they need to do. While
this doesn't thrash the hashtab as much as previously, it at least works.

(closes issue ASTERISK-22276)
Reported by: Matt Jordan
........

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

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


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

Patches:
    reviewboard-2377.patch uploaded by Paul Belanger
Review: https://reviewboard.asterisk.org/r/2377/
........

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

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


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

Patches:
    reviewboard-2155.patch uploaded by Paul Belanger
Review: https://reviewboard.asterisk.org/r/2155/
........

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

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


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

This patch changes ARI bridging to allow other channel operations to
happen while the channel is bridged.

ARI channel operations are designed to queue up and execute
sequentially. This meant, though, that while a channel was bridged,
any other channel operations would queue up and execute only after the
channel left the bridge.

This patch changes ARI bridging so that channel commands can execute
while the channel is bridged. For most operations, things simply work
as expected. The one thing that ended up being a bit odd is recording.

The current recording implementation will fail when one attempts to
record a channel that's in a bridge. Note that the bridge itself may
be recording; it's recording a specific channel in the bridge that
fails. While this is an annoying limitation, channel recording is
still very useful for use cases such as voice mail, and bridge
recording makes up much of the difference for other use cases.

(closes issue ASTERISK-22084)
Review: https://reviewboard.asterisk.org/r/2726/


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

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