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

Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename

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

ASTERISK-26480 #close

Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966

Added needed UTF-8 checks before constructing json objects in various
files for strings obtained outside the system.  In this case string values
from a channel driver's peer and not from the user setting channel
variables.

* aoc.c: Fixed type mismatch in s_to_json() for time and granularity json
object construction.

ASTERISK-26466
Reported by: Richard Mudgett

Change-Id: Iac2d867fa598daba5c5dbc619b5464625a7f2096

CEL wrongly assumed that a channel would only have a single dial
event on it. This is incorrect. Particularly in a queue each
call attempt to a member will result in a dial event, adding
a new dial status in CEL without removing the old one. This
would cause the container to grow with only one dial status
being removed when the channel went away. The other dial status
entries would remain leaking memory.

This change fixes the memory leak by ensuring that only one dial
status will only ever exist for each channel.

The behavior during the scenario where multiple events are received
has also been improved. For failure cases the first failure will
be the dial status. If an answer dial status is received, though,
it will take priority and the dial status for the channel will be
answer.

Memory usage has also been decreased by storing the minimal
amount of information and the code has been cleaned up slightly.

ASTERISK-25262 #close

Change-Id: I5944eb923db17b6a0faa7317ff6abc9307c009fe

Stasis subscriptions and message routers create taskprocessors to process
the event messages.  API calls are needed to be able to set the congestion
levels of these taskprocessors for selected subscriptions and message
routers.

* Updated CDR, CEL, and manager's stasis subscription congestion levels
based upon stress testing.  Increased the congestion levels to reduce the
potential for bursty call setup/teardown activity from triggering the
taskprocessor overload alert.  CDRs in particular need an extra high
congestion level because they can take awhile to process the stasis
messages.

ASTERISK-26088
Reported by:  Richard Mudgett

Change-Id: Id0a716394b4eee746dd158acc63d703902450244

The return type of ast_cel_track_event() is not large enough to return all
64 potential bits of the event enable mask.  Fortunately, the defined CEL
events do not really need all 64 bits and the return value is only used to
determine if the requested CEL event is enabled.

* Made the ast_cel_track_event() return 0 or 1 only so the return value
can fit inside an int type instead of zero or a truncated 64 bit non-zero
value.

Change-Id: I783d932320db11a95c7bf7636a72b6fe2566904c

Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.

Specifically, it does the following:

* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
  remove passing the version in with the macro. Other facilities
  than 'core show file version' make use of the file names, such as
  setting a debug level only on a specific file. As such, the act of
  registering source files with the Asterisk core still has use. The
  macro rename now reflects the new macro purpose.

* main/asterisk:
  - Refactor the file_version structure to reflect that it no longer
    tracks a version field.
  - Remove the "core show file version" CLI command. Without the file
    version, it is no longer useful.
  - Remove the ast_file_version_find function. The file version is no
    longer tracked.
  - Rename ast_register_file_version/ast_unregister_file_version to
    ast_register_file/ast_unregister_file, respectively.

* main/manager: Remove value from the Version key of the ModuleCheck
  Action. The actual key itself has not been removed, as doing so would
  absolutely constitute a backwards incompatible change. However, since
  the file version is no longer tracked, there is no need to attempt to
  include it in the Version key.

* UPGRADE: Add notes for:
  - Modification to the ModuleCheck AMI Action
  - Removal of the "core show file version" CLI command

Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e

This fixes autological comparison warnings in the following:
 * chan_skinny: letohl may return a signed or unsigned value, depending on the
   macro chosen
 * func_curl: Provide a specific cast to CURLoption to prevent mismatch
 * cel: Fix enum comparisons where the enum can never be negative
 * enum: Fix comparison of return result of dn_expand, which returns a signed
   int value
 * event: Fix enum comparisons where the enum can never be negative
 * indications: tone_data.freq1 and freq2 are unsigned, and hence can never be
   negative
 * presencestate: Use the actual enum value for INVALID state
 * security_events: Fix enum comparisons where the enum can never be negative
 * udptl: Don't bother to check if the return value from encode_length is less
   than 0, as it returns an unsigned int
 * translate: Since the parameters are unsigned int, don't bother checking
   to see if they are negative. The cast to unsigned int would already blow
   past the matrix bounds.
 * res_pjsip_exten_state: Use a temporary value to cache the return of
   ast_hint_presence_state
 * res_stasis_playback: Fix enum comparisons where the enum can never be
   negative
 * res_stasis_recording: Add an enum value for the case where the recording
   operation is in error; fix enum comparisons
 * resource_bridges: Use enum value as opposed to -1
 * resource_channels: Use enum value as opposed to -1

Review: https://reviewboard.asterisk.org/r/4533
ASTERISK-24917
Reported by: dkdegroot
patches:
  rb4533.patch submitted by dkdegroot (License 6600)
........

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

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


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

Since 'core stop now' and 'core restart now' do not stop modules,
it is unsafe for most of the core to run cleanups.  Originally all
cleanups used ast_register_atexit, and were only changed when it
was shown to be unsafe.  ast_register_atexit is now used only when
absolutely required to prevent corruption and close child processes.

Exceptions that need to use ast_register_atexit:
* CDR: Flush records.
* res_musiconhold: Kill external applications.
* AstDB: Close the DB.
* canary_exit: Kill canary process.

ASTERISK-24142 #close
Reported by: David Brillert

ASTERISK-24683 #close
Reported by: Peter Katzmann

ASTERISK-24805 #close
Reported by: Badalian Vyacheslav

ASTERISK-24881 #close
Reported by: Corey Farrell

Review: https://reviewboard.asterisk.org/r/4500/
Review: https://reviewboard.asterisk.org/r/4501/
........

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

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


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

From reviewboard:

"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?

The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."

The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.

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

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

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


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

CEL typically tracks a lot of information using the unique ID of the channel.
This is typically needed due to tying events together using the linked ID of
the various channels involved in a "call", which is derived from the channel ID
of the oldest channel involved in a bridge (or in the case of a Dial, the
parent channel).

Previously, we had updated the extra fields to include the involved channel
names, but forgot to put in the unique ID. This patch corrects that error.
........

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

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


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

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

This corrects two issues with the extra field information in Asterisk
12+ in channel event logs.

It is possible to inject custom values into the dialstatus provided by
ast_channel_dial_type() Stasis messages that fall outside the
enumeration allowed for the DIALSTATUS channel variable. CEL now
filters for the allowed values and ignores other values.

The "hangupsource" extra field key is always blank if the far end
channel is a chan_pjsip channel. This is because the hangupsource is
never set for the pjsip channel driver. This change sets the
hangupsource whenever a hangup is queued for chan_pjsip channels.

This corrects an issue with the pjsip channel driver where the
hangupcause information was not being set properly.

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

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


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

Add the "bridge_technology" extra field key to BRIDGE_ENTER and
BRIDGE_EXIT CEL events to convey the bridge technology in use at the
time the record was generated.


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

During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
 * AGI execution
 * Returning objects for ARI commands
 * During some Local channel operations
 * During some dialling operations
 * During variable setting
 * During some bridging operations
And more.

This patch does the following:
 - It removes a number of fields from channel snapshots. These fields were
   rarely used, were expensive to have on the snapshot, and hurt performance.
   This included formats, translation paths, Log Call ID, callgroup, pickup
   group, and all channel variables. As a result, AMI Status,
   "core show channel", "core show channelvar", and "pjsip show channel" were
   modified to either hit the live channel or not show certain pieces of data.
   While this is unfortunate, the performance gain from this patch is worth
   the loss in behaviour.
 - It adds a mechanism to publish a cached snapshot + blob. A large number of
   publications were changed to use this, including:
   - During Dial begin
   - During Variable assignment (if no AMI variables are emitted - if AMI
     variables are set, we have to make snapshots when a variable is changed)
   - During channel pickup
   - When a channel is put on hold/unhold
   - When a DTMF digit is begun/ended
   - When creating a bridge snapshot
   - When an AOC event is raised
   - During Local channel optimization/Local bridging
   - When endpoint snapshots are generated
   - All AGI events
   - All ARI responses that return a channel
   - Events in the AgentPool, MeetMe, and some in Queue
 - Additionally, some extraneous channel snapshots were being made that were
   unnecessary. These were removed.
 - The result of ast_hashtab_hash_string is now cached in stasis_cache. This
   reduces a large number of calls to ast_hashtab_hash_string, which reduced
   the amount of time spent in this function in gprof by around 50%.

#ASTERISK-23811 #close
Reported by: Matt Jordan

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

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


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

This exposes the retreiver of a parked call under the "retreiver" key
of the extra field when this information is available.

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

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


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

Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it.  Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation.  This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first.  In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.

Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.

(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........

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


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

The CEL data structures need to be protected during a configuration reload
and shutdown.  Asterisk crashed during a shutdown because CEL events were
still in flight and the CEL data structures were already destroyed.

* Protected the cel_backends, cel_dialstatus_store, and cel_linkedids ao2
containers with a global ao2 object wrapper.

* Added NULL checks before use of the cel_backends, cel_dialstatus_store,
and cel_linkedids ao2 containers in case the CEL module is already
shutdown.

* Fixed overloading of the cel_linkedids held objects reference count.
During shutdown any held objects would be leaked.

* Fixed memory leak of cel_linkedids held objects if the LINKEDID_END is
not being tracked.  The objects in the cel_linkedids container were not
removed if the LINKEDID_END event is not used.

* Added access protection to the cel_backends container during the CLI
"cel show status" command.

* Made cel_backends, cel_dialstatus_store, and cel_linkedids use the
standard ao2 callback templates for the hash and cmp functions.

* Eliminated unnecessary uses of RAII_VAR().

* Made ast_cel_engine_init() cleanup alocated resources on failure.

(closes issue AST-1253)
Reported by: Guenther Kelleter

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

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

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

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


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

Original commit message by mmichelson (asterisk 12 r403311):

"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."

The above was initially committed and then reverted at r403398.  The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed.  Fixed by unreffing the channels.

Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel.  Fixed by
unlocking "other->chan"

(closes issue ASTERISK-22709)
Reported by: John Bigelow
........

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


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

........

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


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

This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
........

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


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

This fixes a crash when CELGenUserEvent is called from the dialplan
while CEL is disabled. Currently, CEL does not create its topics and
forwards if it is not enabled and external entities may depend on
these topics blindly since they should always be available. This patch
breaks up route creation and topic/forward creation such that the CEL
topics and forwards will always exist while the router and its
associated routes will be torn down and recreated as necessary.

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

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


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

........

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


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

Subscribing to Stasis isn't free.

As such, this patch makes AMI, CDR, and CEL - the "big 3" - only subscribe
when enabled. Toggling their availability via a .conf file will
unsubscribe/subscribe as appropriate.

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

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


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

........
  r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
  
  Minor performance bump by not allocate manager variable struct if we don't need it
........
  r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
  
  Stasis performance improvements
  
  This patch addresses several performance problems that were found in
  the initial performance testing of Asterisk 12.
  
  The Stasis dispatch object was allocated as an AO2 object, even though
  it has a very confined lifecycle. This was replaced with a straight
  ast_malloc().
  
  The Stasis message router was spending an inordinate amount of time
  searching hash tables. In this case, most of our routers had 6 or
  fewer routes in them to begin with. This was replaced with an array
  that's searched linearly for the route.
  
  We more heavily rely on AO2 objects in Asterisk 12, and the memset()
  in ao2_ref() actually became noticeable on the profile. This was
  #ifdef'ed to only run when AO2_DEBUG was enabled.
  
  After being misled by an erroneous comment in taskprocessor.c during
  profiling, the wrong comment was removed.
  
  Review: https://reviewboard.asterisk.org/r/2873/
........
  r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
  
  Taskprocessor optimization; switch Stasis to use taskprocessors
  
  This patch optimizes taskprocessor to use a semaphore for signaling,
  which the OS can do a better job at managing contention and waiting
  that we can with a mutex and condition.
  
  The taskprocessor execution was also slightly optimized to reduce the
  number of locks taken.
  
  The only observable difference in the taskprocessor implementation is
  that when the final reference to the taskprocessor goes away, it will
  execute all tasks to completion instead of discarding the unexecuted
  tasks.
  
  For systems where unnamed semaphores are not supported, a really
  simple semaphore implementation is provided. (Which gives identical
  performance as the original taskprocessor implementation).
  
  The way we ended up implementing Stasis caused the threadpool to be a
  burden instead of a boost to performance. This was switched to just
  use taskprocessors directly for subscriptions.
  
  Review: https://reviewboard.asterisk.org/r/2881/
........
  r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
  
  Optimize how Stasis forwards are dispatched
  
  This patch optimizes how forwards are dispatched in Stasis.
  
  Originally, forwards were dispatched as subscriptions that are invoked
  on the publishing thread. This did not account for the vast number of
  forwards we would end up having in the system, and the amount of work it
  would take to walk though the forward subscriptions.
  
  This patch modifies Stasis so that rather than walking the tree of
  forwards on every dispatch, when forwards and subscriptions are changed,
  the subscriber list for every topic in the tree is changed.
  
  This has a couple of benefits. First, this reduces the workload of
  dispatching messages. It also reduces contention when dispatching to
  different topics that happen to forward to the same aggregation topic
  (as happens with all of the channel, bridge and endpoint topics).
  
  Since forwards are no longer subscriptions, the bulk of this patch is
  simply changing stasis_subscription objects to stasis_forward objects
  (which, admittedly, I should have done in the first place.)
  
  Since this required me to yet again put in a growing array, I finally
  abstracted that out into a set of ast_vector macros in
  asterisk/vector.h.
  
  Review: https://reviewboard.asterisk.org/r/2883/
........
  r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
  
  Remove dispatch object allocation from Stasis publishing
  
  While looking for areas for performance improvement, I realized that an
  unused feature in Stasis was negatively impacting performance.
  
  When a message is sent to a subscriber, a dispatch object is allocated
  for the dispatch, containing the topic the message was published to, the
  subscriber the message is being sent to, and the message itself.
  
  The topic is actually unused by any subscriber in Asterisk today. And
  the subscriber is associated with the taskprocessor the message is being
  dispatched to.
  
  First, this patch removes the unused topic parameter from Stasis
  subscription callbacks.
  
  Second, this patch introduces the concept of taskprocessor local data,
  data that may be set on a taskprocessor and provided along with the data
  pointer when a task is pushed using the ast_taskprocessor_push_local()
  call. This allows the task to have both data specific to that
  taskprocessor, in addition to data specific to that invocation.
  
  With those two changes, the dispatch object can be removed completely,
  and the message is simply refcounted and sent directly to the
  taskprocessor.
  
  Review: https://reviewboard.asterisk.org/r/2884/
........

Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This change makes the CEL peer field useful again for BRIDGE_ENTER and
BRIDGE_EXIT events and fills the field with a comma-separated list of
all channels in the bridge other than the channel that is entering or
exiting the bridge.

Review: https://reviewboard.asterisk.org/r/2840/
(closes issue ASTERISK-22393)
........

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


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

* Fixed resulting warnings with improper use of ao2_global_obj_replace().

* Made a couple uses of ao2_global_obj_replace_unref(x, NULL) into the
equivalent and more appropriate ao2_global_obj_release() call.
........

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


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

(closes ASTERISK-22376)
Reported by: John Hardin
Patches:
     memleak.patch uploaded by jhardin (license 6512)
     memleak2.patch uploaded by jhardin (license 6512)
........

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


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

........
  r397921 | mmichelson | 2013-08-29 10:42:10 -0500 (Thu, 29 Aug 2013) | 6 lines
  
  Resolve assumptions that bridge snapshots would be non-NULL for transfer stasis events.
  
  Attempting to transfer an unbridged call would result in crashes in either CEL code or
  in the conversion to AMI messages.
........
  r397922 | mmichelson | 2013-08-29 10:42:29 -0500 (Thu, 29 Aug 2013) | 3 lines
  
  Remove extra debug message.
........

Merged revisions 397921-397922 from http://svn.asterisk.org/svn/asterisk/branches/12


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

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

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

This modifies the behavior of the CEL engine to conform to documented
behavior for Asterisk 12 as defined on the wiki
https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CEL+Specification

The primary changes deal with removal of the peer field from function
calls since it is no longer directly relevant to the bridging system
and removal of the layer of CDR-like business logic that was providing
a partial emulation of Asterisk 11 CEL functionality. With this change,
there is no longer a distinction between "bridges" and "conferences"
and all participation changes are denoted with bridge enter and bridge
exit messages.

This updates the CEL unit tests to handle these changes and simplifies
some of the macros used in the process.

This also fixes a segfault when attempting to ref a configuration that
failed to load.

Review: https://reviewboard.asterisk.org/r/2788/
(issue ASTERISK-21567)


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

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

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

This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.

A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.

(closes issue ASTERISK-22130)


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

This greatly modifies the operation of DTMF attended transfers so that
the full range of options from features.conf applies.

In addition, a new option has been added that allows for a transferer
to switch between bridges during a transfer before completing the
transfer.

(closes issue ASTERISK-21543)
reported by Matt Jordan

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



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