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
I can vouch for the fact that some folks keep showing up and asking for this kind of feature. We're not big fans of the straight-to-db paradigm, but others certainly are. I think the devs would be agreeable to have this in contrib for people to play with at their own risk. As long as the core devs & company don't have to answer questions about your buggy module ;) then it should be okay. Just be ready to offer support for your module because everyone who uses it will come asking for advice. -MC On Fri, May 21, 2010 at 7:57 AM, Vitalii Colosov <vetali100@gmail.com>wrote:
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
As I have been advised back in the days, if you happen to do this, copy the vars from the session thread and launch a new one, otherwise you are going to lock sessions no matter what. JM On Fri, May 21, 2010 at 7:27 PM, Michael Collins <msc@freeswitch.org> wrote:
I can vouch for the fact that some folks keep showing up and asking for this kind of feature. We're not big fans of the straight-to-db paradigm, but others certainly are. I think the devs would be agreeable to have this in contrib for people to play with at their own risk. As long as the core devs & company don't have to answer questions about your buggy module ;) then it should be okay. Just be ready to offer support for your module because everyone who uses it will come asking for advice.
-MC
On Fri, May 21, 2010 at 7:57 AM, Vitalii Colosov <vetali100@gmail.com>wrote:
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
_______________________________________________ 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
Hi João, Today I got the following log message and recalled your advice to launch a new thread: switch_core_session.c:1171 Session 73 (sofia/external/00...mynumber) Locked, Waiting on external entities We had a problem to establish a call (NO_ROUTE_DESTINATION) - previously all calls to same direction were successful. Is this kind of problems you meant to avoid by launching new thread? If not, could anyone please advice what does this message mean (Locked, Waiting on external entities) and whether it can cause a call attempt to fail with NO_ROUTE_DESTINATION? I am referring to: 2010/5/22 João Mesquita <jmesquita@freeswitch.org>
As I have been advised back in the days, if you happen to do this, copy the vars from the session thread and launch a new one, otherwise you are going to lock sessions no matter what.
Thank you, Vitalie 2010/5/22 João Mesquita <jmesquita@freeswitch.org>
As I have been advised back in the days, if you happen to do this, copy the vars from the session thread and launch a new one, otherwise you are going to lock sessions no matter what.
JM
On Fri, May 21, 2010 at 7:27 PM, Michael Collins <msc@freeswitch.org>wrote:
I can vouch for the fact that some folks keep showing up and asking for this kind of feature. We're not big fans of the straight-to-db paradigm, but others certainly are. I think the devs would be agreeable to have this in contrib for people to play with at their own risk. As long as the core devs & company don't have to answer questions about your buggy module ;) then it should be okay. Just be ready to offer support for your module because everyone who uses it will come asking for advice.
-MC
On Fri, May 21, 2010 at 7:57 AM, Vitalii Colosov <vetali100@gmail.com>wrote:
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
_______________________________________________ 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
_______________________________________________ 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
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@lists.freeswitch.org [mailto:freeswitch-dev-bounces@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
Hi Jan, Thanks for your inputs. Basically what you described here makes me plan to create completely different thing that I was planning initially. It should be "mod_cdr_mediation" - it must read the CDRs prepared by mod_cdr_csv, apply business rules, insert into the database and move successfully processed CDRs into archive directory. If to go in this direction, I would also give the possibility to invoke a Lua/JS script before exporting CDRs, so user will create complex business logic to apply on the CDR values. It will give a lot of flexibility, for example user can decide whether to skip some CDRs from inserting into the database, can enhance the values, etc... Lua/FS script will receive selected CDR fields from the session variables, and enhanced / new values will be sent back to the mod_cdr_mediation for exporting. Do you think this idea reflects what you described? Thank you, Vitalie
Firstly I would find out what's already here because FS do have some CDR support. A generic CDR daemon could be useful, though you should take into consideration that a distributed telecom system might need to write parts of a CDR on different computers. _____ From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Vitalii Colosov Sent: 22. mai 2010 18:35 To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Would like to create and contribute a module "mod_cdr_logic" Hi Jan, Thanks for your inputs. Basically what you described here makes me plan to create completely different thing that I was planning initially. It should be "mod_cdr_mediation" - it must read the CDRs prepared by mod_cdr_csv, apply business rules, insert into the database and move successfully processed CDRs into archive directory. If to go in this direction, I would also give the possibility to invoke a Lua/JS script before exporting CDRs, so user will create complex business logic to apply on the CDR values. It will give a lot of flexibility, for example user can decide whether to skip some CDRs from inserting into the database, can enhance the values, etc... Lua/FS script will receive selected CDR fields from the session variables, and enhanced / new values will be sent back to the mod_cdr_mediation for exporting. Do you think this idea reflects what you described? Thank you, Vitalie
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. 2010/5/22 Jan Berger <jan.berger@video24.no>
Firstly I would find out what’s already here because FS do have some CDR support.
A generic CDR daemon could be useful, though you should take into consideration that a distributed telecom system might need to write parts of a CDR on different computers.
------------------------------
*From:* freeswitch-dev-bounces@lists.freeswitch.org [mailto: freeswitch-dev-bounces@lists.freeswitch.org] *On Behalf Of *Vitalii Colosov *Sent:* 22. mai 2010 18:35
*To:* freeswitch-dev@lists.freeswitch.org *Subject:* Re: [Freeswitch-dev] Would like to create and contribute a module "mod_cdr_logic"
Hi Jan,
Thanks for your inputs.
Basically what you described here makes me plan to create completely different thing that I was planning initially.
It should be "mod_cdr_mediation" - it must read the CDRs prepared by mod_cdr_csv, apply business rules, insert into the database and move successfully processed CDRs into archive directory.
If to go in this direction, I would also give the possibility to invoke a Lua/JS script before exporting CDRs, so user will create complex business logic to apply on the CDR values.
It will give a lot of flexibility, for example user can decide whether to skip some CDRs from inserting into the database, can enhance the values, etc...
Lua/FS script will receive selected CDR fields from the session variables, and enhanced / new values will be sent back to the mod_cdr_mediation for exporting.
Do you think this idea reflects what you described?
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
On Sat, May 22, 2010 at 2:04 PM, Vitalii Colosov <vetali100@gmail.com>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
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 <msc@freeswitch.org>wrote:
On Sat, May 22, 2010 at 2:04 PM, Vitalii Colosov <vetali100@gmail.com>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 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
Hello Vitalie I've made a thingy which can implement complex business logic. It's a FastCGI daemon that works together with mod_xml_cdr <http://wiki.freeswitch.org/wiki/Mod_xml_cdr> to process CDR records. Right now xmlcdrd can store CDR fields into MySQL tables and/or run custom Lua scripts against fields retrieved with XPATH expressions from CDR body. Functionality of xmlcdrd could be extended by writing plugins for other databases or different script languages. Despite I'm running it in production, it needs some polish. Please have a look at: http://wiki.freeswitch.org/wiki/Xmlcdrd for full description. Sorry, my English is terrible, much worse than my Russian ) If you are interested, we could cooperate. Best Regards, Nazim On 05/22/2010 09:35 PM, Vitalii Colosov wrote:
Hi Jan,
Thanks for your inputs.
Basically what you described here makes me plan to create completely different thing that I was planning initially.
It should be "mod_cdr_mediation" - it must read the CDRs prepared by mod_cdr_csv, apply business rules, insert into the database and move successfully processed CDRs into archive directory.
If to go in this direction, I would also give the possibility to invoke a Lua/JS script before exporting CDRs, so user will create complex business logic to apply on the CDR values.
It will give a lot of flexibility, for example user can decide whether to skip some CDRs from inserting into the database, can enhance the values, etc...
Lua/FS script will receive selected CDR fields from the session variables, and enhanced / new values will be sent back to the mod_cdr_mediation for exporting.
Do you think this idea reflects what you described?
Thank you, Vitalie
Hi Nazim, mod_xml_cdr is able to send CDR to apache server, and I was using it successfully until I created the module that writes CDRs directly into the database. I thought to add some business logic ability and share with the community. I am sure your idea will also find many grateful users. Personally from my side, I wanted to completely avoid using any HTTP servers (many reasons, bottom line - it's just not REALLY needed for such task in many implementations). I think I will continue working in this direction and it will find some users (like me) who will also use it. The only problem here I see is performance - maybe it will not be suitable for really LARGE implementations. Vitalie
Hi team, I 've created first version of *mod_cdr_logic*. And I would like to ask you what is the best way to share it with the community? It can be provided in contrib dir or I can put it on my personal site, if you think it is better not to include it into contrib dir at this stage. Module exports any channel variables into the provided table using ODBC in core. It supports master and backup database (also I will add failover dump into a file in a future version if it will be required). *The most important thing of this module is the ability to execute set of Lua or Java scripts before exporting CDR into the table.* *So one can implement any business logic, set new channel variables based on some conditions, and then export them all into the table as CDR.* Config file (attached) contains 3 sections: 1. Database and table settings 2. Scripts to be executed before export 3. Channel variables to be exported (and corresponding table field names). I would greatly appreciate your inputs! P.S. I tested it carefully and it looks stable, but for sure it will need few months of community intensive testing (and bug fixing if any) before being considered fully stable. *Also, I would greatly appreciate any comments of the development team on the source code (especially on string concatenation and memory management).* Regards, vIT 2010/5/26 Vitalii Colosov <vetali100@gmail.com>
Hi Nazim,
mod_xml_cdr is able to send CDR to apache server, and I was using it successfully until I created the module that writes CDRs directly into the database. I thought to add some business logic ability and share with the community.
I am sure your idea will also find many grateful users.
Personally from my side, I wanted to completely avoid using any HTTP servers (many reasons, bottom line - it's just not REALLY needed for such task in many implementations).
I think I will continue working in this direction and it will find some users (like me) who will also use it. The only problem here I see is performance - maybe it will not be suitable for really LARGE implementations.
Vitalie
Hi Vitalie, Where is the source code? Moises Silva Senior Software Engineer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com On Sun, Jun 6, 2010 at 2:13 PM, Vitalii Colosov <vetali100@gmail.com> wrote:
Hi team,
I 've created first version of *mod_cdr_logic*. And I would like to ask you what is the best way to share it with the community? It can be provided in contrib dir or I can put it on my personal site, if you think it is better not to include it into contrib dir at this stage.
Module exports any channel variables into the provided table using ODBC in core. It supports master and backup database (also I will add failover dump into a file in a future version if it will be required).
*The most important thing of this module is the ability to execute set of Lua or Java scripts before exporting CDR into the table.* *So one can implement any business logic, set new channel variables based on some conditions, and then export them all into the table as CDR.*
Config file (attached) contains 3 sections:
1. Database and table settings 2. Scripts to be executed before export 3. Channel variables to be exported (and corresponding table field names).
I would greatly appreciate your inputs!
P.S. I tested it carefully and it looks stable, but for sure it will need few months of community intensive testing (and bug fixing if any) before being considered fully stable.
*Also, I would greatly appreciate any comments of the development team on the source code (especially on string concatenation and memory management). *
Regards, vIT
2010/5/26 Vitalii Colosov <vetali100@gmail.com>
Hi Nazim,
mod_xml_cdr is able to send CDR to apache server, and I was using it successfully until I created the module that writes CDRs directly into the database. I thought to add some business logic ability and share with the community.
I am sure your idea will also find many grateful users.
Personally from my side, I wanted to completely avoid using any HTTP servers (many reasons, bottom line - it's just not REALLY needed for such task in many implementations).
I think I will continue working in this direction and it will find some users (like me) who will also use it. The only problem here I see is performance - maybe it will not be suitable for really LARGE implementations.
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
Hi Moises, Basically this was my question :) - what is the best way to share it with the community? Where can I put the source code? Regards, Vitalie 2010/6/6 Moises Silva <moises.silva@gmail.com>
Hi Vitalie,
Where is the source code?
Moises Silva Senior Software Engineer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
On Sun, Jun 6, 2010 at 2:13 PM, Vitalii Colosov <vetali100@gmail.com>wrote:
Hi team,
I 've created first version of *mod_cdr_logic*. And I would like to ask you what is the best way to share it with the community? It can be provided in contrib dir or I can put it on my personal site, if you think it is better not to include it into contrib dir at this stage.
Module exports any channel variables into the provided table using ODBC in core. It supports master and backup database (also I will add failover dump into a file in a future version if it will be required).
*The most important thing of this module is the ability to execute set of Lua or Java scripts before exporting CDR into the table.* *So one can implement any business logic, set new channel variables based on some conditions, and then export them all into the table as CDR.*
Config file (attached) contains 3 sections:
1. Database and table settings 2. Scripts to be executed before export 3. Channel variables to be exported (and corresponding table field names).
I would greatly appreciate your inputs!
P.S. I tested it carefully and it looks stable, but for sure it will need few months of community intensive testing (and bug fixing if any) before being considered fully stable.
*Also, I would greatly appreciate any comments of the development team on the source code (especially on string concatenation and memory management). *
Regards, vIT
2010/5/26 Vitalii Colosov <vetali100@gmail.com>
Hi Nazim,
mod_xml_cdr is able to send CDR to apache server, and I was using it successfully until I created the module that writes CDRs directly into the database. I thought to add some business logic ability and share with the community.
I am sure your idea will also find many grateful users.
Personally from my side, I wanted to completely avoid using any HTTP servers (many reasons, bottom line - it's just not REALLY needed for such task in many implementations).
I think I will continue working in this direction and it will find some users (like me) who will also use it. The only problem here I see is performance - maybe it will not be suitable for really LARGE implementations.
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
_______________________________________________ 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
Oh, genius me .. For starters I guess you can add it as a new feature to JIRA ( jira.freeswitch.org ) Moises Silva Senior Software Engineer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com On Sun, Jun 6, 2010 at 3:20 PM, Vitalii Colosov <vetali100@gmail.com> wrote:
Hi Moises,
Basically this was my question :) - what is the best way to share it with the community?
Where can I put the source code?
Regards, Vitalie
2010/6/6 Moises Silva <moises.silva@gmail.com>
Hi Vitalie,
Where is the source code?
Moises Silva Senior Software Engineer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
On Sun, Jun 6, 2010 at 2:13 PM, Vitalii Colosov <vetali100@gmail.com>wrote:
Hi team,
I 've created first version of *mod_cdr_logic*. And I would like to ask you what is the best way to share it with the community? It can be provided in contrib dir or I can put it on my personal site, if you think it is better not to include it into contrib dir at this stage.
Module exports any channel variables into the provided table using ODBC in core. It supports master and backup database (also I will add failover dump into a file in a future version if it will be required).
*The most important thing of this module is the ability to execute set of Lua or Java scripts before exporting CDR into the table.* *So one can implement any business logic, set new channel variables based on some conditions, and then export them all into the table as CDR. *
Config file (attached) contains 3 sections:
1. Database and table settings 2. Scripts to be executed before export 3. Channel variables to be exported (and corresponding table field names).
I would greatly appreciate your inputs!
P.S. I tested it carefully and it looks stable, but for sure it will need few months of community intensive testing (and bug fixing if any) before being considered fully stable.
*Also, I would greatly appreciate any comments of the development team on the source code (especially on string concatenation and memory management).*
Regards, vIT
2010/5/26 Vitalii Colosov <vetali100@gmail.com>
Hi Nazim,
mod_xml_cdr is able to send CDR to apache server, and I was using it successfully until I created the module that writes CDRs directly into the database. I thought to add some business logic ability and share with the community.
I am sure your idea will also find many grateful users.
Personally from my side, I wanted to completely avoid using any HTTP servers (many reasons, bottom line - it's just not REALLY needed for such task in many implementations).
I think I will continue working in this direction and it will find some users (like me) who will also use it. The only problem here I see is performance - maybe it will not be suitable for really LARGE implementations.
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
_______________________________________________ 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
_______________________________________________ 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
I have created new feature and attached the module sources and config file. http://jira.freeswitch.org/browse/FSMOD-55 Regards, Vitalie 2010/6/6 Moises Silva <moises.silva@gmail.com>
Oh, genius me ..
For starters I guess you can add it as a new feature to JIRA ( jira.freeswitch.org )
Moises Silva Senior Software Engineer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
On Sun, Jun 6, 2010 at 3:20 PM, Vitalii Colosov <vetali100@gmail.com>wrote:
Hi Moises,
Basically this was my question :) - what is the best way to share it with the community?
Where can I put the source code?
Regards, Vitalie
2010/6/6 Moises Silva <moises.silva@gmail.com>
Hi Vitalie,
Where is the source code?
Moises Silva Senior Software Engineer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
On Sun, Jun 6, 2010 at 2:13 PM, Vitalii Colosov <vetali100@gmail.com>wrote:
Hi team,
I 've created first version of *mod_cdr_logic*. And I would like to ask you what is the best way to share it with the community? It can be provided in contrib dir or I can put it on my personal site, if you think it is better not to include it into contrib dir at this stage.
Module exports any channel variables into the provided table using ODBC in core. It supports master and backup database (also I will add failover dump into a file in a future version if it will be required).
*The most important thing of this module is the ability to execute set of Lua or Java scripts before exporting CDR into the table.* *So one can implement any business logic, set new channel variables based on some conditions, and then export them all into the table as CDR. *
Config file (attached) contains 3 sections:
1. Database and table settings 2. Scripts to be executed before export 3. Channel variables to be exported (and corresponding table field names).
I would greatly appreciate your inputs!
P.S. I tested it carefully and it looks stable, but for sure it will need few months of community intensive testing (and bug fixing if any) before being considered fully stable.
*Also, I would greatly appreciate any comments of the development team on the source code (especially on string concatenation and memory management).*
Regards, vIT
2010/5/26 Vitalii Colosov <vetali100@gmail.com>
Hi Nazim,
mod_xml_cdr is able to send CDR to apache server, and I was using it successfully until I created the module that writes CDRs directly into the database. I thought to add some business logic ability and share with the community.
I am sure your idea will also find many grateful users.
Personally from my side, I wanted to completely avoid using any HTTP servers (many reasons, bottom line - it's just not REALLY needed for such task in many implementations).
I think I will continue working in this direction and it will find some users (like me) who will also use it. The only problem here I see is performance - maybe it will not be suitable for really LARGE implementations.
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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
participants (6)
-
Jan Berger
-
João Mesquita
-
Michael Collins
-
Moises Silva
-
Nazim Aghabayov
-
Vitalii Colosov