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

Steve Davies davies147 at gmail.com
Wed Jan 4 11:49:55 CST 2012


On 4 January 2012 17:25, Kevin P. Fleming <kpfleming at digium.com> wrote:
[snip]
>
> 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,

I 100% agree with your response. As mentioned in my previous post,
what I am attempting to do is to define the rules of the "CDR game" on
the basis that

1) Any existing game rules that are valid cannot be broken
2) Any undefined or clearly broken cases are fixed.

None of my existing submissions do that, they just add band-aid to the
existing code to fix the worst cases, but as I mentioned, I think I am
95% of the way to an answer.

The basic principle is that if an outbound channel is created, it will
probably be costing us, so we need to track it properly. The inbound
call information would be nice too if we can represent it as an aside.
If you need to track transfers, conferences etc in full detail, then
absolutely you need the additional info from CEL.

I believe the way forward if I am to see this through is for me to
prepare a 1.8 or 10.0 version of what I currently have, and use the
review-board once there is something to show. After all, people can
only say "no" :)

Regards,
Steve



More information about the asterisk-dev mailing list