RESOLVED: No call recording - no such format ''

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:

exten => recordcheck,n,MixMonitor(${MIXMON_DIR}${YEAR}/${MONTH}/${DAY}/${CALLFILENAME}.${MON_FMT},ai(LOCAL_MIXMON_ID),${MIXMON_POST})

and hard code and extension like wav where ${MON_FMT} is, it works.

Of course, any change to the system overwrites this file.

Is there a permanent fix for this?

The ‘MIXMON_FMT’ value is set in Advanced Settings. It should be defaulting to ‘wav’ - do you want to check that it’s actually set to something there?

Actually, looking a bit harder, there seems to be a couple of problems.

Firstly, from the wiki:
CALLFILENAME (which, in the example above) is made up of this:


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

systemname = pbx0

in /etc/asterisk/asterisk.conf [options] section

which will prepend pbx0 to all uniqueids )

1 Like

Good point, it IS possible for it to be a zero.

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 . . .


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?

Yes it is set in the GUI to ‘wav’.

in the interim try selecting WAV there, that will possibly fix things unless you are an apple fan :wink:

It was alread WAV, i tried to move it to wav, same results

Then I think you need to wait for an official fix/solution.

Elsewhere noted:-

perhaps adding

MON_FMT = wav

to /etc/asterisk/extensions_custom.conf might also satisfy the beast until then :wink:

Can you please update to callrecording v12.0.2.4 and let me know of any other issues.

I’m on 12.0.5 right now…are you asking to roll back?

Edit - nevermind, I looked at the wrong module. I will update and report back.

Looks like this update resolves the issue. Thanks!