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
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
This commit introduces the first phase of an effort to manage documentation of the
interfaces in Asterisk in an XML format. Currently, a new format is available for
applications and dialplan functions. A good number of conversions to the new format
are also included.
For more information, see the following message to asterisk-dev:
http://lists.digium.com/pipermail/asterisk-dev/2008-October/034968.html
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In this commit:
- move the ast_register/unregister_app functions to module.h
to avoid the need to include pbx.h for the simpler apps;
- move the ast_group structure to channel.h to remove the
dependency of app.h on linkedlists.h
Note, this is a long process that I am doing in small steps.
The main difficulty is that now for each subsystem we
have a single header (e.g. channel.h) included by the subsystem
provider (usually one file, e.g. channel.c) and by its clients
(dozens of them, e.g. we have some 70+ apps and 30+ functions).
This requires the clients to include all the extra headers
required by the provider (eg. lock.h, linkedlists.h, definitions
of substructures...) even though many of the clients would be
just happy with opaque struct declarations and function prototypes.
The long term plan is to eventually rectify this structure
so that the compilation can become faster, and also APIs
are more stable.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89522 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
- 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
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
In general, LOCAL_USER_ADD/REMOVE should be the first/last thing called in an
application. An exception is if there is some *fast* setup code that might
halt the execution of the application, such as checking to see if an argument
exists.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@6832 65c4cc65-6c06-0410-ace0-fbb531ad65f3