Displaying Recorded Calls

I guess it should be added that they are not showing up in the user portal either.

Thanks to Alex at thirdlane, we have discovered that the WAV files being created are differing.

The one file that is displaying is named "inout-2014-2008-10-16-11:54:41-2007.wav"

The rest that aren't are all being named as "auto-1224174881-inout-2007-2008-10-16-12:34:18-2013-in.wav"

Strange because they were all recorded the exact same way (#9) and no auto-recording was set

Hi Mathews,

I've the same problem my file are called :

auto-1224583933-out-41-2008-10-21-12:12:04-69-in.wav

auto-1224584052-out-41-2008-10-21-12:14:01-69-in.wav

auto-1224583933-out-41-2008-10-21-12:12:04-69-out.wav

auto-1224584052-out-41-2008-10-21-12:14:01-69-out.wav

At the end of the recording (with #9, not autorecording) I've got a notice message on the CLI :

Oct 21 12:14:25 NOTICE[11315]: res_monitor.c:316 ast_monitor_stop: monitor executing ( nice -n 19 soxmix "/var/spool/asterisk/monitor/auto-1224584052-out-41-2008-10-21-12:14:01-69-in.wav" "/var/spool/asterisk/monitor/auto-1224584052-out-41-2008-10-21-12:14:01-69-out.wav" "/var/spool/asterisk/monitor/auto-1224584052-out-41-2008-10-21-12:14:01-69.wav" && rm -f "/var/spool/asterisk/monitor/auto-1224584052-out-41-2008-10-21-12:14:01-69-"* ) &

I Use Debian 4.0, the last version of Thirdlane (6.0.1.63) and Asterisk 1.2.30. Do you have any update form Alex or form Thirdlane about this ??

no updates to speak of, other than from Alex:

"Normally we set the file name in the dialplan but I have a suspicion that the calls with “auto” somehow are directed to the extension with the dialplan “bypassed” – possibly from the queues. Do you know whether this may be the case?"

I have just informed Alex that the dialplan is not being bypassed and has not changed.

hey duc,

what i have found by listening to the split wav files is that the files ending in -out.wav are the outbound audio from the recording extension. and the files ending with -in.wav contain the inbound audio to the recording extension.

weird.

we foound this mailing list post which is relevant since we are using features.conf and are at the mercy of asterisk naming the file:

http://www.mail-archive.com/asterisk-users@lists.digium.com/msg199010.h…

"The default automon (touch monitor) output file name format is:

auto-epoch-caller-callee.wav

A variable is available to modify the second half:

auto-epoch-${TOUCH_MONITOR}.wav

But, I can't modify the first half, 'auto-epoch-', with any variables

that I know of, including ${MONITOR_FILENAME}. I want to immediately

convert this output file to mp3, e.g. with ${MONITOR_EXEC_ARGS}, but I

can't because it's impossible to predict a file name that includes an

epoch number."

from voip-info.org:

"The monitor runs on the "callee" channel, so channel variables which affect the end of the monitor process (such as MONITOR_EXEC, which controls how the in/out files are mixed) must be set on the "callee" channel using the M(macro) option of the Dial command."

I have installed sox and now i am getting files such as:

auto-1224707391-out-2064-2008-10-22-16:29:34-2013.wav

This file IS being displayed in the GUIs, however it has the callee's audio first, then the caller's audio second. it is appending the files instead of combining.

according to the yum.log, sox was never removed.

so they are now being "combined" and displaying, but the audio is not being mixed correctly...

when we set the extensions to "Record all calls" the recordings display and are mixed properly.

it is the #9 recording which has the issue.

We deleted sox and created a symlink from /usr/bin/sox to /usr/bin/soxmix because Asterisk wants to run sox -m and in the version that ships with centos 5.2, the -m flag to sox does not exist. We're guessing that -m makes sox behave like soxmix.