HELP! 44 Byte Recordings!

1

We have 1-2% of our call recordings showing up empty (44 bytes). Based on cdr logs, the calls are typical. Many of the calls in question lasted for several minutes… This is a call center using queues. So far, nothing I have read in forums give me any good clues.

Here is the situation. I am very new to Asterisk (and Linux for that matter). I called the home office and expressed interest in paid support. However, I am only authorized to pay for two hours. The office says no one can speak to me on the phone about it, but they said developers and support personnel monitor the forum. If someone up there believes they can diagnose the problem and offer a solution we can implement in two hours paid time, please let me know. We are ready to move immediately.

Folks in sales says no way, I have been be a developer for 20+ years. I have never had a support issue that took more than two hours, short of data recovery. Find your best guy, we are ready to pay.

2

44k recordings happen and you are correct they are empty. There is a process that cleans these up I believe on a cron Queues use their own recording so it would have a seperate recording

3

Help me with a clue here. All of the calls with good recordings have data in the dstchannel field. Most of calls with bad recording files do not. Here is an example that shows 263 seconds of duration. What gives? Was there an actual call?

calldate, clid, src, dst, dcontext, channel, dstchannel, lastapp, lastdata, duration, billsec, disposition, amaflags, accountcode, uniqueid, userfield, did, recordingfile, cnum, cnam, outbound_cnum, outbound_cnam, dst_cnam
’‘2017-03-13 12:11:17’, ‘“CS+18437154081” <18437154081>’, ‘18437154081’, ‘100’, ‘ext-queues’, ‘SIP/172.16.100.202-0000aef2’, ‘’, ‘Queue’, ‘100,t,’, ‘253’, ‘253’, ‘ANSWERED’, ‘3’, ‘’, ‘1489421477.90084’, ‘’, ‘+18665110793’, ‘q-100-18437154081-20170313-121152-1489421477.90084.wav’, ‘18437154081’, ‘+18437154081’, ‘’, ‘’, ‘’

4

If the recording is interrupted or transferred (say the person hangs up or gets dropped into a queue from an initial call) the “header stub” of the wav file will get created.

If there’s nothing in the dstchannel, that means the that call wasn’t routed to a destination through a normal call transfer (within the Asterisk context framework).

There was a question here a few weeks about calls that were not getting recorded after certain system events. I don’t remember any of the details, but someone might. It may or may not be related, but it’s a place to start.

Have you looked through the /var/log/asterisk/full log for the call and the PID associated with it? That string might give us some more clues as to what’s happening?