[asterisk-users] CDR Design

[Steve Murphy]

On Mon, 2008-12-01 at 10:55 -0600, JD wrote:
> Steve Murphy wrote:
> > [...]
> 
> I love it! You will have it done later today, correct? (joke.)
> 
> Just a non-technical/social suggestion: don't call this CDR. Call it 
> "Enhanced CEL" or something like that.
> 
> Why?: because otherwise you will forever get arguments about it. 
> Traditionally, a CDR is one line per call; all inclusive. And as you 
> know, that is a horrible standard for todays complex systems; but it is 
> what it is.
> 
> So, perhaps Asterisk should not build native CDR at all. It should build 
> your "Enhanced CEL". A separate perl/ruby/etc script could be included 
> in the Asterisk distribution that build the "CDRs" after the fact. Or 
> multiple CDR scripts based on the flavor-of-the-day of what CDR means.
> 
> Just my thoughts. I very much look forward to your code. This will make 
> my life so much easier.
> 
> John

John--

Point well taken, but if I call it anything but 
CDR, people will go "Huh?".

CEL is per-event, but CDR's are event-groups. I 
think we are safe to keep calling it CDR, because 
I perceive that at least some of the big-name
pbx vendors are generating much more than simple 
line-per-call records and they still call them CDR's.

Using a db to make sense of CEL events for billing 
purposes is extraordinarily difficult, as the strings 
of events are reported as they occur, and with
multiple calls going on simultaneously, the events are
interlaced. You can pull out single threads by sorting 
on the linkedid; but still you have strings of events 
among multiple channels that will not be obviously easy to 
decode, especially by concocting SQL queries. Thus, the 
need to provide some sense via CDR's.

And, yes, I agree with you. I will try to make it so 
a CEL->CDR generator could be run either 'real time'
inside asterisk (via make menuselect choice), (and 
using your selection of existing backends), AND, I 
can try to provide a stand-alone option that could 
be run on CEL events that were logged to one of the 
CEL backends; probably just one of the plain-text
ones.

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20081201/d5e7a804/attachment.bin