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@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@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@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org