2004-09-24 21:33:48 +00:00
|
|
|
/*
|
2005-09-15 15:44:26 +00:00
|
|
|
* Asterisk -- An open source telephony toolkit.
|
2004-09-24 21:33:48 +00:00
|
|
|
*
|
2005-09-15 15:44:26 +00:00
|
|
|
* Copyright (C) 1999 - 2005, Anthony Minessale anthmct@yahoo.com
|
2021-10-31 01:04:41 +00:00
|
|
|
* Development of this app Sponsored/Funded by TAAN Softworks Corp
|
2005-09-15 15:44:26 +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.
|
|
|
|
*
|
2004-09-24 21:33:48 +00:00
|
|
|
* This program is free software, distributed under the terms of
|
2005-09-15 15:44:26 +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
|
2005-09-15 15:44:26 +00:00
|
|
|
*
|
2005-10-24 20:12:06 +00:00
|
|
|
* \brief Fork CDR application
|
2005-12-30 21:18:06 +00:00
|
|
|
*
|
|
|
|
* \author Anthony Minessale anthmct@yahoo.com
|
|
|
|
*
|
2006-08-14 22:38:52 +00:00
|
|
|
* \note Development of this app Sponsored/Funded by TAAN Softworks Corp
|
2017-12-22 14:23:22 +00:00
|
|
|
*
|
2005-11-06 15:09:47 +00:00
|
|
|
* \ingroup applications
|
2004-09-24 21:33:48 +00:00
|
|
|
*/
|
|
|
|
|
2011-07-14 20:28:54 +00:00
|
|
|
/*** MODULEINFO
|
|
|
|
<support_level>core</support_level>
|
|
|
|
***/
|
|
|
|
|
2006-06-07 18:54:56 +00:00
|
|
|
#include "asterisk.h"
|
|
|
|
|
2005-04-21 06:02:45 +00:00
|
|
|
#include "asterisk/file.h"
|
|
|
|
#include "asterisk/channel.h"
|
|
|
|
#include "asterisk/pbx.h"
|
|
|
|
#include "asterisk/cdr.h"
|
Merged revisions 118858 via svnmerge from
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
2008-05-29 01:29:09 +00:00
|
|
|
#include "asterisk/app.h"
|
2005-04-21 06:02:45 +00:00
|
|
|
#include "asterisk/module.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"
|
2004-09-24 21:33:48 +00:00
|
|
|
|
2008-11-04 18:06:50 +00:00
|
|
|
/*** DOCUMENTATION
|
|
|
|
<application name="ForkCDR" language="en_US">
|
|
|
|
<synopsis>
|
2013-06-17 03:00:38 +00:00
|
|
|
Forks the current Call Data Record for this channel.
|
2008-11-04 18:06:50 +00:00
|
|
|
</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<parameter name="options">
|
|
|
|
<optionlist>
|
|
|
|
<option name="a">
|
2013-06-17 03:00:38 +00:00
|
|
|
<para>If the channel is answered, set the answer time on
|
|
|
|
the forked CDR to the current time. If this option is
|
|
|
|
not used, the answer time on the forked CDR will be the
|
|
|
|
answer time on the original CDR. If the channel is not
|
|
|
|
answered, this option has no effect.</para>
|
|
|
|
<para>Note that this option is implicitly assumed if the
|
|
|
|
<literal>r</literal> option is used.</para>
|
2008-11-04 18:06:50 +00:00
|
|
|
</option>
|
|
|
|
<option name="e">
|
2013-06-17 03:00:38 +00:00
|
|
|
<para>End (finalize) the original CDR.</para>
|
2008-11-04 18:06:50 +00:00
|
|
|
</option>
|
|
|
|
<option name="r">
|
2013-06-17 03:00:38 +00:00
|
|
|
<para>Reset the start and answer times on the forked CDR.
|
|
|
|
This will set the start and answer times (if the channel
|
|
|
|
is answered) to be set to the current time.</para>
|
|
|
|
<para>Note that this option implicitly assumes the
|
|
|
|
<literal>a</literal> option.</para>
|
2008-11-04 18:06:50 +00:00
|
|
|
</option>
|
|
|
|
<option name="v">
|
2013-06-17 03:00:38 +00:00
|
|
|
<para>Do not copy CDR variables and attributes from the
|
|
|
|
original CDR to the forked CDR.</para>
|
|
|
|
<warning><para>This option has changed. Previously, the
|
|
|
|
variables were removed from the original CDR. This no
|
|
|
|
longer occurs - this option now controls whether or not
|
|
|
|
a forked CDR inherits the variables from the original
|
|
|
|
CDR.</para></warning>
|
2008-11-04 18:06:50 +00:00
|
|
|
</option>
|
|
|
|
</optionlist>
|
|
|
|
</parameter>
|
|
|
|
</syntax>
|
|
|
|
<description>
|
2013-06-17 03:00:38 +00:00
|
|
|
<para>Causes the Call Data Record engine to fork a new CDR starting
|
|
|
|
from the time the application is executed. The forked CDR will be
|
|
|
|
linked to the end of the CDRs associated with the channel.</para>
|
2008-11-04 18:06:50 +00:00
|
|
|
</description>
|
|
|
|
<see-also>
|
|
|
|
<ref type="function">CDR</ref>
|
2022-12-22 01:58:54 +00:00
|
|
|
<ref type="function">CDR_PROP</ref>
|
2008-11-04 18:06:50 +00:00
|
|
|
<ref type="application">ResetCDR</ref>
|
|
|
|
</see-also>
|
|
|
|
</application>
|
|
|
|
***/
|
Merged revisions 118858 via svnmerge from
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
2008-05-29 01:29:09 +00:00
|
|
|
|
2008-11-04 18:06:50 +00:00
|
|
|
static char *app = "ForkCDR";
|
Merged revisions 118858 via svnmerge from
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
2008-05-29 01:29:09 +00:00
|
|
|
|
|
|
|
AST_APP_OPTIONS(forkcdr_exec_options, {
|
2013-06-17 03:00:38 +00:00
|
|
|
AST_APP_OPTION('a', AST_CDR_FLAG_SET_ANSWER),
|
|
|
|
AST_APP_OPTION('e', AST_CDR_FLAG_FINALIZE),
|
|
|
|
AST_APP_OPTION('r', AST_CDR_FLAG_RESET),
|
|
|
|
AST_APP_OPTION('v', AST_CDR_FLAG_KEEP_VARS),
|
Merged revisions 118858 via svnmerge from
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
2008-05-29 01:29:09 +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
|
|
|
STASIS_MESSAGE_TYPE_DEFN_LOCAL(forkcdr_message_type);
|
|
|
|
|
|
|
|
/*! \internal \brief Message payload for the Stasis message sent to fork the CDR */
|
|
|
|
struct fork_cdr_message_payload {
|
|
|
|
/*! The name of the channel whose CDR will be forked */
|
|
|
|
const char *channel_name;
|
|
|
|
/*! Option flags that control how the CDR will be forked */
|
|
|
|
struct ast_flags *flags;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void forkcdr_callback(void *data, struct stasis_subscription *sub, struct stasis_message *message)
|
|
|
|
{
|
|
|
|
struct fork_cdr_message_payload *payload;
|
|
|
|
|
|
|
|
if (stasis_message_type(message) != forkcdr_message_type()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
payload = stasis_message_data(message);
|
|
|
|
if (!payload) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_cdr_fork(payload->channel_name, payload->flags)) {
|
|
|
|
ast_log(AST_LOG_WARNING, "Failed to fork CDR for channel %s\n",
|
|
|
|
payload->channel_name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-05-21 21:13:09 +00:00
|
|
|
static int forkcdr_exec(struct ast_channel *chan, const char *data)
|
2004-09-24 21:33:48 +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 stasis_message *, message, NULL, ao2_cleanup);
|
2014-08-06 12:55:28 +00:00
|
|
|
RAII_VAR(struct fork_cdr_message_payload *, payload, 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
|
|
|
|
2013-06-17 03:00:38 +00:00
|
|
|
char *parse;
|
|
|
|
struct ast_flags flags = { 0, };
|
|
|
|
AST_DECLARE_APP_ARGS(args,
|
Merged revisions 118858 via svnmerge from
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
2008-05-29 01:29:09 +00:00
|
|
|
AST_APP_ARG(options);
|
|
|
|
);
|
2005-11-16 18:21:10 +00:00
|
|
|
|
2013-06-17 03:00:38 +00:00
|
|
|
parse = ast_strdupa(data);
|
Merged revisions 118858 via svnmerge from
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
2008-05-29 01:29:09 +00:00
|
|
|
|
2013-06-17 03:00:38 +00:00
|
|
|
AST_STANDARD_APP_ARGS(args, parse);
|
Merged revisions 118858 via svnmerge from
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
2008-05-29 01:29:09 +00:00
|
|
|
|
2013-06-17 03:00:38 +00:00
|
|
|
if (!ast_strlen_zero(args.options)) {
|
|
|
|
ast_app_parse_options(forkcdr_exec_options, &flags, NULL, args.options);
|
|
|
|
}
|
2008-08-10 14:45:25 +00:00
|
|
|
|
2014-08-06 12:55:28 +00:00
|
|
|
if (!forkcdr_message_type()) {
|
|
|
|
ast_log(AST_LOG_WARNING, "Failed to manipulate CDR for channel %s: no message type\n",
|
|
|
|
ast_channel_name(chan));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
payload = ao2_alloc(sizeof(*payload), NULL);
|
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;
|
|
|
|
}
|
|
|
|
|
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));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
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->flags = &flags;
|
|
|
|
message = stasis_message_create(forkcdr_message_type(), payload);
|
|
|
|
if (!message) {
|
|
|
|
ast_log(AST_LOG_WARNING, "Failed to fork CDR for channel %s: unable to create message\n",
|
|
|
|
ast_channel_name(chan));
|
|
|
|
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
|
|
|
|
2013-06-17 03:00:38 +00:00
|
|
|
return 0;
|
2004-09-24 21:33:48 +00:00
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
static int unload_module(void)
|
2004-09-24 21:33:48 +00:00
|
|
|
{
|
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) {
|
|
|
|
stasis_message_router_remove(router, forkcdr_message_type());
|
|
|
|
}
|
|
|
|
STASIS_MESSAGE_TYPE_CLEANUP(forkcdr_message_type);
|
|
|
|
ast_unregister_application(app);
|
|
|
|
return 0;
|
2004-09-24 21:33:48 +00:00
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
static int load_module(void)
|
2004-09-24 21:33:48 +00:00
|
|
|
{
|
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
|
|
|
int res = 0;
|
|
|
|
|
2014-01-12 22:13:12 +00:00
|
|
|
if (!router) {
|
2017-04-11 16:07:39 +00:00
|
|
|
return AST_MODULE_LOAD_DECLINE;
|
2014-01-12 22:13:12 +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
|
|
|
res |= STASIS_MESSAGE_TYPE_INIT(forkcdr_message_type);
|
|
|
|
res |= ast_register_application_xml(app, forkcdr_exec);
|
2014-01-12 22:13:12 +00:00
|
|
|
res |= stasis_message_router_add(router, forkcdr_message_type(),
|
|
|
|
forkcdr_callback, NULL);
|
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 (res) {
|
2017-04-11 16:07:39 +00:00
|
|
|
unload_module();
|
|
|
|
|
|
|
|
return AST_MODULE_LOAD_DECLINE;
|
2014-01-12 22:13:12 +00:00
|
|
|
}
|
|
|
|
return AST_MODULE_LOAD_SUCCESS;
|
2004-09-24 21:33:48 +00:00
|
|
|
}
|
|
|
|
|
2018-02-17 03:11:42 +00:00
|
|
|
AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_DEFAULT, "Fork The CDR into 2 separate entities",
|
|
|
|
.support_level = AST_MODULE_SUPPORT_CORE,
|
|
|
|
.load = load_module,
|
|
|
|
.unload = unload_module,
|
|
|
|
.requires = "cdr",
|
|
|
|
);
|