Age | Commit message (Collapse) | Author |
|
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
|
|
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
|
|
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
|
|
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
|
|
again :-)
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
|
|
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
|
|
STANDARD_HANGUP_LOCALUSERS
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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@6213 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
of usses to use the new functions (bug #4504)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@6146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@5867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(bug #4058)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@5490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@5257 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@5068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@5034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@4748 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@4298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@4060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@3832 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|