[asterisk-dev] [Code Review] MixMonitor Leaves Empty Audio Files Behind

[elguero]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2068/
-----------------------------------------------------------

(Updated Oct. 22, 2012, 4:22 p.m.)


Review request for Asterisk Developers.


Changes
-------

- This patch now takes care of audio files created from different streams (received audio and transmitted audio) as well as the mixed audio file
- Re-factored the patch to make the code easier to read and maintain now that there are three audio files that need to be handled if a user has turned on the options r and t


Summary
-------

When the MixMonitor application is started, it creates an empty audio file (just the header is present) for writing an audio stream.

In the event that MixMonitor is started before dialing (in the case on the issue, record only a bridged channel) but the bridge never is setup due to the other side not answering or for whatever reason the bridge did not succeed in being created, MixMonitor does not clean up the empty audio file.  This has the effect of leaving empty audio files behind.

This proposed patch is a simple one.  I took a look at app_record to see how it handles files that do not contain any audio and proceeded to create this patch to match that behavior.


This addresses bug ASTERISK-20156.
    https://issues.asterisk.org/jira/browse/ASTERISK-20156


Diffs (updated)
-----

  /branches/10/UPGRADE.txt 375324 
  /branches/10/apps/app_mixmonitor.c 375324 

Diff: https://reviewboard.asterisk.org/r/2068/diff


Testing
-------

Reproducing this issue is pretty straight forward.  I tested this patch on one of my local dev machines.  I have yet to get a response on the issue as to whether it is working for the original reporter.


Thanks,

elguero

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121022/003549b1/attachment.htm>