Any update on this? How about just fire a SWITCH_EVENT_CDR with raw event headers so mod like mod_cdr_pg_csv can listen to it and write to db without parsing back the XML? Thanks. -- Seven Du Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Tuesday, June 12, 2012 at 10:31 AM, Anthony Minessale wrote:
B is the right choice. The size of the body has no limit. How bout, if a certian header exists in the event with a local file path, then the the mod opens the referenced file for delivery; Otherwise it uses the body if it exists. On Jun 11, 2012 8:39 PM, "Mariusz Czulada" <manieq@wp.eu (mailto:manieq@wp.eu)> wrote:
Hi all,
I was thinking about sending CDRs via HTTP in a same or similar way mod_xml_cdr does. I consider implementing this (unless someone else is working on it) but first wanted to discuss with you the best approach.
A. All in mod_conference
This would require to copy many fragments of code from mod_xml_cdr into mod_conference. Also same configuration parameters used in xml_cdr must be processed and used for sending data. The advantage for this solution is that everything related to this mechanism is included in this module. Drawback: if something in mod_xml_cdr requires fixing or extending, probably the same changes should by applied in related parts of mod_conference.
B. mod_conference builds, mod_xml_cdr sends data
For this solution I'll give more details. 1. New event type should be added (like SWITCH_EVENT_CDR) 2. When a module (in this case: mod_conference) wants to store CDR via HTTP it must fire an event of that type and: - "Event-Subclass" set (like "conference") - Only common headers are needed, plus... - "Content-Type" and "Content-Length" must be set - CDR data must be build as XML in a module and added as an event content. 3. mod_xml_cdr will listen to this event type. 4. For each event subclass which mod_xml_cdr must must react, configuration file will contain a set of params same as for generic channel CDRs. 5. If subclass matches configuration, mod_xml_cdr reads data from event content and sends them according to configuration.
Changes in mod_conference: - one new parameter for each profile (like "cdr-via-event=yes|no") - if "yes" then xml must be build even if "cdr-log-dir" is unset - if "yes", then an event must be fired as described above
Changes in mod_xml_cdr: - extra parameters from configuration to be parsed (like '<settings subclass="conference">....</settings>') - bind to SWITCH_EVENT_CDR - if 'Event-Subclass' matches configuration, a content of the event will be sent via HTTP (probably most of 'my_on_report' routine bellow 'try to post it to the web server' comment will be reused)
A [small] drawback is that it makes an indirect module dependency, but we already have such situations (like mod_shout needed to record a conference in mp3).
Advantages are: - one can create an external tool for handling this type of event (to store it directly in db or send it with other protocols) - this mechanism can be easily reused in other modules if needed; maybe in mod_callcenter, maybe in other components. No further changes in mod_xml_cdr should be needed.
What is unknown to me is a maximum size of event content. Conference CDR XMLs can be quite big - will it be a problem to send it this way?
I think the second solution is better and more universal but I'd like to hear your opinions about this case.
Regards,
Mariusz
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org (mailto:consulting@freeswitch.org) http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org (mailto: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
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org (mailto:consulting@freeswitch.org) http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org (mailto: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