<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><EM>>The reason some want it to move via ODBC to a DB is so it can be
remote.<BR>>If you are using asterisk as a phone switch instead of a PBX
where you<BR>>must bill customers, you want your call data to outlive the
machine in<BR>>case it where to crash. ODBC is a way to get this data off the
switch<BR>>and to another machine semi reliably.<BR><BR>>Also it is much
easier for the same group of people to generate billing<BR>>from a DB.
Granted that the records can just as easily be combined into<BR>>a DB at a
later non realtime basis. Of course some of these same people<BR>>are wanting
to run calling card apps that require that realtime access. </EM></DIV>
<DIV><EM></EM> </DIV>
<DIV>I understand these and other reasons to use a DB and ODBC access. I
will add though, that remote access to a DB over a WAN is not always that
easy. We have had a lot of experiences trying to support this for our
customers where network reliability was an impedance as were other network
security issues. </DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>If the PBX machine/PC goes down, CDR is probably the last
thing you will worry about from a priority standpoint. In addition,
frequent CDR polling from either a DB or from flat files is just as secure
in getting data "off" the switch.</FONT><BR></DIV>
<DIV><FONT size=2></FONT><FONT size=2></FONT><FONT size=2></FONT><BR><EM>>I
assume to enable a new class of applications.</EM></DIV>
<DIV><EM></EM> </DIV>
<DIV>I think this is exactly right. My impression is that Asterisk will
not be the host/source of these new applications, but that they will be provided
by 3rd parties. While it is possible for these apps to read directly from a
system DB via ODBC or otherwise, it is usually not in the PBX's best interest to
allow 3rd party apps to use its resources unrestricted. Billing and
traffic reports can grind a disk to death!</DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>With that in mind, it is more typical for the PBX to offload
its data as quickly as possible. Other apps picking up this data will
invariably have their own DB's to migrate data into for further processing,
queries, reporting, alarming, etc. Any DB tables setup for CDR by Asterisk
will then need to have the data extracted for use in other apps.
That just seems like a lot of extra work for little gain. These other apps
can be and already are browser accessible data repositories.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><EM>>And (unless you use MySQL) reading the database<BR>>does NOT
lock out writes As you _will_ need multiple * boxes<BR>>for a large
system supporting concurent writes may be important.<BR></EM></DIV>
<DIV>That brings up another issue regarding call rating and billing. You
will have to correctly identify the source of an outbound call carried by the
PSTN in order to rate it correctly based on mileage bands for local and
IntraLATA service from a local telephone company or possibly other carriers. If
you have a distributed set of Asterisk boxes in several locations, you will have
to provide some indication of where the calls egress to the PSTN.</DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>- David Schlossman</FONT></DIV>
<DIV><FONT size=2></FONT><FONT size=2><A
href="mailto:david@atcomm.com">david@atcomm.com</A></FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV></BODY></HTML>