[asterisk-users] CDR changes in 1.4.3?

[Andreas van dem Helge]

On 4/27/07, Steve Murphy <murf at digium.com> wrote:
> I'm the guilty party. I've been trying to fix several CDR bugs,
> involving stuff like missing times, missing changes in state (like
> NO_ANSWER when the call was ANSWERED), etc.

Now that we are talking about CDRs, I must ask: in 1.2.x if the CDR is
forked into two the uniqueid is the same for both CDR records. Is that
the intended behavior? Does that remain in 1.4.x?

> CDR's are complicated by the fact that they record 3 events: "start",
> "Answer", and "end" events. Add to that the fact that in most cases at
> least two channels are involved, sometimes 4 or 5, or even more,
> involving bridging, maquerading, parking, transfers, local channels,
> AGI, conferences, and more...
>
> Some cases were impossible to fix unless CDR's were attached to every
> channel,
> and merged to collect the bits and pieces that sometimes were on the
> wrong side of the bridge.

It would be nice if the CDR engine could be configured to allow for
these transactions either to be merged or not and what to do with the
bits and pieces as you describe them. However it would seem logical
that if various pieces are merged then ultimately they should not be
logged as that would be redundant... However I'd rather see it be a
configuration choice.

> The result is that several more cases are more accurate, but also, that
> rather uninteresting CDR's can be generated. In contemplating what could
> be done to get rid of some of these, I sometimes have to ask, "is this
> truly something we have to get rid of?"... In the meantime,
> uninteresting CDR's with NO_ANSWER and billsec=0, should be easy to
> filter out, right?

I don't think CDRs with NO ANSWER disposition or billsec=0 should be
discarded. Why not make it configurable?

> I will, in the coming days, look at some of the extraneous CDR's that
> are generated, and see what I can do to get rid of them. It's not always
> that simple.
> If we ring a phone, for instance, and no-one answers it, is that truly,
> really, something that no-one will ever be, could ever be, interested
> in? (just a fer-instance).


>From a billing standpoint no whats the point? For statistical purposes
I think its useful. For VoIP serviceprovider also very useful customer
probably wants full call logs. I don't think your idea is too much
CALEA-compliant either.

> I welcome your input. Complain up a storm. I'll try my best to make you
> happy.
>

Make it configurable.