[Asterisk-Dev] Current database abstraction effort ?
critch at basesys.com
Tue Jan 6 11:52:31 MST 2004
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>
More information about the asterisk-dev