I am really in favor of separating things here. The switch's job is to reliably generate CDRs and not to deal with the business logic. FreeSWITCH does the first part for you, the second part really is up to you or some other software like the ones discussed here.
Mixing these 2 roles into the core could lead to several problems in which I have already ran into in the past. FreeSWITCH even takes one step further which is posting the files to you on a web server if you want, so.... JM On Sat, May 22, 2010 at 11:39 PM, Michael Collins <[email protected]>wrote: > > > On Sat, May 22, 2010 at 2:04 PM, Vitalii Colosov <[email protected]>wrote: > >> Well, big telcos will anyway use big mediation systems (whether they >> really need them or not :-) ), but for most other implementations one >> consolidated table for CDRs might be enough for all practical purposes. >> >> You also need to decide if you really want to limit yourself to CSV's. The > mod_xml_cdr module is extremely powerful and maybe lend itself to the whole > "CDR daemon" concept. You could have your daemon listen for POSTs from > xml_cdr or you could just have it scoop up the .xml files from > freeswitch/log/xml-cdr/ and process them. (Either way would work but if you > have it use the HTTP POST method you could more easily build a distributed > model.) > > I'm partial to mod_xm_cdr because it gives a very complete picture of what > happened on the call. > -MC > > > _______________________________________________ > FreeSWITCH-dev mailing list > [email protected] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > >
_______________________________________________ FreeSWITCH-dev mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
