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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
