Steve Murphy wrote: > [...] > > Everyone-- > > I've just made some major changes to the CDRfix2.rfc.txt > file in http://svn.digium.com/svn/asterisk/team/murf/RFCs > to accommodate the Leg approach instead of a > channel-based approach. > > Greyman is correct. By cutting the timeline into legs, > we avoid all the nasty channel state problems, or so it > appears thus far. I threw out all the text about > channel/peer state, fleshed in all the example > cases, etc. > > I added a section describing the linkedID field. > > I provide a list of CDR record types at the end, > that will eventually be expanded to describe each > field that set in that type, and what they mean. > > The types so far are: > > 3WAY > AXFER > AXFER1 > AXFER2 > BARGE > BXFER > CALL > CONF > HOLD > PARK > RECALL > RECONN > USER > WHISPER > > > murf > >
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 _______________________________________________ -- 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
