Skip to main content

Not able to record calls that come inbound through a queue?

Posted by BobRafferty on Fri, 04/03/2009

Has anyone got an idea as to why I may not be able to record incoming calls if they go through a queue?

I am using the following...

Single Tenant Edition
PBX Manager 6.0.1.69

Thanks in advance for your help.

Bob Rafferty


Submitted by BobRafferty on Tue, 04/07/2009 Permalink

Sorry Erik.

They are as follows...Under the "Current Members"

SIP/2201 - Bristol CheckIn <2201>

SIP/2202 - Bristol CheckOut <2202>

SIP/2301 - Bristol MA <2301>

SIP/2302 - Bristol MA <2302>

SIP/2330 - Bristol Triage <2330>

Thanks for all your help.

Bob Rafferty

Submitted by eeman on Tue, 04/07/2009 Permalink

you cannot record calls individually in this manner because the handsets are getting called directly by their channel names bypassing dialplan. this is a much cleaner method of delivering calls from a queue and allows for using ringinuse= settings etc. However, your recordings will have to be done in queues.conf not as individual extensions. You need to enable recording and sepcify recording format under the queues section of PBX manager and retrieve the files as admin under 'recorded calls'.

Submitted by BobRafferty on Wed, 04/08/2009 Permalink

Erik... Thanks for your help. I finally figured it out... It was recording all along. The recordings just were not showing up in the Thirdlane GUI anywhere... I finally found them on the HD in the /var/spool/asterisk/monitor folder.

One last question... Is there a way to get them to show up in the Thirdlane GUI? Thanks again.

Bob Rafferty

Submitted by conraddewet on Mon, 08/15/2011 Permalink

Hi guys, i'm having the same issue.

With Queue call recording enabled, asterisk records the call, but save the files as ....in.wav and ...out.wav. That's using the default thirdlane setting SIP/XX. Also there is no specific extension cdr line for the call from the queue to the extension. So its a puzzle to figure out how long they waited in the queue before getting answered by someone, and there is no entry in the extension's cdr.

if i use the Local/XXX method the extension records perfectly and the call to the extension is recorded in a new line on the CDR, meaning the extensions cdr's detail are correct, and accompanying call recoding... however the availability is lost as asterisks blindly attempts to the contact the member on a given extension, resulting with an error... "i don't know what to do with..."

Both have pros and cons... my question is how do it get both.
Caller enters a queue, watis with nice music, gets set to to extension xxx because it available, a new cdr is started with dst = xxx and a new call recoding is started.

any ideas?

Submitted by eeman on Fri, 08/19/2011 Permalink

the most 2 common issues with files not being mux'ed together:

- not having monitor-type=MixMonitor set in queues.conf under [general]

- an issue with your sox installation

Submitted by conraddewet on Fri, 08/19/2011 Permalink

Yip, thanks its sorted.

I took a look as voip-info and found the monitor-type=MixMonitor, that was sorted.

Then for the cdr, I changed my display data, i just a set a condition in the row, that if the lastapp as "Queue" then don't look in the dst column for the destination, use the dstchannel - strip the "-xxxx" and then it was done. (BTW.. for those following, we don't use the TL CDR page, we send them off to another server for further breakdown and analysis.)

So now its 99% correct now... the only issue is a "cart-before-horse" issue of the call recording file name not containing the extension number of the final person who accepted the call. For this we are going to be doing some post processing. Ill probably change the file name to include the unique id of the call so that i can do some kind of conditional lookup in the extension cdrs. I understand the unique id is the same from start to finish of the call. I'm sure a smart enough script will fix that up nice.

Submitted by eeman on Fri, 08/19/2011 Permalink

the queue_log file will list what agent/member accepts a call and its disposition.. what you're likely looking for is to use this log, in conjunction with the CDR data. The queue_log will list the uniqueid of the call so that would be your cross-reference key. Queuemetrics has a perl program called queueloader that will scan the queue_log and inject it into their mysql database. You could poach that script to scan the log and instead inject it into a database/table of your choosing.

Submitted by conraddewet on Fri, 08/19/2011 Permalink

Oh yes, i forgot to mention that! I was most excited to see that the queue_log has in fact been quietly keeping a record of everything that was going on.

Quick question, is it worth setting the queue_log to mysql? worth it?

Submitted by eeman on Fri, 08/19/2011 Permalink

if you're wanting a statistical page where you are pulling data about a call and need data from both logs then having it in mysql is useful since you can index on something like uniqueid. I was contemplating an opposite statistic report.. where one is looking at queue statistics specifically. It would be very useful to look at a report of a call, and be able to click on its uniqueid and pull up the CDR record of that same call. It would also be very cool if the name of the recording included the uniqueid so that, from the same interface, it would be trivial to click on and play that recording.

Submitted by IVSCOMM on Thu, 02/02/2012 Permalink

Is there a way to add the tenant name to the queue recording?
So instead of just the Unique call Id you get the call id and the tenant name.

123456778899-1234556.WAV
is roughly what I get now.

I would like it to be
123456778899-1234556-TenantName.WAV

Submitted by IVSCOMM on Thu, 02/02/2012 Permalink

it was working when I turned it on in january this is how it labeled them:

queue-InboundCalls-TenantName-2012-01-09-10-35-19-55555555555-TenantName.wav

Later that day and from then on it labeled them this way:

1234567890.123456.wav

Any ideas as to why it changed?