[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
disadvantages.
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