[Asterisk-Dev] Current database abstraction effort ?

[Steven Critchfield]

hehe, I get to argue for the other side a moment. 

On Tue, 2004-01-06 at 11:51, david wrote:
<sniped great commentary about call load estimation>

> My question is, why do you need to write the CDR to a database in the first
> place?  The applications that read this type of data are used to accessing
> it as clear text (ASCII).  This has been picked up in the past from RS-232
> streams but in more recent years "evolved" to file or IP streams.  Here are
> approaches that are used today by various IP PBX manufacturers:

The reason some want it to move via ODBC to a DB is so it can be remote.
If you are using asterisk as a phone switch instead of a PBX where you
must bill customers, you want your call data to outlive the machine in
case it where to crash. ODBC is a way to get this data off the switch
and to another machine semi reliably.

Also it is much easier for the same group of people to generate billing
from a DB. Granted that the records can just as easily be combined into
a DB at a later non realtime basis. Of course some of these same people
are wanting to run calling card apps that require that realtime access. 

> I wonder why it is important to write the Asterisk CDR to a database.
> Writing a flat, fixed column ASCII file makes it much more accessible to the
> variety of applications out there used for traffic engineering and billing.
> One effective way to do this is to manage a threshold (timer or call count)
> at which point you write a new file using a unique file name scheme
> (sequence number, date/time, etc.).  While the new file is open, it is
> write-locked, preventing any other app from reading it. All previous CDR
> files are accessible.  If you use a timer, these files could be available
> every hour, or every day, or whatever sequence the user sets it up for.
> Sequential file names like cdrXXXX.txt could cycle from 0000 to 9999 at
> which point they overwrite the oldest data.  This is then somewhat
> self-maintaining within the disk limits of the user's system.  Just some
> suggestions as well as questions.

Log rotation would be nice, I even think it is already a possibility as
there was a command you could send to asterisk that can cause it to
close and reopen it's log files too. 
-- 
Steven Critchfield  <critch at basesys.com>