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: [email protected] 
[mailto:[email protected]] On Behalf Of James Cloos
Sent: 19 April 2018 19:56
To: [email protected]
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 <[email protected]>         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
-- 
_____________________________________________________________________
-- 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

Reply via email to