When making recordings of g729 channels at least two decoders will be used. This means that if you have 10 licenses you can have a maximum concurrency of 5 calls going through your system that is being recorded. For anything but the smallest of switches this is not acceptable.
In addition, recording to .wav is a rather space-consuming process. Instead, we’d like to minimize the g729 license usage, as well as optimizing disk-consumption.
It should be stated that nothing that is about to be said here is currently tested. This is merely a conceptual idea that I’m busy formulating, but all of it should work, as is.
Previously, I’ve used tcpdump to obtain the raw rtp streams to extract the voice data, these can be easy (and quickly) converted to wav, but is unmixed (meaning each direction ends up in it’s own file). Based on the fact that I can have files recorded to .g729 without using encoders/decoders permitting the channel is g729 I hoping that I can also Monitor() (NOT MixMonitor) the input/output of a particular channel to .g729. If this is the case we can separately record the two audio directions separately without using g729 encoders/decoders.
This would make it possible to on-demand transcode these audio streams to another format (On my system I need about 1ms/1s of audio to convert from g729->slin (which is close enough to the required format for .wav that we can safely ignore that overhead). Thus given that a call was 5 minutes I need ~600ms worth of CPU time to convert both channels to .wav, after which I can use soxmix to mix them into a single file (say another 100ms). After this I can either stream the raw .wav down the internet, or more likely, convert to .mp3 (CPU intensive, and probably not the best for voice, but very good for storage, and most people have mp3 players readily available). Considering the original (pre-g729 compression) was a 64kbps signal compressing to 64kbps should be just fine, and even down to 16kbps should still be audible.
Now for the kicker, due to the fact that calls tend to be distributed over a time period we can somewhat safely assume that 10 calls won’t end in the same instant, or at least, 10 calls should not end within the same second. So, Instead of using MixMonitor, we can use Monitor to record the raw .g729 streams, and then write a script to do the rest of the conversion, and just set MONITOR_EXEC to point to this script before invoking Monitor().
This way we should be able to reach (and record) at considerably higher call-concurrencies than what we would be able to with MixMonitor. If the conversion process further more executes at high nice levels and even queues itself should insufficient number of decoders be available for g729 -> wav conversion we should even be able to do this without the rest of asterisk being impacted on (ie, without loss of quality for ongoing calls).
Tags: call recording, g729, mixmonitor, monitor, VoIP