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

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

........

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

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


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

ASTERISK-24049


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

Follow-up issue to -r430435 from reviewboard review.

ASTERISK-24049
Review: https://reviewboard.asterisk.org/r/4315/


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

* Made the following AMI actions use list API calls for consistency:
Agents
BridgeInfo
BridgeList
BridgeTechnologyList
ConfbridgeLIst
ConfbridgeLIstRooms
CoreShowChannels
DAHDIShowChannels
DBGet
DeviceStateList
ExtensionStateList
FAXSessions
Hangup
IAXpeerlist
IAXpeers
IAXregistry
MeetmeList
MeetmeListRooms
MWIGet
ParkedCalls
Parkinglots
PJSIPShowEndpoint
PJSIPShowEndpoints
PJSIPShowRegistrationsInbound
PJSIPShowRegistrationsOutbound
PJSIPShowResourceLists
PJSIPShowSubscriptionsInbound
PJSIPShowSubscriptionsOutbound
PresenceStateList
PRIShowSpans
QueueStatus
QueueSummary
ShowDialPlan
SIPpeers
SIPpeerstatus
SIPshowregistry
SKINNYdevices
SKINNYlines
Status
VoicemailUsersList

* Incremented the AMI version to 2.7.0.

* Changed astman_send_listack() to not use the listflag parameter and
always set the value to "Start" so the start capitalization is consistent.
i.e., The FAXSessions used "Start" while the rest of the system used
"start".  The corresponding complete event always used "Complete".

* Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the
AMI ActionID for all of its list events.

* Fixed off-nominal AMI protocol error in manager_bridge_info(),
manager_parking_status_single_lot(), and
manager_parking_status_all_lots().  Use of astman_send_error() after
responding to the original AMI action request violates the action response
pattern by sending two responses.

* Fixed minor protocol error in action_getconfig() when no requested
categories are found.  Each line needs to be formatted as "Header: text".

* Fixed off-nominal memory leak in manager_build_parked_call_string().

* Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail().

ASTERISK-24049 #close
Reported by: Jonathan Rose

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430435 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 resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
........

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

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

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


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

Bridges have two new optional properties, a creator and a name.
Certain consumers of bridges will automatically provide bridges that
they create with these properties. Examples include app_bridgewait,
res_parking, app_confbridge, and app_agent_pool. In addition, a name
may now be provided as an argument to the POST function for creating
new bridges via ARI.

(closes issue AFS-47)
Review: https://reviewboard.asterisk.org/r/3070/
........

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


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

Adds the following AMI events, closely following their CLI counterparts:

BridgeDestroy
BridgeKick
BridgeTechnologyList
BridgeTechnologySuspend
BridgeTechnologyUnsuspend

BridgeDestroy kicks an entire bridge, where BridgeKick kicks just one
channel off the bridge. When kicking a channel, specifying the bridge
also (optional) insures it is not removed from the wrong bridge.  The
BridgeTechnology events allow viewing and changing suspension status,
which affects only subsequent not active bridging.

(closes ASTERISK-22356)
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/2973/
........

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


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

* 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

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

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

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

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

Ensure that the BridgeInfo command provides adequate state information
about channels by publishing the full channel snapshot for
BridgeInfoChannel subevents. This prevents a two-stage lookup since
most consumers will be keying on channel names instead of uniqueids.

(closes issue ASTERISK-22140)


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

The stasis_cache_update messages are somewhat cumbersome to handle
with the stasis_message_router. Since all updates have the same
message type, they are normally handled with the same route.

Since caching itself is a first class component of stasis-core, it
makes sense for the router to handle the cache update messages itself.
This patch adds stasis_message_router_add_cache_update() and
stasis_message_router_remove_cache_update() to handle the routing of
stasis_cache_update messages.

This patch also corrects an issue with manager_{bridging,channels}.c,
where events might be reordered. The reordering occurs because the
components use different message routers, which they needed because
they both needed to route cache update messages. They now both use
manager's router, and add cache routes for just the cache updates they
are interested in.

(closes issue ASTERISK-22038)
Review: https://reviewboard.asterisk.org/r/2677/


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

This adds new flags to the channel tech properties that flag it as
different types of implementation detail used exclusively to provide a
feature. Examples of channels that would have these flags include the
announcement and recording channels used by confbridge which are the
only two marked as such by this patch.

Review: https://reviewboard.asterisk.org/r/2633/
(closes issue ASTERISK-21873)


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

Refactor operations to access the stasis cache instead of objects directly when retrieving information.

(closes issue ASTERISK-21883)

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


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

This creates stasis messages that are sent during a blind or
attended transfer. The stasis messages also are converted to
AMI events.

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

(closes issue ASTERISK-21337)
Reported by Matt Jordan



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

Breaks many things until they can be reworked.  A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers


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