[asterisk-dev] Re: The New CDR system

Steve Edwards asterisk.org at sedwards.com
Fri Mar 30 13:16:26 MST 2007

In my application (an adult chat system), we process about 15,000 calls a 
day. I write a CDR at the start of each product (context) using 
resetcdr(w) so we can keep track of how much time was spent on the 
previous product. Each call consists of between 5 and 100 cdrs.

I added the following fields to our CDR table: agent, ani, dnis, globalid 
(host id + unique id), per_minute (charge per minute for this product), 
product (previous context), surcharge (surcharge for this product), theme, 
and timestamp -- obviously a bunch of stuff other users may not be 
interested in.

I implemented this by hacking on cdr_addon_mysql() in 1 system and by a 
custom AGI on another. Both work pretty well and have their advantages and 

What I would have liked to implement would be for the CDR engine ask the 
database for the column names in the specified table. Then, when a CDR is 
written, if there is a global or channel variable of that name, it would 
be added to the insert statement. I would also like to have implemented an 
"alias" feature so that I could say "column-name = variable-name."

This would eliminate the userfield kludge and let implementors tailor the 
CDR to their needs without requiring any custom coding.

On Fri, 30 Mar 2007, Norman Franke wrote:

> I agree that the one call/one entry days are way, way over. That was 
> something that was frustrating me in managing my CDRs. The other complaint 
> was different CDR methods, e.g. ODBC vs TDS logged different things to tables 
> of different structure. That's not cool, and I assume that will be corrected.
> I've very exited to hear about the event type/ event date concept. I think 
> this makes it much more flexible, particularly if a dialplan command can 
> generate custom event types. I'd very much like a transfer type to be in 1.4, 
> since that's one of the major oversights in the current scheme. Hold should 
> be possible for SIP channels, since it reinvites which should be easy to 
> trap. I can see that on a Zap line, it may not be possible to detect hold. 
> That's life.
> I'd also like a more flexible userfield scheme. This could be somewhat 
> mitigated by having the dialplan command to generate CDR events, but I'd like 
> to allow an arbitrary number of userfields. If none are added via a dialplan, 
> then none get inserted. If you specify two, the CDR record would expect to 
> find two in the database table. Thus, it could grow according to the dialplan 
> users' needs.
> I think this is a step in the right direction!
> Norman Franke
> ASD, Inc.
> http://www.myasd.com/
>> Date: Thu, 29 Mar 2007 12:48:27 -0600
>> From: Steve Murphy <murf at digium.com>
>> Subject: [asterisk-dev] The New CDR system
>> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
>> Message-ID: <1175194107.7325.44.camel at digium2>
>> Content-Type: text/plain
>> FYI--
>> I've been collecting all the CDR related bugs. I have a branch,
>> team/murf/bug8221-1.4, where I've been testing out fixes to problems
>> reported.
>> I'm about to clean it up and commit it to 1.4 and trunk.
>> If there's one thing I've concluded, it's that there are some problems
>> with the CDR system, and something different is in order.
>> And, after yesterdays "Oldest 15" phone conference, with the CDR
>> discussion afterwards, just what exactly the "new CDR" system should be,
>> is beginning to gel.
>> First of all, why a **new** CDR system? Well, to put it plainly, the old
>> days of "one call", and it's corresponding "one CDR", are over. It might
>> have been fine for Ma Bell to bill from when all that happened was, you
>> dial a number, and two
>> people talk, then you both hang up. But things aren't that simple any
>> more!
>> There's parking lots, 3 way conferences, conference rooms, transfers,
>> blind and attended, call forwarding, findmefollowme, masquerading,
>> queues, etc. etc., and the billing requirements can get quite tricky!
>> 1. There will be a configuration file choice, as whether to use the
>> "OLD" CDR
>>   system (the current one we all know and love), and the "NEW" config
>> system,
>>   the one I'm about to describe. By default, in trunk, it will be
>> "OLD". Maybe
>>   in 1.8, it will default to "NEW", and in 1.10, OLD will disappear,
>> maybe.
>>   Maybe not.
>> 2. The record format will change. Currently, each CDR has room for 3
>> events:
>>   start (usually channel creation), answer (from a dial operation), and
>> end
>>   (usually when the CDR is to be closed and posted, usually a hangup,
>> or
>>   transfer, etc.).
>>   The new CDR record will record only 1 event, and be immediately
>> posted.
>>   For the sake of the database backends, these fields are currently
>>   output:
>>   calldate (date/time)     (odbc, pgsql, mysql)
>>   start (date/time)    (tds, radius, sqlite
>>   answer (date/time)    (tds, radius, sqlite
>>   end (date/time)    (tds, radius,
>>   clid     (odbc, tds,  pgsql, mysql)
>>   src     (odbc, tds,  pgsql, mysql)
>>   dst     (odbc, tds,  pgsql, mysql)
>>   dcontext     (odbc, tds,  pgsql, mysql)
>>   channel     (odbc, tds,  pgsql, mysql)
>>   dstchannel     (odbc, tds,  pgsql, mysql)
>>   lastapp     (odbc, tds,  pgsql, mysql)
>>   lastdata     (odbc, tds,  pgsql, mysql)
>>   duration (int)     (odbc, tds,  pgsql, mysql)
>>   billsec  (int)     (odbc, tds,  pgsql, mysql)
>>   disposition     (odbc, tds,  pgsql, mysql)
>>   amaflags  (int)     (odbc, tds,  pgsql, mysql)
>>   accountcode      (odbc, tds,  pgsql, mysql)
>>   uniqueid     (odbc, tds,  pgsql, mysql, sqlite(option), )
>>   userfield     (odbc, pgsql, mysql, sqlite(option), )
>>   The calldate timestamp vs. start, answer, end timestamps was a bit of
>> mystery
>>   to me, so I checked it out... in mysql,pgsql,odbc, it's the start
>> time; my
>>   guess is that billsec/duration fields are the important ones, and the
>> calldate
>>   maybe just serves to help sort the records.
>>   The new CDR output format will drop the start/answer/end/calldate
>> fields, and
>>   instead have a single "eventdate" field instead. It will add an
>> "eventtype"
>>   field that contains a standardized event name, "START", "HANGUP",
>> "ANSWER",
>>   "APP", "BRIDGE", for now, with possibilities like "PARK", "TRANSFER",
>>   "CONF_START", "CONF_END", and others, that we should nail down
>> completely
>>   before beginning.
>>   Some of the other fields don't make sense any more in this sytem.
>> "dst" might
>>   not be known until after a dial, say. "lastapp" and "lastdata" would
>> most
>>   likely turn into just "App" and "AppData", and only be meaningful if
>> the event
>>   type is "APP"; "duration" and "billsec" would disappear, as the users
>> would
>>   have to the calc themselves, based on their own criteria; disposition
>> would
>>   probably only be meaningful with certain eventtypes; amaflags,
>> accountcode,
>>   userfield would probably be output with every event-type. The
>> software to
>>   generate billing data would probably get a little more complex, but
>> should be
>>   able to generate the proper numbers from much more accurate and clear
>> data.
>> 3. CDR's would follow the life and activity of a channel in Asterisk.
>> Each
>>   channel is assigned its uniqueid, and BRIDGE and CONF_START events,
>> and
>>   similar, will record both channels so channel activity can be linked.
>> The
>>   uniqueid field in the cdr records can be used to link all the events
>> that
>>   happened on a channel for a particular call. When two channels are
>> linked,
>>   the necessary uniqueid's will be available to link things up.  A
>> confID might
>>   be necessary to tie calls into conference rooms together.
>> 4. Either we can assign events a level number, and allow the user to
>> specify via
>>   the config file, at what level they wish to log, or we can allow the
>> user to
>>   specify in the config file exactly what events they wish to track,
>> and even
>>   restrict which apps they wish to track as well, if not all of them.
>> Only those
>>   events specified in the config file would be logged, hopefully
>> reducing
>>   storage requirements and clutter. For those interested in Deep
>> Dialplan
>>   Debugging, requesting info on ALL apps, would provide a complete
>> record of all
>>   dialplan functions executed on a channel-- right down to NoOps and
>> Goto's,
>>   if such are desired...
>> 5. Some (but not all) apps currently provided by asterisk for CDR
>> manipulation,
>>   like ForkCDR, for instance, should be unnecessary, and would not
>> apply to the
>>   "new" system any more.
>> Hate it? Love it? Have suggestions?
>> murf
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev

Thanks in advance,
Steve Edwards      sedwards at sedwards.com      Voice: +1-760-468-3867 PST
Newline                                             Fax: +1-760-731-3000

More information about the asterisk-dev mailing list