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

[Michael L. Young (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael L. Young updated ASTERISK-21294:
----------------------------------------

    Assignee: Michael L. Young  (was: daroz)
      Status: Open  (was: Waiting for Feedback)

Thanks for the feedback.  Glad to hear it seems to have fixed the behavior change.
                
> 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