<!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>&gt;The reason some want it to move via ODBC to a DB is so it can be 
remote.<BR>&gt;If you are using asterisk as a phone switch instead of a PBX 
where you<BR>&gt;must bill customers, you want your call data to outlive the 
machine in<BR>&gt;case it where to crash. ODBC is a way to get this data off the 
switch<BR>&gt;and to another machine semi reliably.<BR><BR>&gt;Also it is much 
easier for the same group of people to generate billing<BR>&gt;from a DB. 
Granted that the records can just as easily be combined into<BR>&gt;a DB at a 
later non realtime basis. Of course some of these same people<BR>&gt;are wanting 
to run calling card apps that require that realtime access. </EM></DIV>
<DIV><EM></EM>&nbsp;</DIV>
<DIV>I understand these and other reasons to use a DB and ODBC access.&nbsp; I 
will add though, that remote access to a DB over a WAN&nbsp;is not always that 
easy.&nbsp; 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.&nbsp; </DIV>
<DIV><FONT size=2></FONT>&nbsp;</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.&nbsp; In addition, 
frequent CDR polling&nbsp;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>&gt;I 
assume to enable a new class of applications.</EM></DIV>
<DIV><EM></EM>&nbsp;</DIV>
<DIV>I think this is exactly right.&nbsp; My impression is that Asterisk will 
not be the host/source of these new applications, but that they will be provided 
by 3rd parties.&nbsp;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.&nbsp; Billing and 
traffic reports can grind a disk to death!</DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>With that in mind, it is more typical for the PBX to offload 
its data as quickly as possible.&nbsp; Other apps picking up this data will 
invariably have their own DB's to migrate data into for further processing, 
queries, reporting, alarming, etc.&nbsp; Any DB tables setup for CDR by Asterisk 
will&nbsp;then need to have the data extracted&nbsp;for use in other apps.&nbsp; 
That just seems like a lot of extra work for little gain.&nbsp; These other apps 
can be and already are browser accessible data repositories.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><EM>&gt;And (unless you use MySQL) reading the database<BR>&gt;does NOT 
lock out writes&nbsp; As you _will_ need multiple * boxes<BR>&gt;for a large 
system supporting concurent writes may be important.<BR></EM></DIV>
<DIV>That brings up another issue regarding call rating and billing.&nbsp; 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>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV></BODY></HTML>