[Freeswitch-dev] Would like to create and contribute a module "mod_cdr_logic"
Jan Berger
jan.berger at video24.no
Fri May 21 21:47:47 PDT 2010
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-bounces at lists.freeswitch.org
[mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Vitalii
Colosov
Sent: 21. mai 2010 16:58
To: freeswitch-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100522/71839ebc/attachment-0001.html
More information about the FreeSWITCH-dev
mailing list