On 4/27/07, Steve Murphy <[EMAIL PROTECTED]> 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. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
