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
|
|
|
|
|
|
|
static char *app = "ForkCDR";
|
|
|
|
static char *synopsis =
|
2004-10-23 12:17:46 +00:00
|
|
|
"Forks the Call Data Record";
|
|
|
|
static char *descrip =
|
2005-02-23 22:48:47 +00:00
|
|
|
" ForkCDR([options]): Causes the Call Data Record to fork an additional\n"
|
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
|
|
|
"cdr record starting from the time of the fork call. This new cdr record will\n"
|
|
|
|
"be linked to end of the list of cdr records attached to the channel. The original CDR is\n"
|
|
|
|
"has a LOCKED flag set, which forces most cdr operations to skip it, except\n"
|
|
|
|
"for the functions that set the answer and end times, which ignore the LOCKED\n"
|
|
|
|
"flag. This allows all the cdr records in the channel to be 'ended' together\n"
|
|
|
|
"when the channel is closed.\n"
|
|
|
|
"The CDR() func (when setting CDR values) normally ignores the LOCKED flag also,\n"
|
|
|
|
"but has options to vary its behavior. The 'T' option (described below), can\n"
|
|
|
|
"override this behavior, but beware the risks.\n"
|
|
|
|
"\n"
|
|
|
|
"Detailed Behavior Description:\n"
|
|
|
|
"First, this app finds the last cdr record in the list, and makes\n"
|
|
|
|
"a copy of it. This new copy will be the newly forked cdr record.\n"
|
|
|
|
"Next, this new record is linked to the end of the cdr record list.\n"
|
|
|
|
"Next, The new cdr record is RESET (unless you use an option to prevent this)\n"
|
|
|
|
"This means that:\n"
|
|
|
|
" 1. All flags are unset on the cdr record\n"
|
|
|
|
" 2. the start, end, and answer times are all set to zero.\n"
|
|
|
|
" 3. the billsec and duration fields are set to zero.\n"
|
|
|
|
" 4. the start time is set to the current time.\n"
|
|
|
|
" 5. the disposition is set to NULL.\n"
|
|
|
|
"Next, unless you specified the 'v' option, all variables will be\n"
|
|
|
|
"removed from the original cdr record. Thus, the 'v' option allows\n"
|
|
|
|
"any CDR variables to be replicated to all new forked cdr records.\n"
|
|
|
|
"Without the 'v' option, the variables on the original are effectively\n"
|
|
|
|
"moved to the new forked cdr record.\n"
|
|
|
|
"Next, if the 's' option is set, the provided variable and value\n"
|
|
|
|
"are set on the original cdr record.\n"
|
|
|
|
"Next, if the 'a' option is given, and the original cdr record has an\n"
|
|
|
|
"answer time set, then the new forked cdr record will have its answer\n"
|
|
|
|
"time set to its start time. If the old answer time were carried forward,\n"
|
|
|
|
"the answer time would be earlier than the start time, giving strange\n"
|
|
|
|
"duration and billsec times.\n"
|
|
|
|
"Next, if the 'd' option was specified, the disposition is copied from\n"
|
|
|
|
"the original cdr record to the new forked cdr.\n"
|
|
|
|
"Next, if the 'D' option was specified, the destination channel field\n"
|
|
|
|
"in the new forked CDR is erased.\n"
|
|
|
|
"Next, if the 'e' option was specified, the 'end' time for the original\n"
|
|
|
|
"cdr record is set to the current time. Future hang-up or ending events\n"
|
|
|
|
"will not override this time stamp.\n"
|
|
|
|
"Next, If the 'A' option is specified, the original cdr record will have\n"
|
2008-06-12 14:56:26 +00:00
|
|
|
"it ANS_LOCKED flag set, which prevent future answer events\n"
|
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
|
|
|
"from updating the original cdr record's disposition. Normally, an\n"
|
|
|
|
"'ANSWERED' event would mark all cdr records in the chain as 'ANSWERED'.\n"
|
|
|
|
"Next, if the 'T' option is specified, the original cdr record will have\n"
|
|
|
|
"its 'DONT_TOUCH' flag set, which will force the cdr_answer, cdr_end, and\n"
|
|
|
|
"cdr_setvar functions to leave that cdr record alone.\n"
|
|
|
|
"And, last but not least, the original cdr record has its LOCKED flag\n"
|
|
|
|
"set. Almost all internal CDR functions (except for the funcs that set\n"
|
|
|
|
"the end, and answer times, and set a variable) will honor this flag\n"
|
|
|
|
"and leave a LOCKED cdr record alone.\n"
|
|
|
|
"This means that the newly created forked cdr record will affected\n"
|
|
|
|
"by events transpiring within Asterisk, with the previously noted\n"
|
|
|
|
"exceptions.\n"
|
2007-11-06 19:04:45 +00:00
|
|
|
" Options:\n"
|
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
|
|
|
" a - update the answer time on the NEW CDR just after it's been inited..\n"
|
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
|
|
|
" The new CDR may have been answered already, the reset that forkcdr.\n"
|
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
|
|
|
" does will erase the answer time. This will bring it back, but\n"
|
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
|
|
|
" the answer time will be a copy of the fork/start time. It will.\n"
|
|
|
|
" only do this if the initial cdr was indeed already answered..\n"
|
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
|
|
|
" A - Lock the original CDR against the answer time being updated.\n"
|
|
|
|
" This will allow the disposition on the original CDR to remain the same.\n"
|
|
|
|
" d - Copy the disposition forward from the old cdr, after the .\n"
|
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
|
|
|
" init..\n"
|
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
|
|
|
" D - Clear the dstchannel on the new CDR after reset..\n"
|
|
|
|
" e - end the original CDR. Do this after all the necc. data.\n"
|
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
|
|
|
" is copied from the original CDR to the new forked CDR..\n"
|
|
|
|
" R - do NOT reset the new cdr..\n"
|
|
|
|
" s(name=val) - Set the CDR var 'name' in the original CDR, with value.\n"
|
|
|
|
" 'val'.\n"
|
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
|
|
|
" T - Mark the original CDR with a DONT_TOUCH flag. setvar, answer, and end\n"
|
|
|
|
" cdr funcs will obey this flag; normally they don't honor the LOCKED\n"
|
|
|
|
" flag set on the original CDR record.\n"
|
|
|
|
" Beware-- using this flag may cause CDR's not to have their end times\n"
|
|
|
|
" updated! It is suggested that if you specify this flag, you might\n"
|
|
|
|
" wish to use the 'e' flag as well!\n"
|
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
|
|
|
" v - When the new CDR is forked, it gets a copy of the vars attached\n"
|
|
|
|
" to the current CDR. The vars attached to the original CDR are removed\n"
|
|
|
|
" unless this option is specified.\n";
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
static int forkcdr_exec(struct ast_channel *chan, void *data)
|
|
|
|
{
|
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
|
|
|
{
|
2004-10-23 12:17:46 +00:00
|
|
|
return ast_register_application(app, forkcdr_exec, synopsis, descrip);
|
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");
|