Call Monitor Records being recorded but not able to display in User Panel

I have a 2.10 Distro install that i have upgraded to 2.11 via the modules upgrade script, and am up to date on all available modules. Since doing so, recorded calls will not display when logging in as admin under the user panel. The calls are being recorded and are stored in the /var/spool/asterisk/monitor directory…but will not display either as admin or when logging in as an individual extension. I don’t see any glaring errors in the asterisk start up log that relate to this issue.

I would appreciate any assistance in finding a resolve on this issue.

I have the same issue FreePBX 2.10.1.9 so I do not think it is relevant to 2.11 I think it is just broken. I have seen this before in older versions and it is related to unique id’s in mysql and time/date stamps. http://www.freepbx.org/forum/freepbx/users/recordings-not-showing-in-ari

A bit annoying but this has been going on since before Asterisk 1.4 and even if you fix it; rest assured it will return if you use DST.

Perhaps one day a dev will grasp this and make it work right.
I have 4 systems that were working and now are no more working after DST changes.

We have already “grasped” this. We are in discussions about re-writing the ARI completely. So individual fixes are postponed at this time. Please note that the ARI is probably some of the oldest code in FreePBX (not that it matters…)

That is some of the best news I have heard in a while.
I wont ask for an ETA; I know better. Just good to know it is going to change.

Thanks!

I have the same, or similar, problem here. It was working, a few months ago - perhaps with 2.9. But I’ve upgraded to core 2.10.1.2, and now the call monitor/voicemail user interface does not show any link to a recording. Probing around, I’ve discovered that a .wav recording is being stored in /var/spool/asterisk/monitor/2013/09/24, and that a CDR record is being written to the MySQL asteriskcdrdb.cdr table. However, the recordingfile column is blank, even though uniqueid is written correctly, suggesting CDR is working correctly otherwise.

It’s been many years since I manually hacked an Asterisk dialplan, so I can barely remember how they work, but I reckon the issue could be in extensions_additional.conf, [sub-record-check]. I can see the line

Set(CDR(recordingfile) = ${CALLFILENAME}.{MON_FMT})

near the top, and a few lines later I can see __CALLFILENAME being set with the various components of the filename, but I can’t see where CALLFILENAME is being set.

I’m in a bind - I don’t have the time to hit the books and re-learn Asterisk, let alone debug this monstrous dialplan, but my user is a market researcher who needs to record telephone interviews. Any suggestions would be gratefully received!

The best fix is to purchase the call recording reports. It’s available in our application store. It’s a commercial module and very simple to use.

So, you’re saying I should upgrade Asterisk from 1.6 to 1.8 (which probably means upgrading the underlying OS as well), then upgrade to FreePBX 2.11, then spend $125 to buy something I don’t need, just so that something that should work, actually does work?

Sorry, but that’s not a fix - that’s just rude.

I am not sure what is rude about it. A free solution is in the works, you certainly can wait for that but you indicated that you had immediate commercial concerns so I offered you a solution that I know works.

This is the first time someone told me that suggesting one of the paid apps was rude. Since this is a major funding engine for the project I truly want to understand what you find offensive.

The ARI has been a mess for a long time. The cost to rewrite it is going to be over 100k. Development resources are critical and I think Schmooze does a good job of managing priorities.

I look forward to your feedback.

One other thing on the technical side. There is actually even more involved because commercial modules on run on our Distro and PBX in a flash unless you build the Zend dependencies required by the commercial modules.

I spent several hours working on this problem this morning; I knew it had been working previously - confirmed by the existence of previous recordings in the tree under /var/spool/asterisk/monitor - but started to dig when my wife reported that it had not recorded a telephone interview she had done this morning. So, I Googled, I read, I delved into lots of configuration files - I even almost pulled my tattered copy of “Asterisk - The Future of Telephony” off the shelf. It was clear from my Googling that lots of other people have been having trouble, but nobody seemed to have a solution.

So, in the same way as I have done with other open source projects - am I naive in supposing that FreePBX is an open-source project? - I dug up what information I could in the time available to me. If I had managed to come up with a fix, I would have happily shared that, but I presented what I had, in hopes that someone else might either confirm what I had found, use it to make progress with their own efforts, or just suggest that I might be on the right - or wrong - track. I’ve done that successfully many times, over the years, and I’ve always thought that it was how open source projects were supposed to work.

So, I added my contribution in a Community forum, in a thread that seemed most relevant and most likely to be found by others grappling with this or related issues. Rather than encouragement or thanks, or even a suggestion that I might be barking up the wrong tree, I appear to have been given this ultimatum:

  • Pay us $125 and rebuild your installation, or
  • Sit down, shut up and wait

Given that 2.9 worked, that the Changelog for the Call Recording module indicates changes for one-touch recording, and that the recording file information is not being written to the database in the first place, I have very little confidence that the “Call Recording Reports” module is going to be able to pull information out of the database that isn’t there. I don’t need reports for the few recordings we make - I just need call recording to work the way that it is supposed to. But if your module does work correctly, then you obviously have a fix that you are withholding from the community.

In the end, I will fix it. I will use a manual workaround for the next recording; I will jury-rig a bit of bash scripting or some PHP code to partially automate it after that; and eventually, I may well get it properly fixed. And if and when I do, I will make the bug fix available rather than withholding it, and I won’t charge people $125 for something that they don’t need.

Ok, first let me start off. You don’t need to write any script. You do realize that the call recordings are available in the CDR?

I just tested on a current 2.11 to be sure.

I went back and looked to see what you posted that you thought was helpful. Your assumption about the call recording table was wrong and we are using different data constructs that the Asterisk command you reference.

I can assure you the commercial module works fine, as does the CDR.

The decision was made by the programmers at Schmooze (who contribute 99.999% of the code to the project) not to expend any more effort on current ARI.

Certainly the project is open source. If someone fixes the code in the ARI and submits a patch it will be reviewed for inclusion. Programmers don’t read the forum regularly so realize you are talking to folks that don’t code.

I thought that the commercial module was a viable option given the parameters you outlined. It seems now that the provided facility in the CDR will suit your purpose.

Let us know if that works for you.

If you read my first post, you’ll see that we’re currently on 2.10, in which the recordings are not available in the CDR reports; an upgrade to 2.11 will have to wait until I can schedule a Sunday morning to level and reinstall our Asterisk server. With regards to what is in the database, I think I’ve managed to master the complexities of a single-table SELECT, thanks. As to the rest of this, we shall simply have to agree to disagree; functionality that worked in 2.9 does not work in 2.10, and while you obviously see this as a sales opportunity, I see it as a bug - which is, of course, what it is.