[asterisk-dev] CDR issues - Can someone sanity check them?

Kevin P. Fleming kpfleming at digium.com
Wed Jan 4 11:25:32 CST 2012


On 01/04/2012 07:26 AM, Ryan Wagoner wrote:
> On Wed, Jan 4, 2012 at 5:56 AM, Steve Davies <davies147 at gmail.com
> <mailto:davies147 at gmail.com>> wrote:
>
>     Hi,
>
>     I appreciate that CEL is probably the preferred call logging mechanism
>     these days, but I've found a couple of CDR issues, originally in 1.6.2
>     that still apply through 1.8.x and 10.x.
>
>     https://issues.asterisk.org/jira/browse/ASTERISK-17826 was already
>     open against 1.6.2, but I've just updated it for v.10
>
>     https://issues.asterisk.org/jira/browse/ASTERISK-19164 is new as I
>     discovered it while researching #17826.
>
>     Feedback welcomed please.
>
>     Regards,
>     Steve
>
>
> I've found the CDR records to be buggy when transferring. Basic
> inbound/outbound calls are accounted for correctly. At the very least I
> would like to see transfers fixed, which is most likely the same issue
> for AMI redirects.
>
> https://issues.asterisk.org/jira/browse/ASTERISK-18733
>
> Having to parse CEL to produce my own CDR records seems like an extra
> step. If CEL was added so I can parse the records correctly why can't
> Asterisk? I know everyone has disagreements on how CDR records should be
> accounted for, but I don't think CDR data should be just left out.

CDRs, as a side-effect of their design, *cannot* reliably account for 
any calls except "party A calls party B, party B answers, one party 
hangs up, call is torn down". Transfers, holds, conferencing, redirects, 
any other activity other than basic call handling have no way to be 
properly represented in CDRs. Everyone has different opinions on how 
they should appear, and while I won't disagree that there could be bugs 
that need to be corrected, the fact that transfers are not "properly" 
recorded is not a bug: it can't be, because there is no commonly 
accepted definition of what is 'proper' for a CDR to report a transfer.

CEL was added so that you'd have all the raw data necessary to make your 
own decisions on how to produce CDRs if you need to do so; the decisions 
on how to collapse/coalesce CEL records into CDRs are *business 
decisions* you need to make, they don't belong in Asterisk (and trying 
to put them there only results in frustrations and 'bug reports' from 
people who think that the coalescing should be done differently).

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org



More information about the asterisk-dev mailing list