<div dir="ltr"><div>Hello list,</div><div>Hope you are all doing fine!</div><div><br></div><div>While playing around with the MixMonitor, I've found out that it is possible to start the MixMonitor multiple times to the same output file.</div><div>It is very easy to reproduce, via the CLI or via the dialplan. If the MixMonitor is called twice from the same channel, to the same output file and with option append. After that, with the "mixmonitor list" command we can see two running instances, and also from Linux open files "lsof" we can see two Asterisk process with the same file opened. Nevertheless, in this case the file does not gets corrupted and the recording is completely fine.</div><div>However after observing such behavior I decided to call MixMonitor twice to the same file but from different channels. The observed behavior is that the output file has the contents of the first call until the second MixMonitor command is called for the second call. After that only the second call is recorded. If this is stopped, the first call is recorded again.<br></div><div>I know we can consider an application/dialplan error to call MixMonitor twice for the same output file like this, but I am just curious to know if this situation is actually being handled by the Asterisk/MixMonitor code or if it is completely undefined behavior, since the behavior I described  is actually consistent. <br></div><div>Anyway, to avoid confusion and weird behavior, I think it would be 
probably 

better if Asterisk just not allow creating a MixMonitor thread to a file that is already opened by some other MixMonitor thread. Or is there any reason/situation in which this is not desired?<br></div><div><br></div><div>Kind regards,</div><div>Cheers,</div><div>Patrick Wakano<br></div></div>