[asterisk-users] Solving the CDR mess of attended transfers

[Steve Murphy]

A few corrections!

On Tue, Sep 21, 2010 at 6:32 PM, Steve Murphy <murf at parsetree.com> wrote:

>
>
> On Tue, Sep 7, 2010 at 5:36 PM, Fabiano Carlos Heringer <
> bigu at grupoheringer.com.br> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100922/8e246409/attachment.htm