A few corrections! On Tue, Sep 21, 2010 at 6:32 PM, Steve Murphy <[email protected]> wrote:
> > > On Tue, Sep 7, 2010 at 5:36 PM, Fabiano Carlos Heringer < > [email protected]> wrote: > >> Em 07/09/2010 17:15, Miguel Molina escreveu: >> >> El 07/09/10 14:49, Fabiano Carlos Heringer escribió: >> >> Is there a way to solve the mess on CDR caused by CDR Transfer? anyway, by >> paid support, no paid, or another way... Im going crazy about this. My boss >> is really furious because he don´t understand nothing on the CDR. >> >> I tried the 1.6.2.11, Asterisk 1.8 beta, and everything still the same. >> >> Any solution? >> >> Thanks! >> >> Hi >> >> Some quick measures: >> >> 1. Enable unanswered=yes on cdr.conf and try to see if it helps you with >> the CDR. >> 2. Try using CEL (Channel Event Logging) in 1.8-beta and try to see if >> that helps in a definite way. >> >> Cheers, >> >> -- >> Ing. Miguel Molina >> Grupo de Tecnología >> Millenium Phone Center >> >> Hi, will make this change on my cdr.conf >> >> About CEL on asterisk 1.8 i tried some test on my test server, he really >> logs each event on log, but i did not understood how he will work on a user >> view (most simple). It´s possible to log this events on a database such >> mysql? >> >> Thanks! >> > > Sorry for the delay, things have been busy here. > > Yes, there are problems with the existing CDR interface, mostly historical, > because as Asterisk > grew, the CDR system became obsolete. There were attempts to make it work, > but structurally > and architecturally, it was just not going to work. > > CEL was my answer, built on the channel event goodness that Russell. It's > now in 1.8; but it > Uh, that Russell *wrote*. > lacks a converter to CDRs. You *could* just use the string of events coming > out of CEL, but... > I'd love to see your SQL statements to pull things together! > > I had begun writing a CEL->CDR converter, but got laid off before I could > finish it. > It makes a good start toward a finished package. Long ago (what, almost 2 > years now?) > I proposed two methods of generating CDR's. One was 'simple', the other > 'Complex", or "Leg Based". > > Since then, I refined the doc to just 'Simple', and outlined with some > examples how it would/should work. > The doc still needs to be cleaned up, but you may make sense of it. > > The trouble with CDRs is that no two shops can agree on a CDR standard that > involves transfers, parks, etc. > Beyond the "start", "answer", and "end" times, and some fundamental data > about the call (source, dest, > responsible party, etc.) There isn't much unity about what timepoints need > to be represented, etc. And I'd seen > so few implementations, I couldn't judge a good way to generalize the CDR > converter. > > So, I challenge everyone to look at my simple CDR definition, and see it > would possible for you to adapt it > (perhaps via a mapping from it to your desired conflagration/configuration. > > To look at the doc, do "svn co > http://svn.digium.com/svn/team/murf/asterisk-RFCs and look at the > document in there (I have a few different formats, the .docx is the > source). > Sorry, the URL is http://svn.digium.com/svn/asterisk/team/murf/RFCs > > It's been in flux. Just the first few examples are accurate. Let me know > what you think. > > murf > > > > -- > Steve Murphy > ParseTree Corp > > -- Steve Murphy ParseTree Corp
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
