On Fri, 2008-12-05 at 10:52 +0000, Andrew Thomas wrote: > Thanks for this Greyman - it's all beginning to make sense now ;). > > I agree that the 'loss of CDR upon txfr' is a nasty bug which does need > to be addressed before anything else (assuming it hasn't been already). > > But, wouldn't it be better if you could ignore the CDR's completely and > use an event based system? This would give you ALL the information you > need. All that remains is to filter out the un-required bits. > > Like I said earlier - the CDR's aren't reliable enough for a billing > platform (as you've rightly pointed out) but are OK for very basic call > logging (something the customer can look at). > > Hopefully, the murf'ster will chirp in here :). >
I'll Chirp here. I'm kinda impressed with the number of CDR Design messages in the Q since last I checked, but I'll try to plow my way thru them. I've been ruminating over Greyman's suggestion about simplified CDR's for the past few days, stepped outside my 'box', and I think realized what he actually was asking for, at last. As to the event system, say no more. CEL is it. It will spew out all possible CDR related events in any of several formats, in somewhat real-time (as they occur) order. The state of the channels are included with the time of each event. But, this alone isn't really useful in a database. Try coming up with SQL queries that tell you useful things about what's happened, or happening... CDR format is useful that way; and, like Brian, yes, you can mix the two to your heart's content, even add manager events to the mix. murf > Cheers > Andy > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Grey Man > Sent: 05 December 2008 09:37 > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] CDR Design > > On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas <[EMAIL PROTECTED]> > wrote: > > > > In summary: Leave CDR exactly as it is and create a new CEL (Call > Event > > Logging) module (optional in modules.conf) that puts out (and does not > > accept) call event information (ie. a one-way fire-and-forget output > > from Asterisk). > > > > Hi Andrew and Others, > > This thread is actually part of a discussion that has been going on > for over a year. The links below provide the background to the whole > thing. > > http://www.asterisk.org/node/48358 > http://bugs.digium.com/view.php?id=11849 > http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.htm > l > > Up until recently the approach was to try and fix the specific bugs > with transfer CDRs as a typical bug. There is now a realisation that > that is a lot trickier than inially thought so it's been decided to > try and come up with a good design for the Asterisk CDR sub-system. > > Regards, > > Greyman. > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users -- Steve Murphy Software Developer Digium
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
