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
|
2004-09-24 21:33:48 +00:00
|
|
|
* Development of this app Sponsered/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
|
2005-09-15 15:44:26 +00:00
|
|
|
*
|
2005-11-06 15:09:47 +00:00
|
|
|
* \ingroup applications
|
2004-09-24 21:33:48 +00:00
|
|
|
*/
|
|
|
|
|
2006-06-07 18:54:56 +00:00
|
|
|
#include "asterisk.h"
|
|
|
|
|
|
|
|
ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
|
|
|
|
|
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
#include "asterisk/app.h"
|
2005-04-21 06:02:45 +00:00
|
|
|
#include "asterisk/module.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>
|
|
|
|
Forks the Call Data Record.
|
|
|
|
</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<parameter name="options">
|
|
|
|
<optionlist>
|
|
|
|
<option name="a">
|
|
|
|
<para>Update the answer time on the NEW CDR just after it's been inited.
|
2009-05-04 17:42:56 +00:00
|
|
|
The new CDR may have been answered already. The reset that forkcdr does
|
2008-11-04 18:06:50 +00:00
|
|
|
will erase the answer time. This will bring it back, but the answer time
|
|
|
|
will be a copy of the fork/start time. It will only do this if the initial
|
|
|
|
cdr was indeed already answered.</para>
|
|
|
|
</option>
|
|
|
|
<option name="A">
|
|
|
|
<para>Lock the original CDR against the answer time being updated. This
|
|
|
|
will allow the disposition on the original CDR to remain the same.</para>
|
|
|
|
</option>
|
|
|
|
<option name="d">
|
|
|
|
<para>Copy the disposition forward from the old cdr, after the init.</para>
|
|
|
|
</option>
|
|
|
|
<option name="D">
|
|
|
|
<para>Clear the <literal>dstchannel</literal> on the new CDR after
|
|
|
|
reset.</para>
|
|
|
|
</option>
|
|
|
|
<option name="e">
|
2009-05-04 17:42:56 +00:00
|
|
|
<para>End the original CDR. Do this after all the neccessry data is copied
|
|
|
|
from the original CDR to the new forked CDR.</para>
|
2008-11-04 18:06:50 +00:00
|
|
|
</option>
|
|
|
|
<option name="r">
|
|
|
|
<para>Do <emphasis>NOT</emphasis> reset the new cdr.</para>
|
|
|
|
</option>
|
|
|
|
<option name="s(name=val)">
|
|
|
|
<para>Set the CDR var <replaceable>name</replaceable> in the original CDR,
|
2008-11-05 01:44:04 +00:00
|
|
|
with value <replaceable>val</replaceable>.</para>
|
2008-11-04 18:06:50 +00:00
|
|
|
</option>
|
|
|
|
<option name="T">
|
|
|
|
<para>Mark the original CDR with a DONT_TOUCH flag. setvar, answer, and end
|
|
|
|
cdr funcs will obey this flag; normally they don't honor the LOCKED flag
|
|
|
|
set on the original CDR record.</para>
|
|
|
|
<note><para>Using this flag may cause CDR's not to have their end times
|
|
|
|
updated! It is suggested that if you specify this flag, you might wish
|
|
|
|
to use the <literal>e</literal> flag as well!.</para></note>
|
|
|
|
</option>
|
|
|
|
<option name="v">
|
|
|
|
<para>When the new CDR is forked, it gets a copy of the vars attached to
|
|
|
|
the current CDR. The vars attached to the original CDR are removed unless
|
|
|
|
this option is specified.</para>
|
|
|
|
</option>
|
|
|
|
</optionlist>
|
|
|
|
</parameter>
|
|
|
|
</syntax>
|
|
|
|
<description>
|
|
|
|
<para> Causes the Call Data Record to fork an additional cdr record starting from the time
|
|
|
|
of the fork call. This new cdr record will be linked to end of the list of cdr records attached
|
|
|
|
to the channel. The original CDR has a LOCKED flag set, which forces most cdr operations to skip
|
|
|
|
it, except for the functions that set the answer and end times, which ignore the LOCKED flag. This
|
|
|
|
allows all the cdr records in the channel to be 'ended' together when the channel is closed.</para>
|
|
|
|
<para>The CDR() func (when setting CDR values) normally ignores the LOCKED flag also, but has options
|
|
|
|
to vary its behavior. The 'T' option (described below), can override this behavior, but beware
|
|
|
|
the risks.</para>
|
|
|
|
<para>First, this app finds the last cdr record in the list, and makes a copy of it. This new copy
|
|
|
|
will be the newly forked cdr record. Next, this new record is linked to the end of the cdr record list.
|
|
|
|
Next, The new cdr record is RESET (unless you use an option to prevent this)</para>
|
|
|
|
<para>This means that:</para>
|
|
|
|
<para> 1. All flags are unset on the cdr record</para>
|
|
|
|
<para> 2. the start, end, and answer times are all set to zero.</para>
|
|
|
|
<para> 3. the billsec and duration fields are set to zero.</para>
|
|
|
|
<para> 4. the start time is set to the current time.</para>
|
|
|
|
<para> 5. the disposition is set to NULL.</para>
|
|
|
|
<para>Next, unless you specified the <literal>v</literal> option, all variables will be removed from
|
|
|
|
the original cdr record. Thus, the <literal>v</literal> option allows any CDR variables to be replicated
|
|
|
|
to all new forked cdr records. Without the <literal>v</literal> option, the variables on the original
|
|
|
|
are effectively moved to the new forked cdr record.</para>
|
|
|
|
<para>Next, if the <literal>s</literal> option is set, the provided variable and value are set on the
|
|
|
|
original cdr record.</para>
|
|
|
|
<para>Next, if the <literal>a</literal> option is given, and the original cdr record has an answer time
|
|
|
|
set, then the new forked cdr record will have its answer time set to its start time. If the old answer
|
|
|
|
time were carried forward, the answer time would be earlier than the start time, giving strange
|
|
|
|
duration and billsec times.</para>
|
|
|
|
<para>If the <literal>d</literal> option was specified, the disposition is copied from
|
|
|
|
the original cdr record to the new forked cdr. If the <literal>D</literal> option was specified,
|
|
|
|
the destination channel field in the new forked CDR is erased. If the <literal>e</literal> option
|
|
|
|
was specified, the 'end' time for the original cdr record is set to the current time. Future hang-up or
|
|
|
|
ending events will not override this time stamp. If the <literal>A</literal> option is specified,
|
|
|
|
the original cdr record will have it ANS_LOCKED flag set, which prevent future answer events from updating
|
|
|
|
the original cdr record's disposition. Normally, an <literal>ANSWERED</literal> event would mark all cdr
|
|
|
|
records in the chain as <literal>ANSWERED</literal>. If the <literal>T</literal> option is specified,
|
|
|
|
the original cdr record will have its <literal>DONT_TOUCH</literal> flag set, which will force the
|
|
|
|
cdr_answer, cdr_end, and cdr_setvar functions to leave that cdr record alone.</para>
|
|
|
|
<para>And, last but not least, the original cdr record has its LOCKED flag set. Almost all internal
|
|
|
|
CDR functions (except for the funcs that set the end, and answer times, and set a variable) will honor
|
|
|
|
this flag and leave a LOCKED cdr record alone. This means that the newly created forked cdr record
|
|
|
|
will be affected by events transpiring within Asterisk, with the previously noted exceptions.</para>
|
|
|
|
</description>
|
|
|
|
<see-also>
|
|
|
|
<ref type="function">CDR</ref>
|
|
|
|
<ref type="application">NoCDR</ref>
|
|
|
|
<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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
|
|
|
|
enum {
|
|
|
|
OPT_SETANS = (1 << 0),
|
|
|
|
OPT_SETDISP = (1 << 1),
|
|
|
|
OPT_RESETDEST = (1 << 2),
|
|
|
|
OPT_ENDCDR = (1 << 3),
|
|
|
|
OPT_NORESET = (1 << 4),
|
|
|
|
OPT_KEEPVARS = (1 << 5),
|
|
|
|
OPT_VARSET = (1 << 6),
|
Merged revisions 122046 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@122091 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-12 14:28:01 +00:00
|
|
|
OPT_ANSLOCK = (1 << 7),
|
|
|
|
OPT_DONTOUCH = (1 << 8),
|
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
OPT_ARG_VARSET = 0,
|
|
|
|
/* note: this entry _MUST_ be the last one in the enum */
|
|
|
|
OPT_ARG_ARRAY_SIZE,
|
|
|
|
};
|
|
|
|
|
|
|
|
AST_APP_OPTIONS(forkcdr_exec_options, {
|
|
|
|
AST_APP_OPTION('a', OPT_SETANS),
|
Merged revisions 122046 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@122091 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-12 14:28:01 +00:00
|
|
|
AST_APP_OPTION('A', OPT_ANSLOCK),
|
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
AST_APP_OPTION('d', OPT_SETDISP),
|
|
|
|
AST_APP_OPTION('D', OPT_RESETDEST),
|
|
|
|
AST_APP_OPTION('e', OPT_ENDCDR),
|
|
|
|
AST_APP_OPTION('R', OPT_NORESET),
|
|
|
|
AST_APP_OPTION_ARG('s', OPT_VARSET, OPT_ARG_VARSET),
|
Merged revisions 122046 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@122091 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-12 14:28:01 +00:00
|
|
|
AST_APP_OPTION('T', OPT_DONTOUCH),
|
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
AST_APP_OPTION('v', OPT_KEEPVARS),
|
|
|
|
});
|
|
|
|
|
|
|
|
static void ast_cdr_fork(struct ast_channel *chan, struct ast_flags optflags, char *set)
|
2005-02-23 22:48:47 +00:00
|
|
|
{
|
2005-07-25 22:56:18 +00:00
|
|
|
struct ast_cdr *cdr;
|
|
|
|
struct ast_cdr *newcdr;
|
2005-11-07 04:14:48 +00:00
|
|
|
struct ast_flags flags = { AST_CDR_FLAG_KEEP_VARS };
|
|
|
|
|
2005-11-16 18:21:10 +00:00
|
|
|
cdr = chan->cdr;
|
2005-11-07 04:14:48 +00:00
|
|
|
|
2005-07-25 22:56:18 +00:00
|
|
|
while (cdr->next)
|
|
|
|
cdr = cdr->next;
|
2005-11-07 04:14:48 +00:00
|
|
|
|
2005-07-25 22:56:18 +00:00
|
|
|
if (!(newcdr = ast_cdr_dup(cdr)))
|
|
|
|
return;
|
2005-11-07 04:14:48 +00:00
|
|
|
|
2005-07-25 22:56:18 +00:00
|
|
|
ast_cdr_append(cdr, newcdr);
|
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
|
|
|
|
if (!ast_test_flag(&optflags, OPT_NORESET))
|
|
|
|
ast_cdr_reset(newcdr, &flags);
|
|
|
|
|
2005-07-25 22:56:18 +00:00
|
|
|
if (!ast_test_flag(cdr, AST_CDR_FLAG_KEEP_VARS))
|
|
|
|
ast_cdr_free_vars(cdr, 0);
|
2005-11-07 04:14:48 +00:00
|
|
|
|
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
if (!ast_strlen_zero(set)) {
|
|
|
|
char *varname = ast_strdupa(set), *varval;
|
|
|
|
varval = strchr(varname,'=');
|
|
|
|
if (varval) {
|
|
|
|
*varval = 0;
|
|
|
|
varval++;
|
|
|
|
ast_cdr_setvar(cdr, varname, varval, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_test_flag(&optflags, OPT_SETANS) && !ast_tvzero(cdr->answer))
|
|
|
|
newcdr->answer = newcdr->start;
|
|
|
|
|
|
|
|
if (ast_test_flag(&optflags, OPT_SETDISP))
|
|
|
|
newcdr->disposition = cdr->disposition;
|
|
|
|
|
|
|
|
if (ast_test_flag(&optflags, OPT_RESETDEST))
|
|
|
|
newcdr->dstchannel[0] = 0;
|
|
|
|
|
|
|
|
if (ast_test_flag(&optflags, OPT_ENDCDR))
|
|
|
|
ast_cdr_end(cdr);
|
|
|
|
|
Merged revisions 122046 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@122091 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-12 14:28:01 +00:00
|
|
|
if (ast_test_flag(&optflags, OPT_ANSLOCK))
|
|
|
|
ast_set_flag(cdr, AST_CDR_FLAG_ANSLOCKED);
|
|
|
|
|
|
|
|
if (ast_test_flag(&optflags, OPT_DONTOUCH))
|
|
|
|
ast_set_flag(cdr, AST_CDR_FLAG_DONT_TOUCH);
|
|
|
|
|
2005-07-25 22:56:18 +00:00
|
|
|
ast_set_flag(cdr, AST_CDR_FLAG_CHILD | AST_CDR_FLAG_LOCKED);
|
2004-09-24 21:33:48 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
2005-11-16 18:21:10 +00:00
|
|
|
int res = 0;
|
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
char *argcopy = NULL;
|
|
|
|
struct ast_flags flags = {0};
|
|
|
|
char *opts[OPT_ARG_ARRAY_SIZE];
|
|
|
|
AST_DECLARE_APP_ARGS(arglist,
|
|
|
|
AST_APP_ARG(options);
|
|
|
|
);
|
2005-11-16 18:21:10 +00:00
|
|
|
|
|
|
|
if (!chan->cdr) {
|
|
|
|
ast_log(LOG_WARNING, "Channel does not have a CDR\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
argcopy = ast_strdupa(data);
|
|
|
|
|
|
|
|
AST_STANDARD_APP_ARGS(arglist, argcopy);
|
|
|
|
|
2008-06-22 02:58:06 +00:00
|
|
|
opts[OPT_ARG_VARSET] = 0;
|
|
|
|
|
|
|
|
if (!ast_strlen_zero(arglist.options))
|
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
ast_app_parse_options(forkcdr_exec_options, &flags, opts, arglist.options);
|
2008-08-10 14:45:25 +00:00
|
|
|
|
|
|
|
if (!ast_strlen_zero(data)) {
|
|
|
|
int keepvars = ast_test_flag(&flags, OPT_KEEPVARS) ? 1 : 0;
|
|
|
|
ast_set2_flag(chan->cdr, keepvars, AST_CDR_FLAG_KEEP_VARS);
|
|
|
|
}
|
2005-02-23 22:48:47 +00:00
|
|
|
|
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: http://svn.digium.com/svn/asterisk/trunk@118880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29 01:29:09 +00:00
|
|
|
ast_cdr_fork(chan, flags, opts[OPT_ARG_VARSET]);
|
2004-09-24 21:33:48 +00:00
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
static int unload_module(void)
|
2004-09-24 21:33:48 +00:00
|
|
|
{
|
2007-07-16 13:35:20 +00:00
|
|
|
return ast_unregister_application(app);
|
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
|
|
|
{
|
2008-11-04 18:06:50 +00:00
|
|
|
return ast_register_application_xml(app, forkcdr_exec);
|
2004-09-24 21:33:48 +00:00
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_MODULE_INFO_STANDARD(ASTERISK_GPL_KEY, "Fork The CDR into 2 separate entities");
|