New install of Freepbx 12.0.37 on Centos 6.5. I have enabled call recording. In the full log, I see that call recording is failing with:
[2015-02-14 14:23:18] VERBOSE[854][C-00000000] app_mixmonitor.c: Begin MixMonitor Recording PJSIP/2818325-00000000
[2015-02-14 14:23:18] WARNING[854][C-00000000] file.c: No such format ‘’
[2015-02-14 14:23:18] ERROR[854][C-00000000] app_mixmonitor.c: Cannot open /var/spool/asterisk/monitor/2015/02/14/out-12514316762-2818325-20150214-142318-1423923798.0.
If you go into extensions_additional.conf and modify 647:
That ‘uniqueid’ is made up of a timestamp (142…) and a unique call ID after the dot. That is zero on your system. That’s wrong. I’m almost certain that it should be a positive number. That uniqueid is generated by Asterisk, per call, and won’t change.
So, that’s wrong. (Edit: No, it’s POSSIBLE. It’s unlikely, and will only happen in the first call after Asterisk is started. If that was the first call you attempted after restarting asterisk, then that’s correct)
Secondly, I can’t see how MON_FMT -can’t- be set. It’s a core setting. However, it’s possible that somehow that setting isn’t even THERE on your machine. Can you check that it’s there in Advanced Settings?
(actually Rob, just to clarify,the number after the . are a 0 based count of the calls after starting asterisk, the number before, the the seconds since the “epoch”, so on any system they will be unique per call but there might be more than one spawned record per channel from that original call with that particular uniqueid, you can guarantee them unique systemwide if you have more than one asterisk system reporting to that database by setting for example
Further, the global variable has always been MIXMON_FORMAT not MON_FMT or even MIXMON_FMT as affirmed by the hover over help. the last definition of MON_FMT and or MIXMON_FORMAT in the /etc/asterisk/extensions* tree [global]s will win if it is so defined, maybe that has changed . . .
edit
I note one use/redefinition of a global __MON_FMT to correctly re-identify wav49 as WAV files otherwise it appears to be undefined, a bug maybe yet?