Hi,

It is not a fop2 problem, it is an asterisk problem. FOP2 does not record calls, Asterisk does.

The concatenation issue is due to a sox version different than the one asterisk expects. FOP2 starts a monitor manager command, that fires the monitor feature in asterisk (not mixmonitor), that records both legs separately When the call is done, asterisk runs "soxmix" to mix the sound files and merge them.

Some sox versions require a command line parameter (that was not needed in other versions) to actually mix the files instead of concatenating them. This might help you out:

http://www.freepbx.org/forum/freepbx/us ... bx-2-7-0-1

Regarding the tape icon, as far as I remember, there are no events being fired in AMI when you start on demand recording. FOP2 listens to AMI events, and as there are none, it cannot tell if the call is being recorded or not.

Best regards,

Hi,

FOP2 does not handle audio.

How could this be a problem with FOP2 if it does not know anything about a call leg, or a coded?

As I said before it is an ASTERISK problem, related to your SOX version. Asterisk expects an old sox version, not a new one. You have to downgrade sox if you want the two legs to be mixed.

Do not look for the problem where it is not, nor compare two things that are different. Asterisk has two ways of record calls, one way that records mixed audio, and another that records legs separately and then uses an extra program at call end to perform the mix.

FOP2 uses the Monitor application in asterisk AMI, that application records the legs who later are mixed via sox/soxmix. All of that is done *in asterisk*, exactly in res_monitor.c, this is the important snippet from that file:

#ifdef HAVE_SOXMIX
                                execute = "nice -n 19 soxmix";
#else
                                execute = "nice -n 19 sox -m";
#endif

As you see, it will attempt to run sox in two different ways, depending if you have the HAVE_SOXMIX flag enabled at compile time.

The problem is that I do not know if you HAVE_SOXMIX or not. I also don't know what soxmix version you have and what it expects as parameters to actually mix files.

So *you* will have to test yourself until you get the result you want.

Again, this is NOT a fop2 issue. To be fair, it is not an Asterisk issue either, but a SOX issue.

You will have to get some two original leg files, like xxxxx-in.wav and xxxxx-out.wav , and then try to combine them in the command line with either way you see on the above code, like:

nice -n 19 soxmix wwwww-in.wav xxxxxx-out.wav xxxxxx-combined.wav

or

nice -n 19 sox -m wwwww-in.wav xxxxxx-out.wav xxxxxx-combined.wav

Then listen to the combined file, it is mixed or concatenated? Work your way until one of the above commands mixes the files instead of concatenates them. (Work your way means change your sox version, or remove soxmix and create a soxmix shell script that calls sox with the appropiate parameters).

I cannot be more verbose emphatic that I already am. I am pretty sure of what I am saying. FOP2 does not have any problem at all as it does not even know how to handle audio, it is not its job. It justs ask asterisk to start or stop monitoring, nothing else.

You can look at the recordings_fop2.pl script that you can use as a monitor_exec parameter, that script tries to determine your sox version in order to run the appropiate sox command, but it *tries*, as sox is not very command line friendly in the sense that it does not advertise its version in a clean manner, and in the sense that with every version command line parameters tend to *change* meaning, where previously "m" meant "mix", other versions could change that to anything else..

Best regards,

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.