[Asterisk-Dev] Help Debugging Dropped Call Audio - Possibly Fixed

[Kevin P. Fleming]

Matthew Roth wrote:

> That would be a great option.  Since we're recording to a RAM disk, 
> using Monitor() introduces very little overhead.  Getting the advantages 
> of the MixMonitor() infrastructure while being able to offload the 
> mixing would be the best of both worlds.  I wouldn't have to rewrite my 
> scripts that handle the recordings, either.  = )

Writing to a RAM disk helps, but it does _not_ reduce the overhead 
completely. You are still using ext2, which means it needs to do 
filesystem manipulations to create/remove/extend files, the same as it 
would on a regular disk system. They will take slightly less time, but 
not greatly so... keep in mind that with the amount of RAM you have, a 
regular on-disk filesystem would be mostly in cache anyway (the metadata 
parts) and would perform nearly the same as a RAM disk.

For experimentation purposes, I would try tmpfs instead of ext2, and 
don't actually create a ramdisk device at all... just mount tmpfs (with 
a size limit) at your /var/spool/asterisk/monitor directory (or wherever 
you are recording).

> Is that being planned?  I'd imagine we're not the only people relying on 
> that type of functionality.

Like everything else it's on the 'wishlist', but so are dozens (or 
hundreds) of other items.

> Ideally, MixMonitor() would have a mode where it was a seamless 
> replacement for Monitor().  For example, we rely on the 'm' option of 
> Monitor() and the MONITOR_EXEC/MONITOR_EXEC_ARGS variables to trigger a 
> move of the leg files to a remote machine at call completion.  If we had 
> to rely on something else, such as an hourly sweep, we'd run the risk of 
> filling the RAM disk or moving files that were still being written.

Agreed.

> I have an uncanny ability to realize stuff like that as soon as I hit 
> the send button.  I'm new to analyzing Asterisk's source, but I'm a fast 
> learner (with the proper guidance).  I'd love to be a contributor, but I 
> don't understand the code well enough yet.  What are the best resources 
> to help a person like myself get up to speed?

The Doxygen docs and the code itself are the best resources.

> Am I correct to assume that the code base of ABE is pretty similar to 
> the open source version?  I'd hate to spend time studying code that 
> doesn't resemble what we are actually running in our production 
> environment.

ABE is not available in source form except for large customers who sign 
special licensing agreements. You are correct that the code is very 
similar, although ABE version A.1/2.x is based on a snapshot of CVS HEAD 
from some time ago with most of the bug fixes backported. ABE version 
B.1.x will be based on Asterisk 1.2, and will have the new 
MixMonitor/ChanSpy functionality.