[asterisk-users] CDR Design

[Steve Murphy]

On Mon, 2008-11-24 at 09:12 -0700, Anthony Francis wrote:
> It is my belief that before redesigning the CDR engine some time should 
> be spent looking at current PSTN CDR formats and what information is 
> kept in them.
> The main problem that I feel we face is that calls can be complicated, 
> but we want the record of it to not be.
> In reality a CDR that incorporates all information about a call would 
> have at least two dimensions.
> In the first you would have the base call record as we do now, in the 
> second we would have the event list.
> The event list would be a time indexed list of event names and 
> attributes, just as you would currently store event information.
> The event list would be your glue (with a bit of front end logic of 
> course.) that would relate a call that dialed X external numbers to the 
> X different new CDR's that generated.
> That would allow you all the call path info you could ever want. The 
> most important thing would be a new config file that allows an 
> administrator granular control over what information is "important to 
> them. And of course a "keep it simple stupid" mode that just writes the 
> top level cdr as it does now.
> 

Well, the CEL stuff definitely generates the event lists, and can do it
to any of the normal database backends. But Brian Degenhardt pointed out
that really, such event-list databases are practically useless. Queries
for even simple things would involve incredibly complicated queries in
terms of unique ID, event order, etc. etc.

So, a CDR backend that lists all the call legs and the info 'behind'
each leg, like what prompted this leg (an xfer vs a dial, etc), should
be sufficient to answer most business-logic questions without ambiguity,
and give you the info you seek, like how long a leg lasted. (which might
be pretty interesting to calculate, if all you have are individual
Start, answer, end, xfer, park, conf, etc. events in your db.

Brian took all the raw events to a backend, but then post-processed them
to form the records he needed.

I plan the same for CEL, but am searching for consensus on what to
generate.

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/20081125/13a0d2da/attachment.bin