[asterisk-bugs] [JIRA] (ASTERISK-25674) Mixmonitor stop recording after atxfer

[Joseph Tingiris (JIRA)]

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

Joseph Tingiris commented on ASTERISK-25674:
--------------------------------------------

I realized this is closed, and has been for a while, but found the comments relevant.  I've also run into some challenges with MixMonitor's behavior of following the channel it was started on.  Trying to use dynamic feature codes to StopMixMonitor() wont (easily) work on both sides of the call.  I had to write pre-dial subroutines to invoke different DYNAMIC_FEATURENAMEs for each, self and peer.  That works, but ... it never occurred to me to try and start it on both channels.  Something to try ... thanks.

I'm wondering, if it's started on both channels then what will happen (or what is the expected behavior) if they both use the same MIXMONITOR_FILENAME?

Also, if StopMixMonitor is called then will it still need to be called on the channel that 'first' started MixMonitor?  Or, will a single MixMonitorStop stop both?

> Mixmonitor stop recording after atxfer
> --------------------------------------
>
>                 Key: ASTERISK-25674
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25674
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_mixmonitor
>    Affects Versions: 13.6.0
>         Environment: Asterisk 13.6 compiled from source on CentOS 6.7 64 bit. I have also tried asterisk 13.7.0-rc2 finding the same problem
>            Reporter: Leandro Dardini
>            Assignee: Unassigned
>            Severity: Minor
>
> This seems the same bug affecting asterisk few years ago and that got fixed in asterisk 11. I tested asterisk 11.20 and the bug is not present. In short, when recording is active on a call, making an attended transfer will continue to record (in a different file, but that is correct) the "short talk", but does not record the transferred call. Let me picture better the case, if not enough clear.
> Extension 104 dials number 555-12345, recording is active and the call is recorded correctly.
> Extension 104 puts the call on hold and dials extension 105, recording is active and the call is recorded correctly.
> Extension 104 transfer the 555-12345 call leg to 105. Recording is NOT active and the call is NOT recorded.



--
This message was sent by Atlassian JIRA
(v6.2#6252)