----- "Andreas van dem Helge" <[EMAIL PROTECTED]> wrote: > 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? >
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 _______________________________________________ --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
