[asterisk-dev] The New CDR system

[Steve Murphy]

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




-- 
Steve Murphy
Software Developer
Digium