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

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


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

In https://reviewboard.asterisk.org/r/3057/, applications and functions that
manipulate CDRs were made to interact over Stasis. This was done to
synchronize manipulations of CDRs from the dialplan with the updates the
engine itself receives over the message bus.

This change rested on a faulty premise: that messages published to the CDR
topic or to a topic that forwards to the CDR topic are synchronized with the
messages handled by the CDR topic subscription in the CDR engine. This is not
the case. There is no ordering guaranteed for two messages published to the
same topic; ordering is only guaranteed if a message is published to the same
subscriber.

Stasis was modified in r405311 to allow a publisher to synchronize on the
subscriber. This patch uses that API to synchronize the CDR publishers with
the CDR engine message router, which maintains the overall topic subscription.

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

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

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


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

When doing the rework of the CDR engine that pushed all of the logic into cdr.c
and made it respond to changes in channel state over Stasis, we knew that
accessing the CDR engine from the dialplan would be "slightly"
non-deterministic. Dialplan threads would be accessing CDRs while Stasis
threads would be updating the state of said CDRs - whereas in the past,
everything happened on the dialplan threads. Tests have shown that "slightly"
is in reality "very".

This patch synchronizes things by making the dialplan applications/functions
that manipulate CDRs do so over Stasis. ForkCDR, NoCDR, ResetCDR, CDR, and
CDR_PROP now all use Stasis to send their requests over to the CDR engine,
and synchronize on the channel Stasis topic via a subscription so that they
return their values/control to the dialplan at the appropriate time.

While going through this, the following changes were also made:
 * DISA, which can reset the CDR when a user successfully authenticates, now
   just uses the ResetCDR app to do this. This prevents having to duplicate
   the same Stasis synchronization logic in that application.
 * Answer no longer disables CDRs. It actually didn't work anyway - calling
   DISABLE on the channel's CDR doesn't stop the CDR from getting the Answer
   time - it just kills all CDRs on that channel, which isn't what the caller
   would intend.

(closes issue ASTERISK-22884)
(closes issue ASTERISK-22886)

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

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


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

This patch is the initial push to update Asterisk's CDR engine for the new
bridging framework. This patch guts the existing CDR engine and builds the new
on top of messages coming across Stasis. As changes in channel state and bridge
state are detected, CDRs are built and dispatched accordingly. This
fundamentally changes CDRs in a few ways.
(1) CDRs are now *very* reflective of the actual state of channels and bridges.
    This means CDRs track well with what an actual channel is doing - which
    is useful in transfer scenarios (which were previously difficult to pin
    down). It does, however, mean that CDRs cannot be 'fooled'. Previous
    behavior in Asterisk allowed for CDR applications, channels, and other
    properties to be spoofed in parts of the code - this no longer works.
(2) CDRs have defined behavior in multi-party scenarios. This behavior will not
    be what everyone wants, but it is a defined behavior and as such, it is
    predictable.
(3) The CDR manipulation functions and applications have been overhauled. Major
    changes have been made to ResetCDR and ForkCDR in particular. Many of the
    options for these two applications no longer made any sense with the new
    framework and the (slightly) more immutable nature of CDRs.

There are a plethora of other changes. For a full description of CDR behavior,
see the CDR specification on the Asterisk wiki.

(closes issue ASTERISK-21196)

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



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

Prior to this patch, ForkCDR's e option would immediately set the end time of the forked
CDR to that of the CDR that is being terminated. This resulted in the new CDR's end time
being roughly the same as it's beginning time (which is in turn roughly the same as the
original's end time).

(closes issue ASTERISK-19164)
Reported by: Steve Davies
Patches:
	cdr_fork_end.v10.patch uploaded by Steve Davies (license 5012)
........

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

Merged revisions 362084 from http://svn.asterisk.org/svn/asterisk/branches/10


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

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


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

https://origsvn.digium.com/svn/asterisk/branches/1.10

................
  r328247 | lmadsen | 2011-07-14 16:25:31 -0400 (Thu, 14 Jul 2011) | 14 lines
  
  Merged revisions 328209 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.8
  
  ........
    r328209 | lmadsen | 2011-07-14 16:13:06 -0400 (Thu, 14 Jul 2011) | 6 lines
    
    Introduce <support_level> tags in MODULEINFO.
    This change introduces MODULEINFO into many modules in Asterisk in order to show
    the community support level for those modules. This is used by changes committed
    to menuselect by Russell Bryant recently (r917 in menuselect). More information about
    the support level types and what they mean is available on the wiki at
    https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States
  ........
................


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

This patch adds a sequence field to CDRs that can be combined with the linkedid or uniqueid field to uniquely identify a CDR.

(closes issue #15180)
Reported by: Nick_Lewis
Patches:
      cdr-sequence10.diff uploaded by mnicholson (license 96)
Tested by: mnicholson


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

(closes issue #15595)
Reported by: alecdavis



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

This patch adds 'const' tags to a number of Asterisk APIs where they are appropriate (where the API already demanded that the function argument not be modified, but the compiler was not informed of that fact). The list includes:

- CLI command handlers
- CLI command handler arguments
- AGI command handlers
- AGI command handler arguments
- Dialplan application handler arguments
- Speech engine API function arguments

In addition, various file-scope and function-scope constant arrays got 'const' and/or 'static' qualifiers where they were missing.

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



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

(issue #14801)


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

- Fix a dot that was outside of the <para> in the ForkCDR() XML documentation.


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

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

app_voicemail and app_queue.


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

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r124540 | murf | 2008-06-21 20:54:52 -0600 (Sat, 21 Jun 2008) | 9 lines

(closes issue #12910)
Reported by: chris-mac

Sorry, my testing did not contain the simple case of forkCDR(v),
I am much embarrassed to admit.  If I had, I would have 
more solidly initialized the opts element for varset.



........


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

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r122127 | murf | 2008-06-12 08:51:44 -0600 (Thu, 12 Jun 2008) | 1 line

Arkadia tried to warn me, but the code added to ast_cdr_busy, _failed, and _noanswer was redundant. Didn't spot it until I was resolving conflicts in trunk. Ugh. Redundant code removed. It wasn't harmful. Just dumb.
........


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

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r122046 | murf | 2008-06-12 07:47:34 -0600 (Thu, 12 Jun 2008) | 37 lines

(closes issue #10668)
Reported by: arkadia
Tested by: murf, arkadia

Options added to forkCDR() app and the CDR() func to
remove some roadblocks for CDR applications.

The "show application ForkCDR" output was upgraded
to more fully explain the inner workings of forkCDR.

The A option was added to forkCDR to force the
CDR system to NOT change the disposition on the
original CDR, after the fork. This involves
ast_cdr_answer, _busy, _failed, and so on.

The T option was added to forkCDR to force 
obedience of the cdr LOCKED flag in the
ast_cdr_end, all the disposition changing
funcs (ast_cdr_answer, etc), and in the
ast_cdr_setvar func.

The CHANGES file was updated to explain ALL
the new options added to satisfy this bug report
(and some requests made verbally and via 
email, irc, etc, over the past months/year)

The 's' option was added to the CDR() func,
to force it to skip LOCKED cdr's in the
chain.

Again, the new options should be totally transparent
to existing apps! Current behavior of CDR,
forkCDR, and the rest of the CDR system should
not change one little bit. Until you add the
new options, at least!


........


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

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r118858 | murf | 2008-05-28 18:25:28 -0600 (Wed, 28 May 2008) | 46 lines

(closes issue #10668)
(closes issue #11721)
(closes issue #12726)
Reported by: arkadia
Tested by: murf

These changes:

1. revert the changes made via bug 10668; 
   I should have known that such changes,
   even tho they made sense at the time,
   seemed like an omission, etc, were actually
   integral to the CDR system via forkCDR.
   It makes sense to me now that forkCDR didn't
   natively end any CDR's, but rather depended
   on natively closing them all at hangup time
   via traversing and closing them all, whether
   locked or not. I still don't completely 
   understand the benefits of setvar and answer
   operating on locked cdrs, but I've seen 
   enough to revert those changes also, and
   stop messing up users who depended on that
   behavior. bug 12726 found reverting the changes
   fixed his changes, and after a long review
   and working on forkCDR, I can see why.
2. Apply the suggested enhancements proposed
   in 10668, but in a completely compatible
   way. ForkCDR will behave exactly as before,
   but now has new options that will allow some
   actions to be taken that will slightly 
   modify the outcome and side-effects of
   forkCDR. Based on conversations I've had 
   with various people, these small tweaks
   will allow some users to get the behavior
   they need. For instance, users executing
   forkCDR in an AGI script will find the
   answer time set, and DISPOSITION set, 
   a situation not covered when the routines
  were first written.
3. A small problem in the cdr serializer
   would output answer and end times even
   when they were not set. This is now 
   fixed.



........


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

were included almost everywhere.
Remove some of the instances.



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

build times - tested, there is no measureable difference before and
after this commit.

In this change:

use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h

Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.

Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better. 

For the time being I have left alone second-level directories
(main/db1-ast, etc.).



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

(closes issue #11171, reported and patched by blitzrage)

Many thanks!



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

Applications no longer need to call ast_module_user_add and ast_module_user_remove. This is now taken care of in the pbx_exec function outside of the application.


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

It is no longer required for each module that deals with a channel to call ast_module_user_hangup_all in it's unload function. The loader will automatically perform this action for it.


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

  - restructured build tree and makefiles to eliminate recursion problems
  - support for embedded modules
  - support for static builds
  - simpler cross-compilation support
  - simpler module/loader interface (no exported symbols)



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

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

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

 
As partly documented in loader.c and include/asterisk/module.h,
modules are now expected to return all of their methods and flags
into a structure 'mod_data', and are normally loaded with RTLD_NOW
| RTLD_LOCAL, so symbols are resolved immediately and conflicts
should be less likely.  Only in a small number of cases (res_*,
typically) modules are loaded RTLD_GLOBAL, so they can export
symbols.
 
The core of the change is only the two files loader.c and
include/asterisk/module.h, all the rest is simply adaptation of the
existing modules to the new API, a rather mechanical (but believe
me, time and finger-consuming!) process whose detail you can figure
out by svn diff'ing any single module.

Expect some minor compilation issue after this change, please
report it on mantis http://bugs.digium.com/view.php?id=6968
so we collect all the feedback in one place.

I am just sorry that this change missed SVN version number 20000!



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

since the module API is changing, it's a good time to const-ify the description() and key() return values


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

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

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

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

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

add missing includes of stdio.h
remove some unused and duplicate headers


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

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

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

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

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

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

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