Summary: | ASTERISK-21294: Calling StopMixMonitor on a channel w/o MixMonitor running returns -1 | ||||
Reporter: | daroz (daroz) | Labels: | |||
Date Opened: | 2013-03-16 15:21:32 | Date Closed: | 2013-03-22 17:00:37 | ||
Priority: | Minor | Regression? | Yes | ||
Status: | Closed/Complete | Components: | Applications/app_mixmonitor | ||
Versions: | 11.2.1 | Frequency of Occurrence | |||
Related Issues: |
| ||||
Environment: | Attachments: | ( 0) asterisk-21294-stop_mixmonitor_hangingup.diff | |||
Description: | With the change in [ASTERISK-19096] allowing StopMixMonitor to be called with an optional ID to determine which, of multiple, MixMonitors to stop, a minor regression has occurred. Currently FreePBX (in the 2.11 beta branch) uses macros to trigger recording stop and start, and in certain situations does call StopMixMonitor on channels that have not had MixMonitor started. This has been the case for several versions, and does work correctly in Asterisk 1.8.10 (tested myself) and in 1.10 (unspecified, per freepbx issue report). In cases where this use pattern occurs, StopMixMonitor will now return -1 and stop the dialplan currently executing (see https://code.asterisk.org/code/changelog/asterisk?cs=352093, line 814 in stop_mixmonitor_exec), where prior to this execution would continue.
Ideally, the previous behavior would be retained, that is, to not return -1, and allow continued execution of the dialplan. However, judging from the reviewboard for the patch in question (https://reviewboard.asterisk.org/r/1643/) it's not clear if this was intended, or an unintended consequence. If this is intended, this should be documented (or reverted, marked deprecated, and reapplied in a future version?), and if not intended reverted, perhaps with additional logging if this use pattern is not recommended. | ||||
Comments: | By: Michael L. Young (elguero) 2013-03-18 22:19:02.119-0500 Give this patch a try and please report back. Thanks By: daroz (daroz) 2013-03-18 23:55:49.744-0500 Path applied and put into a production system for testing. Will advise. Thanks. By: daroz (daroz) 2013-03-19 13:31:31.741-0500 Testing on production system today (11.2.1) was positive. No issues found with the patch either in application or use, and recording with both queues and extensions was nominal and in-line with the dialplan on the 1.8.10 box. By: Michael L. Young (elguero) 2013-03-19 14:18:27.441-0500 Thanks for the feedback. Glad to hear it seems to have fixed the behavior change. By: daroz (daroz) 2013-03-19 14:23:43.532-0500 ... and thank you for the quick patch and turnaround. By: daroz (daroz) 2013-03-20 12:06:07.867-0500 Brief update from the downstream bug (http://www.freepbx.org/trac/ticket/6416#comment:11). Another user reports successful testing of the patch in their test environment. By: Michael L. Young (elguero) 2013-03-20 12:10:33.126-0500 Nice! Thanks for the feedback. I have the patch up for code review (https://reviewboard.asterisk.org/r/2404/). As soon as it is approved, it will be added into the Asterisk code base. By: Schmooze Com (schmoozecom) 2013-03-20 19:52:29.891-0500 We went ahead and put this patch in the FreePBX Distro as it was causing issues for our users so that should get some good testing for you guys. Will let you know if we hear of any problems. |