Repeated recording audio in Asterisk 18.12.1

Hello, can you help me the audio of several of the recordings is repeated and I don’t know how to fix it.
I’m using the mixmonitor to record and the alaw, ulaw and g729 codecs

I’m not sure what you really mean by this. You’ll need to describe more about what is actually happening.

I have recordings, for example, of 2 minutes, but the last 30 seconds the recording is repeated.

So, you have a 2 minute phone call. Do you end up with a 2 minute recording that’s 1.5 minutes of the call followed by the 1 minute to 1 minute 30 again or a 2.5 minute recording with the last 30 seconds duplicated?

Are you, by any chance, accessing the file before it is closed?

What format are you recording it in? (Most people would not record using a raw codec, and it seems more likely that things could go wrong with .wav or .WAV (=.wav49), than with a raw codec format.)

Hi everyone. We further investigate the issue, and at least we detected something else about the problem.

First, we have configured an automatic dialer, that, to put it simple, makes a call using call files, then when the call is answered it is redirected to a queue application. In the queue, we have configured monitor-format=WAV and monitor-type=MixMonitor, and in the dialplan we have Set(MONITOR_OPTIONS=W(1)) prior to queue app. The recording of the queue call, should be only the recording of the audio when the call is routed to an agent and the recording duration should be that of the conversation only, I mean the recording should start when the agent answers the call and finish when the call hangs up, and that happens most of the time, but there are some calls where the recording last longer, and that extra duration is filled with the last seconds of the same audio.

What we recently find out, is that this happens when the call is waiting in the queue to be answered.

So, for example, I have a call that enters the queue at 10:12:55, then, because the queue was full and some agent didn’t answer, the call finally gets answered at 10:13:35 (40 seconds later), then agent talk for 21 seconds, so the call ends at 10:13:56. The recording of this file should be only the 21 seconds of the conversation the agent had with the client, but the file we get is a 61 seconds recording, the first 21 seconds is the correct audio of the conversation of the agent, and the next 40 seconds are the last 40 seconds of the call (in this case the 21 seconds of the conversation plus 19 seconds of music on hold)

This happens with every audio recording of the answered calls, so if the conversation last for example 100 seconds, and the client was on hold in the queue for 10 seconds, the recording lasts 110 seconds, with the last 10 seconds filled with the last 10 seconds of the conversation.

We use local channels as queue agents, and we don’t manipulate the file audio in any way during the call.

Please, any ideas on how can we address this issue? If you need more details just let me know, tough we will continue investigating why this happens in our case.

You need to provide a procedure by which other people can reproduce this, as its basically something that doesn’t make sense, unless, just possibly, you are access (which could include copying) the file whilst it is still being written, which was my thought, above.

Yeah, I know that this sounds really weird. When I got reported this issue I thought someone messed up with the recording but I can assure you that it is not the case. I’ll try to create a simple dialplan and procedure to replicate this.

Also, we recently discover one important thing. As I mentioned, we basically make a call using a .call file, then when the call gets answered it is redirected to a queue with agents using a local channel. What I didn’t mention is that the .call file also uses a local channel, I mean, the “channel:” in the .call file is a local channel too, which makes some preprocessing (querying and saving some details in a database) and then makes a Dial using a SIP trunk). We made a modification to our software, so now in the call file, in the channel:, we make a direct call to the SIP trunk, and the issue is gone, and the recording is correctly saved only with the conversation from the agent with the client and no weird recording with repeated audio.

We are now trying to implement this on production (it may take a little time because getting rid of the original local channels brings some other issues with the data we were querying and saving) but I will make some time to give you a scenario to try this, because I thinks it is a bug or at least an issue of some kind.