2003-09-18 21:17:14 +00:00
|
|
|
/*
|
2005-09-14 20:46:50 +00:00
|
|
|
* Asterisk -- An open source telephony toolkit.
|
2003-09-18 21:17:14 +00:00
|
|
|
*
|
2005-09-14 20:46:50 +00:00
|
|
|
* Copyright (C) 1999 - 2005, Digium, Inc.
|
2003-09-18 21:17:14 +00:00
|
|
|
*
|
2003-09-18 21:52:01 +00:00
|
|
|
* Martin Pycko <martinp@digium.com>
|
2003-09-18 21:17:14 +00:00
|
|
|
*
|
2005-09-14 20:46:50 +00:00
|
|
|
* See http://www.asterisk.org for more information about
|
|
|
|
* the Asterisk project. Please do not directly contact
|
|
|
|
* any of the maintainers of this project for assistance;
|
|
|
|
* the project provides a web site, mailing lists and IRC
|
|
|
|
* channels for your use.
|
|
|
|
*
|
2003-09-18 21:17:14 +00:00
|
|
|
* This program is free software, distributed under the terms of
|
2005-09-14 20:46:50 +00:00
|
|
|
* the GNU General Public License Version 2. See the LICENSE file
|
|
|
|
* at the top of the source tree.
|
|
|
|
*/
|
|
|
|
|
2005-10-24 20:12:06 +00:00
|
|
|
/*! \file
|
2008-02-09 11:27:10 +00:00
|
|
|
*
|
2005-10-24 20:12:06 +00:00
|
|
|
* \brief Applications connected with CDR engine
|
2005-09-14 20:46:50 +00:00
|
|
|
*
|
2006-10-31 06:37:48 +00:00
|
|
|
* \author Martin Pycko <martinp@digium.com>
|
2005-12-30 21:18:06 +00:00
|
|
|
*
|
2005-11-06 15:09:47 +00:00
|
|
|
* \ingroup applications
|
2003-09-18 21:17:14 +00:00
|
|
|
*/
|
|
|
|
|
2011-07-14 20:28:54 +00:00
|
|
|
/*** MODULEINFO
|
|
|
|
<support_level>core</support_level>
|
|
|
|
***/
|
|
|
|
|
2005-06-06 22:39:32 +00:00
|
|
|
#include "asterisk.h"
|
|
|
|
|
2005-04-21 06:02:45 +00:00
|
|
|
#include "asterisk/channel.h"
|
|
|
|
#include "asterisk/module.h"
|
2013-06-17 03:00:38 +00:00
|
|
|
#include "asterisk/app.h"
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
#include "asterisk/stasis.h"
|
2014-01-12 22:13:12 +00:00
|
|
|
#include "asterisk/stasis_message_router.h"
|
2003-09-18 21:17:14 +00:00
|
|
|
|
2008-11-01 21:10:07 +00:00
|
|
|
/*** DOCUMENTATION
|
|
|
|
<application name="NoCDR" language="en_US">
|
|
|
|
<synopsis>
|
2013-06-17 03:00:38 +00:00
|
|
|
Tell Asterisk to not maintain a CDR for this channel.
|
2008-11-01 21:10:07 +00:00
|
|
|
</synopsis>
|
|
|
|
<syntax />
|
|
|
|
<description>
|
2013-06-17 03:00:38 +00:00
|
|
|
<para>This application will tell Asterisk not to maintain a CDR for
|
|
|
|
the current channel. This does <emphasis>NOT</emphasis> mean that
|
|
|
|
information is not tracked; rather, if the channel is hung up no
|
|
|
|
CDRs will be created for that channel.</para>
|
|
|
|
<para>If a subsequent call to ResetCDR occurs, all non-finalized
|
|
|
|
CDRs created for the channel will be enabled.</para>
|
|
|
|
<note><para>This application is deprecated. Please use the CDR_PROP
|
|
|
|
function to disable CDRs on a channel.</para></note>
|
2008-11-01 21:10:07 +00:00
|
|
|
</description>
|
2013-06-17 03:00:38 +00:00
|
|
|
<see-also>
|
|
|
|
<ref type="application">ResetCDR</ref>
|
|
|
|
<ref type="function">CDR_PROP</ref>
|
|
|
|
</see-also>
|
|
|
|
</application>
|
|
|
|
<application name="ResetCDR" language="en_US">
|
|
|
|
<synopsis>
|
|
|
|
Resets the Call Data Record.
|
|
|
|
</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<parameter name="options">
|
|
|
|
<optionlist>
|
|
|
|
<option name="v">
|
|
|
|
<para>Save the CDR variables during the reset.</para>
|
|
|
|
</option>
|
|
|
|
<option name="e">
|
|
|
|
<para>Enable the CDRs for this channel only (negate
|
|
|
|
effects of NoCDR).</para>
|
|
|
|
</option>
|
|
|
|
</optionlist>
|
|
|
|
</parameter>
|
|
|
|
</syntax>
|
|
|
|
<description>
|
|
|
|
<para>This application causes the Call Data Record to be reset.
|
|
|
|
Depending on the flags passed in, this can have several effects.
|
|
|
|
With no options, a reset does the following:</para>
|
|
|
|
<para>1. The <literal>start</literal> time is set to the current time.</para>
|
|
|
|
<para>2. If the channel is answered, the <literal>answer</literal> time is set to the
|
|
|
|
current time.</para>
|
|
|
|
<para>3. All variables are wiped from the CDR. Note that this step
|
|
|
|
can be prevented with the <literal>v</literal> option.</para>
|
|
|
|
<para>On the other hand, if the <literal>e</literal> option is
|
|
|
|
specified, the effects of the NoCDR application will be lifted. CDRs
|
|
|
|
will be re-enabled for this channel.</para>
|
|
|
|
<note><para>The <literal>e</literal> option is deprecated. Please
|
|
|
|
use the CDR_PROP function instead.</para></note>
|
|
|
|
</description>
|
|
|
|
<see-also>
|
|
|
|
<ref type="application">ForkCDR</ref>
|
|
|
|
<ref type="application">NoCDR</ref>
|
|
|
|
<ref type="function">CDR_PROP</ref>
|
|
|
|
</see-also>
|
2008-11-01 21:10:07 +00:00
|
|
|
</application>
|
|
|
|
***/
|
2003-09-18 21:17:14 +00:00
|
|
|
|
2009-05-21 21:13:09 +00:00
|
|
|
static const char nocdr_app[] = "NoCDR";
|
2013-06-17 03:00:38 +00:00
|
|
|
static const char resetcdr_app[] = "ResetCDR";
|
|
|
|
|
|
|
|
enum reset_cdr_options {
|
|
|
|
OPT_DISABLE_DISPATCH = (1 << 0),
|
|
|
|
OPT_KEEP_VARS = (1 << 1),
|
|
|
|
OPT_ENABLE = (1 << 2),
|
|
|
|
};
|
|
|
|
|
|
|
|
AST_APP_OPTIONS(resetcdr_opts, {
|
|
|
|
AST_APP_OPTION('v', AST_CDR_FLAG_KEEP_VARS),
|
|
|
|
AST_APP_OPTION('e', AST_CDR_FLAG_DISABLE_ALL),
|
|
|
|
});
|
|
|
|
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
STASIS_MESSAGE_TYPE_DEFN_LOCAL(appcdr_message_type);
|
|
|
|
|
|
|
|
/*! \internal \brief Payload for the Stasis message sent to manipulate a CDR */
|
|
|
|
struct app_cdr_message_payload {
|
|
|
|
/*! The name of the channel to be manipulated */
|
|
|
|
const char *channel_name;
|
|
|
|
/*! Disable the CDR for this channel */
|
|
|
|
int disable:1;
|
|
|
|
/*! Re-enable the CDR for this channel */
|
|
|
|
int reenable:1;
|
|
|
|
/*! Reset the CDR */
|
|
|
|
int reset:1;
|
|
|
|
/*! If reseting the CDR, keep the variables */
|
|
|
|
int keep_variables:1;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void appcdr_callback(void *data, struct stasis_subscription *sub, struct stasis_message *message)
|
|
|
|
{
|
|
|
|
struct app_cdr_message_payload *payload;
|
|
|
|
|
|
|
|
if (stasis_message_type(message) != appcdr_message_type()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
payload = stasis_message_data(message);
|
|
|
|
if (!payload) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (payload->disable) {
|
|
|
|
if (ast_cdr_set_property(payload->channel_name, AST_CDR_FLAG_DISABLE_ALL)) {
|
|
|
|
ast_log(AST_LOG_WARNING, "Failed to disable CDRs on channel %s\n",
|
|
|
|
payload->channel_name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (payload->reenable) {
|
|
|
|
if (ast_cdr_clear_property(payload->channel_name, AST_CDR_FLAG_DISABLE_ALL)) {
|
|
|
|
ast_log(AST_LOG_WARNING, "Failed to enable CDRs on channel %s\n",
|
|
|
|
payload->channel_name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (payload->reset) {
|
|
|
|
if (ast_cdr_reset(payload->channel_name, payload->keep_variables)) {
|
|
|
|
ast_log(AST_LOG_WARNING, "Failed to reset CDRs on channel %s\n",
|
|
|
|
payload->channel_name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int publish_app_cdr_message(struct ast_channel *chan, struct app_cdr_message_payload *payload)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct stasis_message *, message, NULL, ao2_cleanup);
|
2014-01-12 22:13:12 +00:00
|
|
|
RAII_VAR(struct stasis_message_router *, router, ast_cdr_message_router(), ao2_cleanup);
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
|
2014-01-12 22:13:12 +00:00
|
|
|
if (!router) {
|
|
|
|
ast_log(AST_LOG_WARNING, "Failed to manipulate CDR for channel %s: no message router\n",
|
|
|
|
ast_channel_name(chan));
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2014-01-12 22:13:12 +00:00
|
|
|
message = stasis_message_create(appcdr_message_type(), payload);
|
|
|
|
if (!message) {
|
|
|
|
ast_log(AST_LOG_WARNING, "Failed to manipulate CDR for channel %s: unable to create message\n",
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
payload->channel_name);
|
|
|
|
return -1;
|
|
|
|
}
|
2014-01-12 22:13:12 +00:00
|
|
|
stasis_message_router_publish_sync(router, message);
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-06-17 03:00:38 +00:00
|
|
|
static int resetcdr_exec(struct ast_channel *chan, const char *data)
|
|
|
|
{
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
RAII_VAR(struct app_cdr_message_payload *, payload,
|
|
|
|
ao2_alloc(sizeof(*payload), NULL), ao2_cleanup);
|
2013-06-17 03:00:38 +00:00
|
|
|
char *args;
|
|
|
|
struct ast_flags flags = { 0 };
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
|
|
|
|
if (!payload) {
|
|
|
|
return -1;
|
|
|
|
}
|
2013-06-17 03:00:38 +00:00
|
|
|
|
|
|
|
if (!ast_strlen_zero(data)) {
|
|
|
|
args = ast_strdupa(data);
|
|
|
|
ast_app_parse_options(resetcdr_opts, &flags, NULL, args);
|
|
|
|
}
|
|
|
|
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
payload->channel_name = ast_channel_name(chan);
|
|
|
|
payload->reset = 1;
|
|
|
|
|
2013-06-17 03:00:38 +00:00
|
|
|
if (ast_test_flag(&flags, AST_CDR_FLAG_DISABLE_ALL)) {
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
payload->reenable = 1;
|
2013-06-17 03:00:38 +00:00
|
|
|
}
|
|
|
|
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
if (ast_test_flag(&flags, AST_CDR_FLAG_KEEP_VARS)) {
|
|
|
|
payload->keep_variables = 1;
|
2013-06-17 03:00:38 +00:00
|
|
|
}
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
|
|
|
|
return publish_app_cdr_message(chan, payload);
|
2013-06-17 03:00:38 +00:00
|
|
|
}
|
2003-09-18 21:17:14 +00:00
|
|
|
|
2009-05-21 21:13:09 +00:00
|
|
|
static int nocdr_exec(struct ast_channel *chan, const char *data)
|
2003-09-18 21:17:14 +00:00
|
|
|
{
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
RAII_VAR(struct app_cdr_message_payload *, payload,
|
|
|
|
ao2_alloc(sizeof(*payload), NULL), ao2_cleanup);
|
|
|
|
|
|
|
|
if (!payload) {
|
|
|
|
return -1;
|
2013-06-17 03:00:38 +00:00
|
|
|
}
|
2005-10-19 18:19:02 +00:00
|
|
|
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
payload->channel_name = ast_channel_name(chan);
|
|
|
|
payload->disable = 1;
|
|
|
|
|
|
|
|
return publish_app_cdr_message(chan, payload);
|
2003-09-18 21:17:14 +00:00
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
static int unload_module(void)
|
2003-09-18 21:17:14 +00:00
|
|
|
{
|
2014-01-12 22:13:12 +00:00
|
|
|
RAII_VAR(struct stasis_message_router *, router, ast_cdr_message_router(), ao2_cleanup);
|
|
|
|
|
|
|
|
if (router) {
|
|
|
|
stasis_message_router_remove(router, appcdr_message_type());
|
|
|
|
}
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
STASIS_MESSAGE_TYPE_CLEANUP(appcdr_message_type);
|
2013-09-27 21:58:05 +00:00
|
|
|
ast_unregister_application(nocdr_app);
|
|
|
|
ast_unregister_application(resetcdr_app);
|
|
|
|
return 0;
|
2003-09-18 21:17:14 +00:00
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
static int load_module(void)
|
2003-09-18 21:17:14 +00:00
|
|
|
{
|
2014-01-12 22:13:12 +00:00
|
|
|
RAII_VAR(struct stasis_message_router *, router, ast_cdr_message_router(), ao2_cleanup);
|
2013-06-17 03:00:38 +00:00
|
|
|
int res = 0;
|
|
|
|
|
2014-01-12 22:13:12 +00:00
|
|
|
if (!router) {
|
|
|
|
return AST_MODULE_LOAD_FAILURE;
|
|
|
|
}
|
|
|
|
|
app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
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
2013-12-19 00:50:01 +00:00
|
|
|
res |= STASIS_MESSAGE_TYPE_INIT(appcdr_message_type);
|
2013-06-17 03:00:38 +00:00
|
|
|
res |= ast_register_application_xml(nocdr_app, nocdr_exec);
|
|
|
|
res |= ast_register_application_xml(resetcdr_app, resetcdr_exec);
|
2014-01-12 22:13:12 +00:00
|
|
|
res |= stasis_message_router_add(router, appcdr_message_type(),
|
|
|
|
appcdr_callback, NULL);
|
2013-06-17 03:00:38 +00:00
|
|
|
|
|
|
|
if (res) {
|
2007-12-26 20:02:27 +00:00
|
|
|
return AST_MODULE_LOAD_FAILURE;
|
2013-06-17 03:00:38 +00:00
|
|
|
}
|
2007-12-26 20:02:27 +00:00
|
|
|
return AST_MODULE_LOAD_SUCCESS;
|
2003-09-18 21:17:14 +00:00
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_MODULE_INFO_STANDARD(ASTERISK_GPL_KEY, "Tell Asterisk to not maintain a CDR for the current call");
|