While recording with mixmonitor in extensions.conf, when the call is over, the wav file is converted to mp3, and the file name is recorded in cdr with uniqueid.
In most cases, it works well, and if it is not created because it is not entered into the actual recording, it is saved in a way that is deleted from the database later.
However, the current problematic file is created, but files that cannot be played frequently occur. The characteristics of these files are .mp3 files, and they are all 1197 bytes.
I don’t know if there is a problem with the file creation itself, or if the problem is caused by trying to convert a file without data, or if an error occurred during the conversion process and the mp3 conversion failed even though there is no problem with the wav file.
If you have experienced the same symptoms or know a solution, please reply.
– extension ----------------------------------------
same = n,MixMonitor(${filename}.wav,b,conv2mp3 ${filename}.wav)
same = n,Set(CDR(recordingfile)=${UNIQUEID}.mp3)
same = n,Dial(PJSIP/${EXTEN:1}@XXXXXXXXXX ,20,r)
same = n,System(rm ${filename}.wav)
same = n,StopMixMonitor()
From our setup of call recording, we see the same with small files, containing no audio. (I think the WAVs are about 44 bytes.) I assume they are from calls that are never completed.
you’re right.
I confirmed that the wav file size is 44 bytes, and the playback time is 0 seconds.
However, if the billtime is more than 20 seconds, there is a case where recording is not possible.
What is the reason?
If you answer the call, then play a mandatory notification of the recording (Required in most jurisdictions as far as I know), this time will not be counted. In my country, a requirement is the caller can reject the recording, if they don’t consent to the recording.
A delay before user response, can explain if the time is never the same.
My theory has been that the 44 byte files, are calls where users terminate the call right after recording has been started, but before any audio is actually captured.
But it’s possible there’s something in the way Asterisk handles the audio streams between channels internally, that creates a situation where the channel initiating the recording, never see the actual audio, because of audio path optimizations. However, I know absolutely NOTHING about the internal workings of Asterisk, and can only speculate.
I DO know, however, that the forum is frequented by people who know how the internals of Asterisk works, so perhaps one of them stops by, and can explain what happens.