[asterisk-dev] The New CDR system

[Tzafrir Cohen]

Hi

I'm not sure I undrstand CDR systems well enough, so please excuse my
possibly incorrect terminology.

One "requirement" I'd like to make is to have things "just work" at
least as well as they used to.

On Thu, Mar 29, 2007 at 12:48:27PM -0600, Steve Murphy wrote:
> 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), )

sqlite: sqlite2? sqlite3?

With the old format, the information is very clear: a call is a call.
With the new format, some sql wizardy is needed to extract it.

This is one possible regression for the user. To avoid it, the relevant
SQL wizardry should be well documented.

So queries plese, for:

  - All calls
  - Running calls  (heck: show something that wasn't there before)
  - Calls older than 1 monthes (to purge, store elsewhere, or whatever)
  - Anything else?

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir