[asterisk-biz] Call Recording System information request

[Trixter aka Bret McDanel]

On Wed, 2008-07-02 at 19:40 -0400, Matt Florell wrote:
> If you record to RAM drive there really isn't a 60-70 call recording
> limit. We have successfully recorded over 250 calls concurrently on a
> single server with Asterisk.


it would almost seem to make more sense to have a private recording
network, a module that will grab each frame and send it off, and let
something else deal with recording.  This can also be handy for CALEA
stuff, although the ranch networks approach of having a switch do it
seems to make a bit more sense - but that doesnt work on E1/T1s.  

Yes there can be problems with this, however there are problems with
recording to a ram disk depending on how its being used.  For example
when recording you cannot normally move the file off the ram disk until
the call has completed.  If you end up with a large number of calls that
last long durations (or perhaps a large quantity that all start/end
about the same time) you can backlog writing to disk, and run out of
space on the ram disk.

Assuming 8 bit 8khz mono, each call takes 8000 bytes per second
(excluding any compression, or file containers like wav format).
8000*250=2M/sec, 120M/min, 7.2G/hr.  So if you have 250 calls or so that
all last over an hour you have to have more than 8G for a ram disk.
Granted ram is cheaper now, and this is not as problematic as it would
have been years ago, there could be alternatives to this for people with
this type of calling pattern (again short duration calls should be
removed in time).  For comparison my laptop does 19.5MB/sec and its not
even a "fast" disk.

And remember when allocating the ram disk you would want to plan for
slop space.  Granted the 2M/sec is slow for a disk, even a network disk,
so you should be able to offload the files and delete them before your
slop space fills, but its still something you have to contend with.

Now for a potential solution.  If, instead of a ram disk, the call
logging module spawned a new thread and allocated a dynamic buffer, it
could allow that buffer to fill (ram buffer instead of ram disk) and the
writer thread could log the frames to disk in its own time.
Fundamentally it would be even better if you did not copy the memory
from one buffer to another but instead used the same one for call
processing and logging, but to make that efficient you have to have a
pooled memory manager and some other stuff.  It would probably be quite
invasive to get this feature to work at top speed, but not impossible.

Larger writes with less frequency will generally reduce the overall cpu
load, and give more time for other processes to run.  There wont be a
write bottleneck affecting call performance because what might block
will be a separate thread and not block the call itself.  By adusting
the run priority you can ensure that the rtp/tdm/etc threads can preempt
the file writing thread.

This way the overall memory used would be only the aggregrate size of
the buffers, not the entire call length.  Call duration would not matter
as much (frequent short calls would take a hit though as the new thread
would add slightly to the call setup time, this would be minimal
though).


-- 
Trixter http://www.0xdecafbad.com     Bret McDanel
Belfast +44 28 9099 6461        US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!