You could also look at Oreka at sourceforge.<br><br><div><span class="gmail_quote">On 4/13/07, <b class="gmail_sendername">Matthew J. Roth</b> <<a href="mailto:mroth@imminc.com">mroth@imminc.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Savoy, Kevin - Williston, ND wrote:<br>><br>> We are looking at using Asterisk as a call recording server for an<br>> Avaya VoIP S8700 system in a multi-site VoIP Call Center. All calls<br>> will be coming in to one location and sent out via VoIP to other call
<br>> centers.<br>><br>><br>><br>> What kind of specs should we be looking at purchasing for our Asterisk<br>> server to be record up 200-300 calls simultaneously?<br>><br>I can tell you from experience that disk I/O will be your bottleneck.
<br>In our testing, call quality began to seriously deteriorate at around 60<br>simultaneous calls. Our solution was to record to a RAM disk and move<br>the leg files over NFS to a dedicated server for mixing, indexing, and
<br>retrieval.<br><br>It has been a while since the tests, but as far as I know app_monitor<br>based call recording still has a disk write in the code path that<br>bridges two channels. Unless another kind reader of this list can
<br>provide updated information or a better call recording method, I'd<br>assume this is still the case.<br><br>For our inbound call center operations, we regularly record roughly<br>200-300 simultaneous calls on a single server. The agents and queues
<br>also reside on that server, but we have taken great care to offload as<br>many processes as possible. We aren't 100% stable, but I believe most<br>of our downtime can be attributed to app_queue.<br><br>If no new information surfaces, I'd be happy to talk with you about
<br>dimensioning and our overall architecture. Keep in mind that if its an<br>option, breaking this task down so that it can be spread across multiple<br>machines will minimize the number of headaches you're going to have.
<br>><br>> Linux runs in 64 bit architecture, but does Asterisk actually take<br>> advantage of the 64 bit?<br>><br>That really depends on how you define "take advantage." We are running<br>on a 64-bit architecture, but I have no idea if we're any better off
<br>because of it.<br><br> From what I've read, you typically have to benchmark processes to see<br>if they are faster on a 64-bit OS. One definite advantage of 32-bit is<br>most code is more heavily tested for it. Some assumptions that
<br>programmers might make, such as casting a pointer to an int, do not port<br>very well to 64-bit.<br><br>However, if you end up going down the RAM disk path, you might want to<br>research whether or not a 64-bit OS would be necessary to provide enough
<br>memory.<br>><br>> Has anyone tried doing this already? What would be the best way to<br>> get the calls from the Avaya PBX over to the Asterisk recording<br>> server? Any thoughts?<br>><br>><br>I haven't implemented this particular case, but off the top of my head I
<br>would say that you could register the Avaya PBX as a SIP user agent.<br>Then you could direct all of the calls to the Asterisk server which<br>would utilize dialplan logic to record them and bridge them to their<br>desired endpoints.
<br><br>Once again, I'm relying on the other readers of this list to point out<br>any naivety on my part. My best thinking doesn't usually occur at 8:30<br>on Friday evening.<br><br>I hope this is helpful,<br><br>
Matthew Roth<br>InterMedia Marketing Solutions<br>Software Engineer and Systems Developer<br><br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com
</a> --<br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</blockquote></div><br>