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