[Freeswitch-users] mod_cdr revival (or new module maybe)

[regs at kinetix.gr]

Good point. I have got this kind of behavior (cdrs push model) in my 
current system (using radius servers).
The only drawback of this method is that if you want to be absolutely 
sure that all the cdrs were handled by
the web server (or radius server) you have to check at certain intervals 
every cdr one by one (and handle those left
unhandled for various reasons (network, excessive web server load etc.))

But for my next project I am somewhat forced to use a "cdrs-pull" method 
where a process will "pull" cdrs
from the server at its own pace making this extra check unnecessary.

I will wait for an automatic log rotation as Shawn Lewis wrote. I think 
that will do the job.

Michael Collins wrote:
>> Yes, the xml files give you tons of info... but isn't it a little
>> insufficient - performance wise -
>> to open and close so many files in such a little time. In a PBX
>> environment that wouldn't be an
>> issue but if we get to the small-voip-carrier level (some thousand
>>     
> cdrs
>   
>> per hour)
>> that could slow things down considerably, wouldn't it?
>>
>> Thanks again for your prompt replies,
>>
>>     
>
> At that level of activity then I would assume you'd want a more robust
> solution which obviously would involve a server handling the CDRs
> separately. That's where XML is a real winner: it can POST CDRs to a web
> server and the webserver can handle all the pre-processing and db fun
> stuff. And if the connection to the webserver failed, the CDRs would be
> put on disk so that they aren't lost forever. Also, the webserver could
> cache the CDRs to its disk (or whatever storage) if the db itself went
> down but the webserver stayed up.
>
> Just a thought, anyway. It may be extra layers but it's also extra
> control.
>
> -MC
>
>
>   
>> Michael Collins wrote:
>>     
>>>> Yes, I agree. But one could use the two methods combined (csv or
>>>>         
> xml +
>   
>>>> db) for redundancy.
>>>>
>>>> Is there any consideration regarding automatic log rotation (e.g.
>>>> hourly, or user specified)
>>>> without the need of a HUP? Now, that could make things a lot easier
>>>>
>>>>         
>>> for
>>>
>>>       
>>>> the development of
>>>> an external csv to db aggregation script because the script would
>>>>         
> read
>   
>>>> from a closed (not used by freeswitch
>>>> at the time) CDRs file. And the developer could be sure that the
>>>>         
> cdrs
>   
>>>> contained in that file would
>>>> have a hangup timestamp that could be described by the filename
>>>>         
> (e.g.
>   
>>>> 20080101_010000.csv).
>>>>
>>>>         
>>> For the record, I've been dumping all my XML CDRs into a particular
>>> directory and letting a script pick them up and process them. I
>>>       
> think
>   
>>> this is the best of both worlds: you get individual files with tons
>>>       
> of
>   
>>> info on each call and you can have a process that picks up those
>>>       
> files
>   
>>> and inserts them into the db. If the db is down then the CDRs aren't
>>> lost - they just accumulate in the directory until you get the
>>>       
> db/script
>   
>>> thing working again.
>>>
>>> Just my $.02
>>>
>>> -MC
>>>
>>> _______________________________________________
>>> 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
>>     
>
> _______________________________________________
> 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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20081030/5def9fa4/attachment-0002.html