Thanks for your feedback and detailed post. I know your messages are not complains! Your posts add up to the discussion and might help fellow users with the same problem. I really appreciate it. Your posts are detailed and to the point, not just a "it does not work" at first, and maybe a finally "it works, thx" at the end with no explanation at all that might help other users.
Anyways, I would like to say again that the problem you had is not a FOP2 problem or bug. It is important for me that this gets cleared up. Believe me, I *know* what I am saying. It might seem a semantic issue but it is important. Many users could be misguided or make bad assumptions based on just one word or phrase.
The fact that you experience the problem by *USING* FOP2 doesn't mean that FOP2 has a problem. This happened countless times, not only with recordings but many other aspects/situations.
Asterisk is a complex system, it does *lots* of things, it includes *lots* of modules/functions and applications, available from within Asterisk itself. Unfortunately all the magic it does is made in a non apparent way: being a server that handles media, audio mixing and codification, interfacing with voip and pstn hardware, etc. It is something you cannot *see*. It works "under the hood". It is the engine, while your users are sitting on the passenger seat. And you as the driver, you are behind the wheel, but you still do not see the actual engine working, you learn your ways on how to drive and that is enough to get you from point A to point B.
When you use FOP2, you are making things visual an apparent. Things that were there but you did not notice before become visible. You start seeing graphically what happened before and you did not notice. Some examples: short lived local proxy channels, stuck/locked/zombie channels/calls, member name option in queue members, etc.
As a user, or even as a sysadmin, you do not actually need to know about all that stuff, but if you notice something strange in FOP2 that you did not notice before, it is probably not because of FOP2 that the strangeness happened, but instead you noticing that strangeness *thanks* to FOP2. FOP2 is not usually the cause, it is just the medium to notice the symptoms.
In your particular case with recordings, you did not experience the problem before because you were NOT using the Monitor application in Asterisk. You were using MixMonitor. You maybe did not even know about that, it does not matter, but it is a different application. Both are NATVIVE asterisk applications, I mean that is not a FOP2 function. It *IS* Asteirsk, it always was Asterisk.
The res_monitor.c snipped I pasted is part of the Asterisk source. It is not part of FOP2. It was just there to show you that is ASTERISK who calls sox or soxmix. Not FOP2. Asterisk invokes an external application to do the mixing of the Monitor application (that is also an ASTERISK application), not a FOP2 application. And if you see the code, your install might use two different command to mix audio, both related to Sox.
And I say again, SOX has different versions, and from version to version they made command line parameters incompatible, they change meaning. Also, some versions do not include "soxmix" as a binary at all (one of the calls that asterisk might perform when doing the mixing).
The fact that you noticed the problem when starting a recording inside FOP2 just showed you a problem that it was always there, even if FOP2 were not installed or used. *Your* asterisk is calling sox or soxmix in a way that makes sox concatenate files instead of Mixing.
IT IS ASTERISK THAT CALLS SOX , SOXMIX, AND IT IS SOX/SOXMIX THAT MIX OR CONCATENATES THE FILES.
Now that we have that cleared up, your solution was to use a script I wrote to try to solve the problem with Asterisk and Sox versions. That script is part of FOP2, but it is not enabled by default. The monitor application has an option to pass an external script to do the mixing or whatever instead of the internal call to sox/soxmix that asterisk does by default by means of res_monitor. The script included in fop2 is not enabled because it is up to the sysadmin know what they have installed in their machines, what asterisk version and what sox versions. The script as it is might fail. However, I put significant effort on the script to try to detect the sox version installed, or if you had soxmix, and try to invoke sox in the correct way depending on the version installed. The problem with that script is that perhaps, in the future, sox developers will change its software *again* and break backward command line compatibility *again*, so the script might fail on detecting the correct version or passing the correct arguments to sox. I am not a mentalist, or futurologist.
So I wrote those comments, saying that the script tries to guess what you have and does its best to try to run the correct command, but it is not bullet/future proof. And as it is a script, you can easily tweak it if needed. It is meant to be modified by fellow sysadmins.
When you set monitor_exec in fop2.cfg, you are just telling the monitor application in asterisk to run that script instead of the native sox / soxmix, but if you look at the script, the script still RUNS SOX / SOXMIX!! But it does it in a way that can guess your version to pass the correct commands, something that a compiled asterisk does not do, because the command to run is defined at compile time, and for what I see, you are NOT COMPILING asterisk from source, but using a compiled/binary version.
So, guess what, your Compiled Asterisk Version does not match your Sox Installed version. So, the real problem you have is responsibility of the distribution packager, that lets you install a version of SOX that is not the version Asterisk was compiled for. I am not blaming the packager, as that is a really complex job too, figuring out dependencies among software packages. Perhaps, if you installed Asterisk from RPM, and you have sox instaleld also from RPM, then the packager should figure out what sox.rpm is compatible with the asterisk rpm and change the .spec file to add that dependency. In any case, this is totally out of the scope of FOP2.
The perl script that you are using now that is part of fop2, will mix the files and also insert a db record and move the file to some place. The later two actions are specific to the fop2 recording interface. So this will fix your problem for the fop2 interface.
But whenever you use another application, or you write your custom dialplan that invoked the MONITOR application outside of fop2, you will have the issue again.
The solution you found is the one included in FOP2, for FOP2. But it does not fix your real issue. You are still having a problem with Asterisk and SOX.
To fix your real issue, you will have to install the sox version your compiled Asterisk expects, or create a replacement sox/soxmix script to intercept the asterisk call and then pass the correct command line parameters/commands to the real sox.
Excuse me for this long rant. But let me say again. You did not have a problem with FOP2. You had (and still have) a problem with Asterisk/Sox. FOP2 just made that problem apparent. And the solution you found by using the included fop2 scripts for mixing, will *only* work for FOP2. But you are still having a problem that might bite you in the future.