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