The Post Call Recording Script will not accept a quote character

Hello All,

We are currently attempting to use the post call recording script found in Advanced Settings to run a script that renames the recording file for use with callcabinet.

That said, I need to put quotes around a couple of the parameters for times when the parameter is not set. However placing the following in the post call recording script under Advanced Settings translates the quotes to their ASCII equivalent (") in the extensions_additional.conf…

Post Call Entry via Advanced Settings: ^{MIXMONITOR_FILENAME} "^{AMPUSER}" ^{CALLERID(number)}

.conf results in:


I need the actual quotes so that when {AMPUSER} is not set, it’s placeholder as a parameter is retained.

Current Asterisk Version: 13.22.0
**FreePBX 14.0.11

Try escaping the quote with a preceeding backslash

Tried that. it simply adds the backslash before the ASCII. ^{MIXMONITOR_FILENAME} "^{AMPUSER}" ^{CALLERID(number)}

Any other thoughts? Could this just be a bug?

Well it didn’t show up in the example, but there’s an actual \ before the "

hahaha… this page is converting the ASCII code. which leads me to think… is Freepbx not interpreting the HTML correctly when converting to text in the .conf file?

I think you mighr find that the script is maybe called by /bin/sh (defined in /etc/passwd for the asterisk user), you might want to force bash with an initial


Test with

echo $SHELL

not sure that’s the issue. the script seems to be functioning well… in the log files we see:

app_mixmonitor.c: Executing [/home/callcabinet/ /var/spool/asterisk/monitor/2019/05/18/in-2255324130-2252058967-20190518-132535-1558203935.0.wav &#34]

Freepbx is truncating the command and failing when it encounters the ASCII code. So, in otherwords, the script never receives the proper parameters

When replacing with a constant that doesn’t require a quote, the script runs perfectly.

FYI: bash is specified as first line in the script as you’ve noted.

But FreePBX isn’t running the script, the asterisk user is.

Test with

su asterisk

As root then debug the script with it’s calling parameters directly

Right. however the script is not receiving the proper parameters. Freepbx seems to be truncating the call at the point of the ASCII interpretation.

app_mixmonitor.c: Executing [/home/callcabinet/ /var/spool/asterisk/monitor/2019/05/18/in-2255324130-2252058967-20190518-132535-1558203935.0.wav &#34]

NOTE above, the call to the script is incorrect… it should contain 3 parameters

Aginn, FreePBX is not in way involved. Make sure the script itself is well formed with the editor of your choice

Dicko… first, thank you for your replies… it is much appreciated as I need someone to bounce this off of. been pulling my hair out this weekend. hahaha…

So, the script is fine. 100% sure of that. When you say freepbx is not involved, why do you think that? because I disagree… while the script itself is not the responsibility of Freepbx, the calling of the script via the entry in to the Post Call Recording field is 100% Freepbx right?

And we can see from the log file and from the interpretation in the extensions_additional.conf file that a quote symbol is not supported for some reason. it converts it to ASCII.

Am I making sense?

You pass the parameters as a list of space separated strings, the ^{} format is convenient but restricted as to what can be parameterized but perhaps you need to handle re-quotong needed quote characters inside the script( which need not be bash if you have another preference.)

Have you tried quoting the var in ''? You need to fix how you’re calling the script. Special characters need to be quoted so you need'\"^{AMPUSER}\"' . Give that a try.

The core issue with not being able to pass quoted values to a script (and this isn’t just with this call), is when a parameter is omitted (in this case when {AMPUSER} is blank the enumeration of parameters is skewed. So for example calling a script expecting 2 parameters should be able to handle: “” 1234 OR “ABC” 1234 so the enumeration of the parameters is correct. If a script is expecting 2 parameters and gets called with 1234, clearly this will only show up to the script as 1 parameter and thus the values set within the script are skewed…

Yea, gonna need a workaround for this which sucks… Hey, do you know if placing the call to the MIXMONITOR would in the globals_custom.conf would allow me to directly enter a quote as opposed to having the Freepbx interpret the string placed in the Post Call Script?

If the parameter is blank wrap it with _ for example and strip them inside the script

Thanks Blaze… Attempted suggestion which resulted in the following…

MIXMON_POST = /home/callcabinet/ ^{MIXMONITOR_FILENAME} '"^{AMPUSER}"' ^{CALLERID(number)}

Really leaning towards this being a bug in that Freepbx is not interpreting the HTML to Text correctly when going from teh Post Calling Recording field in the interface to the Text entry into extensions_additiona.conf.

Dicko… gotcha… screw the quotes right :slight_smile: extra work but certainly would work…

do you know if placing the string in the globals_custom.conf would allow me to directly enter a quote as opposed to having the Freepbx interpret the string into the extension_additional.conf?

Never trilied it, but please do so and I would like to know your results.

UPDATE… Hope this helps others and hope the developers of Freepbx run into this in case it’s a bug not a “feature”.

So, it is confirmed that the Post Call Recording Script field in the Advanced Settings does not interpret single or double quotes properly, instead, it inserts the ASCII code into the extensions_additional.conf therefore leaving it useless as any call truncates the call at the ASCII code.

The solution: Remove the entry from the post call recording field and set the MIXMON_POST variable manually in the globals_custom.conf file.

In my case, we are attempting to integrate with callcabinet for call recording analysis and reporting so our specific entry is:

MIXMON_POST = /home/callcabinet/ ^{MIXMONITOR_FILENAME} “^{AMPUSER}” ^{CALLERID(number)} ^{CDR(dst)} ^{CDR(start)} ^{CDR(src)} ^{UNIQUEID} “^{AGENTEXTEN}”

This resulted in a successful call even when some variables were empty as indicated in the logfile:

app_mixmonitor.c: Executing [/home/callcabinet/ /var/spool/asterisk/monitor/2019/05/19/in-2255324130-2252058967-20190519-090135-1558274495.9.wav “” 2252058967 recordcheck 2019-05-19 09:01:35 2252058967 1558274495.9 “”]


1 Like

I think you will find that those two are not in the list of usable ^{} variables.

So ^{CDR(ACCOUNTCODE)} yes but you will have to look up the others in the sqlite3 asteriskdb database.

Calling dumpchan() before the call also informative.

OK… Back at it for a bit… There doesn’t appear to be a Asterisk/Freepbx variable that holds the extension of the answering extension. Please correct me if I’m wrong here because I would LOVE to avoid a database call for something this simple…

therefore, after studying the CDR/CEL structure for a bit it appears I can pull the answering number from the CDR from the dst field using the UniqueID and disposition “ANSWERED”. something like this…

EXTANSWER=$(mysql -u $user -p$pw asteriskcdrdb -s -N -e “select dst from asteriskcdrdb.cdr where linkedid=${8} AND disposition=‘ANSWERED’ AND lastapp=“Dial” LIMIT 1;”)


Where ${8} is the uniqueid passed in from the post call recording…

Putting this in my script instead of relying on {AMPUSER} and {AGENTEXTEN} variables (which do not work, thank you Dicko) seems to catch what I need for structuring the file for callcabinet. I have done very little testing thus far but would like any feedback if anyone has any suggestions for improvements or issues with performance running such a query on each call.

BTW: has anyone integrated FreePBX with callcabinet ?? If so, I’d love your feedback…

{EXTEN} would be the called number but the eventual bridged channel would depend on unknown factors. Getting information from the other channel is briefly mentioned here depending on when the script is called. {DIALEDPEERNAME} might be more useful also depending

So {BRIDGEPEER} might or might not be what you are looking for. But you might need to save it while the channel is bridged