Hi,
1 - You will need to store CDR's temporary to a local file and have a daemon that read and archive these. Do it any other way and you will loose CDR records on regular basis if database or network hicks up. 2 - A CDR contains some standard variables like a unique call-id, start-time, duration, DDI, CLI etc. But, an iVR will typically want to add custom parameters that are specific for the business/application. 3. Some IVR applications require Audit logs, meaning you record action points in the application. In a phone-banking etc the CDR should show money transfers and other operations the user performed. This is often used in for auditing, but also for analysing/optimising the IVR. So in short - if you changed your module to be a stand-alone archive module that reads CDR files and convert it to some target archive format it could be useful. Jan _____ From: freeswitch-dev-boun...@lists.freeswitch.org [mailto:freeswitch-dev-boun...@lists.freeswitch.org] On Behalf Of Vitalii Colosov Sent: 21. mai 2010 16:58 To: freeswitch-dev@lists.freeswitch.org Subject: [Freeswitch-dev] Would like to create and contribute a module "mod_cdr_logic" Hi group, I would like to create and contribute to the community a module: "mod_cdr_logic" (or whatever name will be proposed). Do you think ***from your experience*** that there is a practical need in such module, or better to concentrate on something else :-) ? In high level: Module will export CDRs directly into the database with failover, applying business rules (with regular expressions) to the values exported More detailed: After the call is finished, module will export selected chanel variables directly into any provided table (odbc used). It will apply business rules to the selected values (based on regular expressions, condition-action dialplan style). Module will produce one CDR per leg (outgoing/incoming, configurable). Also it will support fail over: if the main database is not available, it will try to export into a backup database, and if that will be down as well, it will dump into a local CSV file. In the config file one will provide: 1.Mapping rule - variable name to the corresponding table field name 2.Set of business rules to apply Config file example (will be in regular xml eventually): -------------------------------------------------------------------- #these are the values that are taken directly from channel variables <channel_variables_map> #channel variable-->mapped to the table field calling_number->calling_number destination_number->called_number dialed_dtmf_digits->dialed_digits <channel_variables_map/> #these are the new values that will be determined at the business rules stage <new_variables> sales_department_call->sales_department_call technical_department_call->technical_department_call one_more_lost_client->one_more_lost_client one_more_happy_client->one_more_happy_client <new_variables/> <rules> <condition field="dialed_dtmf_digits" expression="^(1)(\d+)"> <action set="sales_department_call=1"/> <anti-action set="technical_department_call=1"/> <condition/> <condition field="hangup_cause" expression="NO_ANSWER"> <action set="one_more_lost_client=1"/> <anti-action set="one_more_happy_client=1"/> <condition/> <rules/> -------------------------------------------------------------------- Would be glad to hear your opinion regarding usefulness or useless of such module in the contrib dir. Thank you, Vitalie
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
