[Home]

Summary:ASTERISK-20156: MixMonitor creates file even if call state is unanswered (leaves zero length files)
Reporter:George Keretchashvili (telvo)Labels:
Date Opened:2012-07-20 12:20:37Date Closed:
Priority:TrivialRegression?
Status:Open/NewComponents:Applications/app_mixmonitor
Versions:10.6.1 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Fedora Core 9, 2.6.25-14.fc9.i686Attachments:( 0) 20120719-101521-1342678521.41.mp3
( 1) 20120720-212459-1342805099.19.wav
( 2) asterisk-20156-mixmonitor-zero-len-file.diff
Description:After upgrading from 1.8.8.1, when using MixMonitor() followed by Dial() and the call was not answered (either 180 or 183 SIP message), I get empty audio file recorded with 3ms in length. The file is then converted with bash script to mp3.
{noformat}
MixMonitor(${MONITOR_FILENAME}.wav,b,${MONITOR_EXEC});
Dial(SIP/${TRUNK}/${DESTINATION});
{noformat}
Comments:By: George Keretchashvili (telvo) 2012-07-20 12:28:04.503-0500

original file recorded by MixMonitor
By: Rusty Newton (rnewton) 2012-07-20 16:53:52.568-0500

Please provide the dialplan and an Asterisk full log with DEBUG and VERBOSE of at least level 5 showing this issue in action.  Remember to sanitize anything private.

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: George Keretchashvili (telvo) 2012-07-21 17:18:01.174-0500

This is a production machine, so I am getting too many other output in debug. Will try to provide debug some time later.

Meanwhile I have temporarily resolved problem with bash script responsible for converting wavs to mp3. Script first checks for file size and ignores files less than 1000 bytes. Converted and ignored files are then removed by script.
By: Rusty Newton (rnewton) 2012-07-23 18:31:44.730-0500

thanks - remember to use the "Enter Feedback" button when you gather the debug, otherwise we may miss you.
By: Jonathan Rose (jrose) 2012-08-03 14:24:48.668-0500

There isn't any need for feedback on this one. Reproduction is trivial, as this will always happen if you call mixmonitor and don't actually record anything. The only question is whether it's actually worth addressing. The behavior is predictable and trivial and it isn't even really wrong. We've never actually specified anywhere that we won't create these files under these conditions.

The only real question is whether it would be desirable to change the behavior. I can't really see any justification for the severity being 'major' as the bug report indicates. If it's messing with your script, just have your script check the file's length before running some kind of conversion on it.


By: George Keretchashvili (telvo) 2012-08-03 16:25:37.503-0500

Thank you for your response Jonathan. This behavior was not trivial in 1.8.8.1 or older versions (as I remember) and was unexpected in 10.6.1 to me.

Why would anyone need zero length files of unanswered calls, especially if MixMonitor is called with 'b' option. BTW I found number of others posting about this behavior.

I think it would be very desirable not to create or delete these empty files if nothing was recorded, or at least include an option to specify if MixMonitor should keep zero files anyway.


Thanks
George
By: George Keretchashvili (telvo) 2012-08-03 16:32:11.579-0500

It's true issue severity should not be 'major', sorry this was my first bug report. Now I've changed it to trivial. This bug just accumulates lots of garbage, requires checks against lengths before processing audio files by other systems and requires manual or automated clean-up.
By: Jonathan Rose (jrose) 2012-08-03 16:41:17.677-0500

No one actually needs zero length files. It's just that mixmonitor creates the files as well as their streams during startup for the application regardless of whether record on bridge mode is active or not. This isn't entirely without its advantages since it probably saves us a minuscule amount of time when actually starting the recording afterwards.

It would probably be easier to create an option to delete them afterwards than it would be to change Asterisk not to create the files until the bridge is made though.
By: Michael L. Young (elguero) 2012-08-09 21:37:05.832-0500

Just curious if this is being worked on.  I saw a clone has been made on this issue which I have no permission to view.  Based on Jonathan's comments, I thought that it might not be worked on but now that I see the cloned issue, I think that maybe it is being worked on.  This is still assigned to Rusty, though, so I am a bit confused on the status of this issue.

I have come up with a very simple patch that removes the file if no audio was written to it.  Perhaps it is too simple but it seems to be working from my testing.  I took a look at app_record and see that it deletes files when no audio has been captured.  I think this could be used to help define expected behavior.  I personally would expect an application to clean up its files if they are not used at all such as what happens in this scenario.

If it is being worked on, I will move along to something else.
By: Richard Mudgett (rmudgett) 2012-08-09 22:18:38.392-0500

Michael you can have it.
By: Michael L. Young (elguero) 2012-08-10 10:08:48.297-0500

Cool... Thanks Richard... Didn't want to step on anyone's work and thought it best to check first.  Will be uploading a patch soon.
By: Michael L. Young (elguero) 2012-08-10 11:20:22.133-0500

Very simple patch which doesn't go the route of setting an option.  If we want an option, then that would require a different patch.

This is based off of looking at app_record and seeing how it handles recordings when no audio is written to the file.
By: George Keretchashvili (telvo) 2012-08-12 17:26:30.958-0500

Thank you Michael, haven't had opportunity to test it yet. Hopefully something like this will be included in next release.

Should I close this issue now or wait for some acceptance to make sure it will be included in future release? Again, sorry as this was my first bug report and I not very familiar how things are done here.
By: Michael L. Young (elguero) 2012-08-12 17:57:40.509-0500

Nope, you don't need to close it.  What you can do is test the patch and report back here if it solves the issue for you.  In the meantime, I have already submitted this for review and I will then work on getting it into the code base.

Thanks for your feedback.
By: Amilcar S Silvestre (amilcar) 2014-03-30 05:58:22.796-0500

The code to fix this is at https://reviewboard.asterisk.org/r/2068/ . It's almost complete! Is there any way we can help to make the code merged? The amount of garbage and wasted space because of this bug is enormous.
By: Boris Barabanov (boristheblade) 2015-09-14 04:09:23.984-0500

Also this bug confirm on asterisk version 13.5.0
By: Mauricio Ocampo (maoxcreativo) 2016-05-04 15:15:44.442-0500

same at the 11.22.0 version