[asterisk-bugs] [JIRA] (ASTERISK-21294) Calling StopMixMonitor on a channel w/o MixMonitor running returns -1

[Schmooze Com (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204448#comment-204448 ] 

Schmooze Com commented on ASTERISK-21294:
-----------------------------------------

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.
                
> Calling StopMixMonitor on a channel w/o MixMonitor running returns -1
> ---------------------------------------------------------------------
>
>                 Key: ASTERISK-21294
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21294
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_mixmonitor
>    Affects Versions: 11.2.1
>            Reporter: daroz
>            Assignee: Michael L. Young
>            Severity: Minor
>         Attachments: asterisk-21294-stop_mixmonitor_hangingup.diff
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira