Call Recordings append 'in' and 'out' rather than mix them

Comments

• nicolas

  July 2012

  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,
• OZPHB

  July 2012

  HI Nicholas,
  I am sorry I have taken such a long time to reply. I have been looking into this, and running some tests.
  
  I have read, very carefully, the post you linked to me about the sox version.
  
  I note that upgrading the sox version did not fix the issues being experienced. I have tried this 'fix' which worked for some of the users on the post, but did NOT fix my issue:
  

  Try putting the following line in /etc/asterisk/globals_custom.conf:
  MONITOR_EXEC=soxmix

  
  When I did this, the only effect was that the FOP2 recordings stayed separate (ie, two recordings, one 'in' and one 'out') when without that line in the globals_custom.conf the two files are appended into one file.
  
  Dialling *1 in call works perfectly for me - whether the asterisk system is the callee, or the caller.
  
  It seems to me that, actually, the problem really is with FOP2 .
  
  The command that FOP2 issues to make the recording must be different to the command issued when I dial *1 in call.
  
  When the 'record' option is used in FOP2, the recording is placed directly into /var/spool/asterisk/monitor, while when done via *1, the recording is placed in /var/spool/asterisk/monitor/year/month/day
  
  Also, the FOP2 phonebook "Recordings" tab shows "No records found" even though it just made a recording.
  
  I have had a look and FreePBX is using the following line in /etc/asterisk/features_applicationmap_additonal.conf
  

  apprecord=>*1,caller,Macro,one-touch-record

  
  I am not sure where to look to find the macro itself..
  
  It seems this macro works fine, but the fop2 one doesn't? Is it the case that the fop2 command is issued expecting a different sox version than exists on my system, while the freepbx ver is using a command compatible with my sox ver? I have sox ver 12.18.1, which I see is quite old, yet seems to be the latest version available in the centos repository my system is using.
  
  Any suggestions where to go from here?
  
  Thanks in advance.
• nicolas

  July 2012

  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,
• OZPHB

  July 2012

  Thanks for your further input - I have it working now!
  
  This from your last post was the key:

  You can look at the recordings_fop2.pl script

  
  I checked this file, and the comments at the top, and found that my permissions on this file were set to 'root' and not the 'asterisk' account I am using for asterisk.
  It also pointed me to the fop2.cfg file, where I found this:

  ; To enable the recording interface you must uncomment the following
  ; line, but also you might need to modify the script a little bit 
  ; depending on the sox version you have installed.
  ;
  ;monitor_exec=/usr/local/fop2/recording_fop2.pl
  

  
  So, I uncommented the line

  monitor_exec=/usr/local/fop2/recording_fop2.pl
  

  
  Then, recordings started to work, mixed beautifully. The final recording is in stereo - with the playback playing my caller sound on the left channel, and my callee on the right channel, just like a conversation. Wonderful!
  
  It is now saving the completed recording using path /var/spool/asterisk/monitor/fop2/[date] rather than just leaving it in the top level /var/spool/asterisk/monitor/
  
  I can now 'see' the recording in my phonebook.
  
  I didn't even have to restart fop2.
  
  All working, 100% A OK
  
  Now, just a couple of other matters, for anyone else finding this topic:
  My issue *was*with FOP2, in that I did not have FOP2 config set up correctly.
  I did not know I had to uncomment lines in a config file to enable recording.
  
  I think the 'not putting the recorded file into a subdirectory using date' and 'recording not visible in phonebook' were, in hindsight, the key indicators of [my] user config error.
  
  A couple more things, more for completeness, and because I tried a lot of stuff so may as well note it down:
  
  Also in the fop2.cfg file is this section

  ; You could specify your own script to be executed when the recording
  ; is finished. It will receive 3 parameters, the complete
  ; path and filename of the IN leg, the OUT leg and the final
  ; recording NAME. You should run soxmix in your script to join
  ; the recordings into one file.
  ;
  ; monitor_exec=/var/lib/asterisk/bin/postrecording-script.sh

  I did not have to uncomment the postrecording-script.sh line, nor specify my own script to be executed when recording. This was to be my next step, but it was not required.
  
  Also:
  I do not have a file called 'res_monitor.c' on my system.
  
  I tried mixing the in and out channels of a test recording using both of these suggestions:

  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

  
  One concatenated the file, the other threw an error, and created a file with only the 'in' channel. So, this did not work.
  
  I was very reluctant to change my sox version as, as pointed out by Nicolas, asterisk 'expects' a certain version and my *1 recording method was working and I didn't want to break it. Part of my research suggested to me that asterisk is now using its own recording method, not using sox at all, but I didn't really get to the bottom of that.
  
  Thanks again Nicolas for an excellent program. My users are all hugely resistent to any form of technology, particularly remembering and dialling codes into the phone, so your big colourful buttons and point-and-click panel is very popular. My questions and queries are not a complaint, they are the product of a genuine desire to get the best out of a very good system.
• nicolas

  July 2012

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

  July 2012

  Ok, thanks Nicolas.
  
  I will keep looking, and post back if/when I locate/resolve the underlying problem!