[asterisk-dev] Corrupted recordings

[Daniel Journo]

My experience with recording and call transferring is that the recording ends as soon as the call is transferred.
This is because the recording is started on party B's channel so when party A is transferred to party C, party B's channel ends along with the recording.
I had to create an agent running on the servers using AMI to start the recording on party A's channel to prevent this from happening.

This is with mixmonitor though. I don't know whether it applies to res_monitor. And in my case, the records weren't corrupt. They were just missing half the call.

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of James Cloos
Sent: 19 April 2018 19:56
To: asterisk-dev at lists.digium.com
Subject: [asterisk-dev] Corrupted recordings

I've been made aware of an instance of asterisk which makes heave use of res_monitor, records to gsm files, and often sees corruption in the gsm files.

The corrupt blobs are very regular.  If you split an affected gsm file into 33-octet chunks, all of the non-gsm chunks in each such blob are identical.

The suspicion is that the caller transferred the call.  My suspicion, therefore, is that the corruption is ulaw rining packets.

Is it possible that the code which generates ringing sounds bypasses res_monitor's codec translation?


The problem with the corruption is that libgsm's decode routine truncates the output once it sees a non-gsm 33-octet packet.
Ie one which does not start with the nybble 0xD.  So all of the data after that is lost.

-JimC
--
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6





--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180419/12cee37e/attachment.html>