[asterisk-dev] [Code Review]: Fix incorrect duration reporting in CDRs created in batch mode that use ast_cdr_getvar

[Matt Jordan]

> On June 21, 2012, 10:12 a.m., Tilghman Lesher wrote:
> > /branches/1.8/main/cdr.c, lines 292-295
> > <https://reviewboard.asterisk.org/r/1996/diff/1/?file=29024#file29024line292>
> >
> >     I really don't think you should do this, especially in a released version.  You are likely to break more dialplans than you will help, and it violates one of our core tenets that multiple developers have regretted (thou shalt not change how CDRs work).

I won't say that I'm a fan of doing this.  I'm not.  On the other hand, it is a legitimate bug.  And it isn't happening due to undefined behavior (see, transfers/masquerades/anything involving more then two channels), it isn't happening due to an incredibly contrived dialplan or configuration - its happening because they happen to be using a well documented (if rarely exercised) feature.

I find it a little tough to say that we won't attempt to fix that.

BUT: to minimize the risk further, there are a few things that can be done here to make this a bit less likely to cause problems.  In particular, we could check (similar to billsec) whether or not a value has been set for cdr->end.  If a value has been set for cdr->end and duration is 0, we can trust that we have a valid duration of 0.  If not, we re-calculate using the current time.

That preserves the intent of the original patch, which was to calculate the duration if - for whatever reason - ast_cdr_end failed to get called, while preventing that calculation from occurring if ast_cdr_end really was called.


> On June 21, 2012, 10:12 a.m., Tilghman Lesher wrote:
> > /branches/1.8/cdr/cdr_adaptive_odbc.c, lines 621-636
> > <https://reviewboard.asterisk.org/r/1996/diff/1/?file=29023#file29023line621>
> >
> >     The point of this section is that duration is (due to legacy reasons) calculated as an integer, whereas the adaptive driver is permitted to calculate the duration and billsec in fractions of a second.  If you're going to eliminate this here, you need to address this shortcoming in the core.

After I read through this and thought through it some more, I don't think removing this was appropriate anyway.  While having the cdr_adaptive_odbc backend re-interpret the duration value is less then ideal, making the core CDR code support a fractional duration is way out of scope for this change.  Plus, it shouldn't change the meaning of the duration value as it still is calculating it based on the cdr->end value.

The error that caused the duration values to be mis-reported in batch mode occurs not because the duration value is calculated using cdr->end, but because, if zero, its calculated using ast_tvnow().  Removed this change.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1996/#review6529
-----------------------------------------------------------


On June 20, 2012, 4:14 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1996/
> -----------------------------------------------------------
> 
> (Updated June 20, 2012, 4:14 p.m.)
> 
> 
> Review request for Asterisk Developers, Mark Michelson and Tilghman Lesher.
> 
> 
> Summary
> -------
> 
> Certain places in core/cdr.c would, if the duration value were 0, would calculate the duration as being the delta between the current time and the time at which the CDR record was started.  While this does not typically cause a problem in non-batch mode, this can cause an issue in batch mode where CDR records are gathered and written long after those calls have ended. In particular, this affects calls that were never answered, as those are expected to have a duration of 0.  Often, this would result in CDR logs with a significant number of calls with lengthy durations, but dispositions of "BUSY".
> 
> Note that this does not affect CSV CDRs, as that backend does not use ast_cdr_getvar and instead directly reports the duration value.  The affected core backends include cdr_apative_odbc and cdr_custom; other extended or deprecated CDR backends may potentially still directly manipulate the duration values. 
> 
> This patch essentially reverts r91617, when this behavior was introduced.
> 
> 
> This addresses bug ASTERISK-19860.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19860
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/main/cdr.c 368829 
>   /branches/1.8/cdr/cdr_adaptive_odbc.c 368829 
> 
> Diff: https://reviewboard.asterisk.org/r/1996/diff
> 
> 
> Testing
> -------
> 
> Ran through the Asterisk Test Suite's CDR tests.  A new test for batch CDR creation was also written that also tests that the disposition/billsec are 0 when they should be, and non-zero when the calls are answered.
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120621/e40f7fbd/attachment-0001.htm>