[asterisk-dev] Re: The New CDR system

[Norman Franke]

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