[Freeswitch-dev] Odp: Re: Conference CDRs via http

Mon Jan 21 19:02:55 MSK 2013

Hi,

I just created an iisue (FS-5042) with a patch for CDR events from mod_conferences. Any feedback appreciated.

Mariusz

Dnia Wtorek, 4 Grudnia 2012 02:00 Anthony Minessale <anthony.minessale at gmail.com> napisał(a)
> I have no had time to do it but if you want to start a patch I can work on getting it in.
> 
> 
> On Mon, Dec 3, 2012 at 6:56 PM, Seven Du <dujinfang at gmail.com> wrote:
> > 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 DuSent with Sparrow
> > 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 at 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 at freeswitch.org
> > > >  http://www.freeswitchsolutions.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 at 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 at freeswitch.orghttp://www.freeswitchsolutions.com
> > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server
> > > Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
> > > Join Us At ClueCon - Aug 7-9, 2012
> > > FreeSWITCH-dev mailing listFreeSWITCH-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-devUNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
> > 
> > _________________________________________________________________________
> >  Professional FreeSWITCH Consulting Services:
> >  consulting at freeswitch.org
> >  http://www.freeswitchsolutions.com
> >  
> >  
> >  
> >  
> >  Official FreeSWITCH Sites
> >  http://www.freeswitch.org
> >  http://wiki.freeswitch.org
> >  http://www.cluecon.com
> >  
> >  FreeSWITCH-dev mailing list
> >  FreeSWITCH-dev at lists.freeswitch.org
> >  http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> >  UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> >  http://www.freeswitch.org
> >  
> 
> -- 
> Anthony Minessale II
> 
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
>  Twitter: http://twitter.com/FreeSWITCH_wire
> 
> AIM: anthm
> MSN:anthony_minessale at hotmail.com
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>  IRC: irc.freenode.net #freeswitch
> 
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> googletalk:conf+888 at conference.freeswitch.org
>  pstn:+19193869900