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

Steve Murphy murf at parsetree.com
Tue Sep 21 19:32:12 CDT 2010


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
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).

It's been in flux. Just the first few examples are accurate. Let me know
what you think.

murf



-- 
Steve Murphy
ParseTree Corp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100921/9f61602f/attachment.htm 


More information about the asterisk-users mailing list