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

Michael L. Young (JIRA) noreply at issues.asterisk.org
Mon Mar 18 22:20:01 CDT 2013


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

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

    Assignee: daroz
      Status: Waiting for Feedback  (was: Open)
    
> 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: daroz
>            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



More information about the asterisk-bugs mailing list