Prior to this patch, ForkCDR's e option would immediately set the end time of the forked
CDR to that of the CDR that is being terminated. This resulted in the new CDR's end time
being roughly the same as it's beginning time (which is in turn roughly the same as the
original's end time).
(closes issue ASTERISK-19164)
Reported by: Steve Davies
Patches:
cdr_fork_end.v10.patch uploaded by Steve Davies (license 5012)
........
Merged revisions 362082 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@362084
65c4cc65-6c06-0410-ace0-
fbb531ad65f3
if (!(newcdr = ast_cdr_dup_unique(cdr)))
return;
+ /*
+ * End the original CDR if requested BEFORE appending the new CDR
+ * otherwise we incorrectly end the new CDR also.
+ */
+ if (ast_test_flag(&optflags, OPT_ENDCDR)) {
+ ast_cdr_end(cdr);
+ }
+
ast_cdr_append(cdr, newcdr);
if (!ast_test_flag(&optflags, OPT_NORESET))
if (ast_test_flag(&optflags, OPT_RESETDEST))
newcdr->dstchannel[0] = 0;
- if (ast_test_flag(&optflags, OPT_ENDCDR))
- ast_cdr_end(cdr);
-
if (ast_test_flag(&optflags, OPT_ANSLOCK))
ast_set_flag(cdr, AST_CDR_FLAG_ANSLOCKED);