ARI and Missing Recordings

[Talkincat]

We moved from Trixbox with Asterisk 1.2 to PBX in a Flash with Asterisk 1.4 a couple of months ago. I can't express how much better happier I am with this system. So, first, thanks for that!

That being said there is still one outstanding issue that I'd like to get worked out. The ARI interface is pretty usable, particularly once you figure out how to search by date. For the most part it's meeting our needs, but there are times when it is unable to find call recordings. This seems to be most prevalent with inbound queues. The inbound route for out main DID directs to a queue that rings a group of static agents. So, anyone that calls our main number and doesn't dial an extension or go to the directory ends up in this queue (3334).

I don't have queue recording enabled because all of our extensions are set to always record. This is a requirement from the company owner, and while that does create its own issues, there's no changing that policy at this point. I have tried enabling queue recording in addition to the extension recording, but this seems to have no effect on ARI's ability to find the recordings. Some of the recordings are found in ARI, some are not. This issue seem to happen most often when the inbound call is answered and then transferred.

I am attaching a couple of screenshots showing what I mean. First I searched for the queue number and the calls are shown, but not the recordings. Then I searched for the phone number from one of the calls and the result is the same. I know that this recording exists because I fished through the monitor folder and listened to it.

Ultimately, I would like to get a better handle on where these calls are ending up and being able to find the recordings. Is there a way to make ARI do this for me? Is there another tool I can look into that will help. Trixbox had a CDR feature that didn't necessarily work all that well, but did at least give me some more information and the ability to find the recordings.

As a side note, I have actually found a tool that might help with this:

http://www.tikalnetworks.com/voip/index.php?cid=38

I was unable to get it to install and run on my test system. Is anyone familiar with this and how to get it installed?

Thanks very much for your help!

 

[thunderheart]

Yep, happens to me too

Cat,

This happens to me as well. Also on transferred calls. ANY transferred calls. And it isn't that they're lost. They are never created. I have "record all" set everywhere I can find a place to do it and still no joy. Obviously, I have no advice for you as far as a fix but please do pass on any solution you come up with as it is one of those few things about our PIAF box that annoys the crap out me.

Dallas

 

[Talkincat]

If we are having the same problem, I suspect if you check out /var/spool/asterisk/monitor, you will find that the recordings actually are being made, it's just that ARI isn't finding them for you. If the recordings aren't being made, I would expect there to be some indication as to why in the log file at /var/log/asterisk/full.

 

[Boolah]

I don't have queue recording enabled because all of our extensions are set to always record.

I would imagine that this would generate quite a few recordings. Have you tried recompiling asterisk-addons with the:

ASTCFLAGS+=-DMYSQL_LOGUNIQUEID

option? If there are more than 3,000 recordings in the /var/spool/asterisk/monitor directory, ARI has a hard time keeping track of stuff without the above option. Unfortunately, the affect is not retroactive, so it will only apply to recordings made after you recompile.

 

[Talkincat]

Boolah,

No, I haven't done that. The idea of creating a uniqueid is interesting, but would ARI know to search the asteriskcdrdb table for it? Also, looking through the Master.csv file, my records appear to have something that looks like a unique identified that looks like this "1254396866.32923" does the setting you're talking about do something different?

Finally, ARI is, for the most part, working correctly, it's just the queues and calls that have been transferred that seem problematic.

 

[Boolah]

Sorry - I forgot to mention one other step which you should take. After you recompile asterisk-addons with the above flag, edit /var/www/html/recordings/includes/main.conf Search for the line:

$CALLMONITOR_ONLY_EXACT_MATCHING = 0;

and change the 0 to a 1. This is the setting which tells ARI to search the DB for the UNIQUEID.

 

[Talkincat]

Hmmm, you've gone and given me hope, now. That's dangerous . I will give this a shot on my testbed and see if I can get this worked out.

Thanks for the pointers!

 

[Talkincat]

Success!

Recompiling the add-ons in the way that you suggested seems to have helped quite a bit. ARI is now finding pretty much every recording that I would expect it to.

Thanks very much for your help!!!

One final question I have has to do with refining the search. I know that I can search by date by adding yyyy-mm-dd to my search. Is there a way to search a date range? Are there any other modifiers that I can use to further refine the results?

 

[Boolah]

Glad it worked out.

I don't think you can use any logic in the ARI search field. Everything you put in there is AND'ed, so selecting a range would be difficult

 

[Talkincat]

It seems I spoke to soon about this. Apparently we just didn't have any inbound calls that were transferred over the weekend. The above change doesn't seem to have made any impact on the ability of ARI to find a recording of a call that is transferred to another extension (which is most of them, it turns out).

I'm on the cusp of giving up on this and finding the recordings by hand when I need to. I am a little frustrated because this is pretty much the only thing left that I miss from our Trixbox days.

If anybody has any other ideas, I'm willing to try.

Thanks!

 

[Talkincat]

I'm going to bump this up once more, just in case anybody has any other ideas. What appears to be happening is that there are three steps to a call A -> B -> C. So, 123-456-7890 calls and ends up at extension 30 who transfers the call to extension 40. If I look for the record relating to the first half of the transaction (123-456-7890 -> ext30), I get no recording. If I look for the record relating to the second part (ext30 -> ext40) I will find the recording. This seems like a fundamental shortcoming of the CDR setup, but if it's possible to fix this, I'd like to.

 

[Talkincat]

I was never able to correct this issue; as I said before I believe this is a shortcoming of the CDR setup. I was able to come up with a work-around, however.

What was happening as that 10 would call 20 who would then transfer to 30. When I searched using ARI, I wouldn't find the call when searching for "10" because it was associated with the call between 20 and 30. By setting our Polycoms to use blind transfer instead of attended transfer, the second leg of the call appears in the CDR as a call from 10 to 30, so ARI is able to find it.

It's not a perfect solution, and it means a small pain for my users, but being able to find the call records is more important.

For anyone that tries to do this using Polycom endpoints, you have to create a second "transfer" button using enhanced feature keys that does a blind transfer automatically. Well, that or you have to rely upon your users to hit the "blind" button each time (which I won't rely upon my users to do). If anyone needs help with the EFK setup or would like to see my code, please let me know.

Thanks for everyone's help on this!!