Hi Waldo,
The best I've seen so far is about 100 concurrent calls on a single
Xeon 2.4Ghz. The CPU was 100% but this does not mean anything since
this is due to GSM encoding which happens sequentially and always
leaves capture work in priority. I'm sure it can do more than that,
it's just not
At 01:19 PM 04/11/2006, you wrote:
The last point also brings up a question. Does anyone know how
gracefully Asterisk handles attempting to write leg files to a full disk?
For some number of days my * box was running with the disk set to
read only and I only discovered it when I noticed some
Another solution would be to use a dedicated recording server sniffing
RTP and signalling packets in the media path using software such as
http://www.oreka.org. Oreka automatically mixes both legs of an RTP
conversation to disk and GSM encodes the result in a separate thread
so that capture always
Hey Henri,
Long time no talk. How far have you been able to scale oreka up to?
How many simultaneous calls have you been able to record and under
what hardware config?
Thanks,
Waldo
On Apr 12, 2006, at 11:12 AM, Henri Herscher wrote:
Another solution would be to use a dedicated
Erick Perez wrote:
How much RAM disk is needed or are you using for your current needs?
We're planning to do something like this. But I can't figure proper
dimensioning.
Erick,
We are using Asterisk to handle our inbound call center operations.
There are currently 158 leg files (produced
The last point also brings up a question. Does anyone know how
gracefully Asterisk handles attempting to write leg files to a full disk?
We've had this happen twice and if it is a regular-path partition it
seems to have handled the overlap in either RAM or on the root
partition. Not sure
Matt Roth wrote:
The last point also brings up a question. Does anyone know how
gracefully Asterisk handles attempting to write leg files to a full disk?
I suspect it would fail in an ugly way
___
--Bandwidth and Colocation provided by
How much RAM disk is needed or are you using for your current needs?
We're planning to do something like this. But I can't figure proper
dimensioning.
On 4/6/06, Matt Florell [EMAIL PROTECTED] wrote:
That is what we do actually. One drive for Linux/Asterisk and a SCSI
RAID for
Matthew, thanks for your feedback and advice.
what I actually experienced was the complete breakdown of Asterisk at
around 60 concurrent recordings without it (the reality).
The drive for saving your voice recordings is the same as your OS
(Asterisk)? What do you think that save the voice
Matthew, thanks for your feedback and advice.
what I actually experienced was the complete breakdown of Asterisk at
around 60 concurrent recordings without it (the reality).
The drive for saving your voice recordings is the same as your OS
(Asterisk)? What do you think that save the voice
Matt Florell wrote:
Matthew, thanks for your feedback and advice.
what I actually experienced was the complete breakdown of Asterisk at
around 60 concurrent recordings without it (the reality).
The drive for saving your voice recordings is the same as your OS
(Asterisk)? What do
That is what we do actually. One drive for Linux/Asterisk and a SCSI
RAID for /var/spool/asterisk/monitor
I'm really surprised (and impressed) that this is working for you,
Matt. What are the specs of the RAID array (filesystem, drive speeds,
RAID level, etc.)?
We use LSILogic MegaRAID
Hi All,
In previous mail lists, people talked about a solution
to record large amount of simultaneous calls. And then it seems that RAM disk
solution was the best choice due to the I/O bottleneck of Hard disk (System). Please
find the previous discussion as follows:
Hello,
What happens a few weeks into this when you've fragmented the free
space on the drives by deleting files periodically and rewriting in
some places? The consistent performance of SATA drives goes down
dramatically when this happens, much more so than on a SCSI-based
drive system.
Also, you
On 4/3/06, Isaac Xiao [EMAIL PROTECTED] wrote:
Hi All,
In previous mail lists, people talked about a solution to record large
amount of simultaneous calls. And then it seems that RAM disk solution was
the best choice due to the I/O bottleneck of Hard disk (System). Please find
the
15 matches
Mail list logo
