[asterisk-users] CDR changes in 1.4.3?

[Steve Murphy]

----- "Andreas van dem Helge" <joakimsen at gmail.com> wrote:
> 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?
> 

It should be the same. The uniqueid is a channel attribute, and when the CDR is initialized,
that value is copied from the channel. That hasn't changed from 1.2 to 1.4, nor have I mucked
with it.

> > 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.
> 

I'll do what I can... but I don't see merging entries to be an option in the near future.
I think I'll be lucky to be able to give you accurate info that you can merge at the backend...!

> > 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?

Now, this may be option. 

> 
> > 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.

Viva la CALEA! OK. Forget the filtering. The Gov shall have everything.


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

I'll try!


-- 
Steve Murphy
Software Developer
Digium