[Freeswitch-users] Call accounting - CDR's

Ken Rice krice at suspicious.org
Fri Feb 6 13:18:39 PST 2009


This is built into mod_xml_cdr and should be covered on its wiki page...

I personally don't post the records to a web server as I think that's too
much over head at this load... I use a script to scrape the directory and
process the CDRs...

This gives me the FileSystem as a buffer, and allows me to get a ton of info
out of the xml cdrs like custom channel variables etc

K

> From: Nik Middleton <nik.middleton at noblesolutions.co.uk>
> Reply-To: <freeswitch-users at lists.freeswitch.org>
> Date: Fri, 6 Feb 2009 21:07:12 -0000
> To: <freeswitch-users at lists.freeswitch.org>
> Subject: Re: [Freeswitch-users] Call accounting - CDR's
> 
> So you're simply posting this file to a web server? How do you find the load
> on it at this rate of calls?
> 
> BTW can anyone point me to resources discussing how to do this? (Using a web
> server to post data to a db) I've not this sort of thing before, and I'm not
> too sure what I should be goggling for
> 
> 
> Regards,
> 
> 
> -----Original Message-----
> From: freeswitch-users-bounces at lists.freeswitch.org
> [mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Ken Rice
> Sent: 06 February 2009 17:40
> To: freeswitch-users at lists.freeswitch.org
> Subject: Re: [Freeswitch-users] Call accounting - CDR's
> 
> Mod_xml_cdr will drop a file to the file system on failure to post. You can
> also leverage this drop a file to the file system and run a CDR processor
> locally.
> 
> We handle call rates in the 500+ range using the local file system as a
> caching mechanism and a simple PHP script to rate the CDRs and load them
> into a pgsql db.
> 
> 
> 
> 
>> From: Adam Long <ajlong at worldlink.net>
>> Reply-To: <freeswitch-users at lists.freeswitch.org>
>> Date: Fri, 6 Feb 2009 12:30:34 -0500
>> To: <freeswitch-users at lists.freeswitch.org>
>> Subject: Re: [Freeswitch-users] Call accounting - CDR's
>> 
>> Is mod_cdr_xml asynchronous ... by that I mean .. if there is a communication
>> failure how
> does this effect load on the system or the call for that
>> matter...
> it wouldn¹t hold up the progress or delay the turn up of the call or
>> anything would it?
> 
> I understand it would write to the error directory (but my
>> thoughts are what is the impact of
> this beyond the obvious IO hit)
> 
> I guess a
>> good question is what is more load intensive???
> 
> 1.) mod_cdr_csv (with batch
>> script that loads into DB somewhere)
> 2.) mod_cdr_xml (posting to lighttpd on
>> remote host inserting into DB)
> 
> I'm thinking about this for a system that
>> would be handling in excess of 200-300 call setups
> per
>> second.
> 
> -Adam
> 
> -----Original Message-----
> From:
>> freeswitch-users-bounces at lists.freeswitch.org
>> [mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Rupa
>> Schomaker (lists)
> Sent: Friday, February 06, 2009 11:27 AM
> To:
>> freeswitch-users at lists.freeswitch.org
> Subject: Re: [Freeswitch-users] Call
>> accounting - CDR's
> 
> Use the script in scripts/contrib/wasim/ as a starting
>> point.
> 
> Basically, you log to csv files, and then the script periodically
>> picks
> them up and loads to your DB.  This is using mysql as an example,
>> but
> you can do the same with postgres as well.
> 
> If you need realtime inserts,
>> then use mod_cdr_xml and have those post
> to a script on a webserver that
>> parses the xml and inserts into
> appropriate tables.  This is what I use along
>> with a rails app.
> 
> Remember that if you do real time, you also need to
>> periodically scrape
> the error directory and load those (mod_cdr_xml will save
>> to error if it
> can't successfully post to your script).
> 
> On 2/6/2009 10:09 AM,
>> Nik Middleton wrote:
>> Hi Guys
>> 
>>  
>> 
>> I¹m looking for some pointers on
>> how to collect  CDR¹s and store in
>> mysql.  Is there anything built in yet?
>> 
>> 
>>  
>> 
>> I can rate the calls as a batch process, I simply need the call
>> data.
>> 
>>  
>> 
>> Regards
>> 
>> 
> 
> 
> _______________________________________________
> Freeswitch-users mailing
>> list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman
>> /listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/opt
>> ions/freeswitch-users
> http://www.freeswitch.org
> 
> 
> ____________________________
>> ___________________
> Freeswitch-users mailing
>> list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman
>> /listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/opt
>> ions/freeswitch-users
> http://www.freeswitch.org
> 
> 
> 
> 
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
> 
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org






More information about the FreeSWITCH-users mailing list