Actually,<br><br>The goal is to not limit the functionality by over thinking how things will be used but to provide building blocks to make much<br>more possible. Our analogy for this is that if you take the common lego reference, If you have something cool built out of legos but they are super glued together it limits what you *could* have done had then not been.<br>
<br>The system that David described is indeed ideal. I have mentioned it more than once and its no coincidence that FreeSWITCH plays into that model to a tee. I do not mention it very often because I think understanding that concept alone is valuable advice that I'd prefer not to waste on deaf ears so I recommend you heed his suggestion. <br>
<br>Logging direct to DB is not a sin or anything but it's just not very reliable. We have so many ways to process call records as it is.<br>you can use the cdr_csv if you want legacy support from asterisk that you can eventually tweak with templatable output, you can even make a template that generates the log as ready to roll sql statements you can just cat into mysql.<br>
<br>We have event_socket + channel_hangup event which has all the same info that the cdr_csv uses to generate the file.<br>We have the XML cdr that is a 3 dimensional view of the call with an account of nearly everything that happend including<br>
each application executed, branching records when the call is transferred complete with a timestamp for each occurance.<br><br>--"However it would be great if freeswitch had the options for extra
functionality (auto log rotation, db cdrs etc)<br>
so that it meets the peculiarities of every different project."<br><br>A single cron entry that does kill -HUP `cat freeswitch.pid` and you have automatic rotation in unix.<br>In windows there are several cron equivs and instead of kill you can use an xml-rpc script to call the FSAPI call "fsctl send_sighup"<br>
also you can schedule it to happen automaticly with the FSAPI<br><br>sched_api @300 mygroup fsctl send_sighup<br><br>A script connected to event socket subscribed to channel_hangup can act as your DB cdr engine and has the bonus that it could<br>
connect to N boxes at once as well as be able to tell if the system was in trouble by listening for system heartbeat events and or socket disconnect.<br><br>Moral of the story, there is more already there than first appears. I've always hated the M$ paper clip so I strive not to bring him back.<br>
"It looks like you are trying to run a VoIP termination company! Shall I assume how you want your call details?"<br><br><br><br><div class="gmail_quote">On Thu, Oct 30, 2008 at 7:43 AM, <a href="mailto:regs@kinetix.gr">regs@kinetix.gr</a> <span dir="ltr"><<a href="mailto:regs@kinetix.gr">regs@kinetix.gr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
I'll try some tests with various combinations first and then decide
what's best.<br>
<br>
I have to say that I was astonished to find out that freeswitch had so
many event handlers from the very beginning.<br>
However it would be great if freeswitch had the options for extra
functionality (auto log rotation, db cdrs etc)<br>
so that it meets the peculiarities of every different project. That
would make a big difference compared to<br>
other softswitch solutions where the lack of such features prohibits
people from using them (especially in<br>
the carrier grade level). User feedback (and wish lists) is the key for
the success of an open source (or not) <br>
project...<br>
<br>
Thank you all for your replies. You' ve been very helpful.<div><div></div><div class="Wj3C7c"><br>
<br>
David Knell wrote:
<blockquote type="cite">
The sleep's done each time the directory's empty, not each time a
file's written. File open and close<br>
are trivial (it's probably still cached), and the contents are going to
have to be parsed wherever you <br>
process it.<br>
<br>
We've used exactly this to process deliver CDRs on boxes handling in
excess of 500K mins/day<br>
without issue. And, looking at one now, the CDR processor's used about
4% of the CPU time<br>
of FreeSWITCH, and about half that of the MySQL database which it
writes the records to, also<br>
on the local machine, from which they're simply copied to the main CDR
processor.<br>
<br>
It performance simply isn't worth worrying about.<br>
<br>
--Dave<br>
<blockquote type="cite">
<pre>"sleep for a couple of seconds"
But then you could only insert 1800 cdrs per hour...
If I was to insert 36000 cdrs per hour this means that I have to
open
parse
close
10 files per second. Imagine the I/O penalty just for opening - closing the file.
(the persing is the same for both situations)
</pre>
<br>
<br>
David Knell wrote:
<blockquote type="cite">
<pre><a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a> wrote:
</pre>
<blockquote type="cite">
<pre>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?
</pre>
</blockquote>
<pre>Not that you'd notice. We run XML CDR to database scripting on each box
that we use
for switching, and it's a pretty trivial task compared with switching
all that media. Doing it
this way is:-
(a) distributed - one process per box scales nicely;
(b) robust - script down, DB down, no problem: files just queue up;
(c) simple - the script logic is trivial:
- while 1
- for each file in the XML CDR directory
- open it
- parse it (XML::Simple for us)
- insert it in to the DB
- delete it
- sleep for a couple of seconds
Two error cases: can't parse or can't find data which should be there:
move the file in to
another directory to be examined by real eyes; DB insert fails: break
out of inner loop and
it'll be retried after a short pause.
--Dave
</pre>
</blockquote>
<br>
<pre><hr size="4" width="90%">
_______________________________________________
Freeswitch-users mailing list
<a href="mailto:Freeswitch-users@lists.freeswitch.org" target="_blank">Freeswitch-users@lists.freeswitch.org</a>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72">--
David Knell, Director, 3C Limited
T: 020 8114 8901 F: 020 3002 7257 M: 001 415 630 3031
<a href="http://www.3c.co.uk" target="_blank">http://www.3c.co.uk</a> </pre>
<pre><hr size="4" width="90%">
_______________________________________________
Freeswitch-users mailing list
<a href="mailto:Freeswitch-users@lists.freeswitch.org" target="_blank">Freeswitch-users@lists.freeswitch.org</a>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>