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

Rusty Newton (JIRA) noreply at issues.asterisk.org
Mon Jan 11 14:39:35 CST 2016


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

Rusty Newton edited comment on ASTERISK-25674 at 1/11/16 2:39 PM:
------------------------------------------------------------------

{quote}
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.
{quote}

Please provide the dialplan used as well as an Asterisk log (warning,error,notice,verbose at least) showing a complete call. Make sure verbose is turned up to 5.

I'd like to see which channel MixMonitor is executed on and with what options.

If the recording is executed on the channel originally dialing then I believe it will follow that party and not the transferred party.

Back in 11 you had to use AUDIOHOOK_INHERIT, but now [that is all handled for you of course|https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Function_AUDIOHOOK_INHERIT].


was (Author: rnewton):
{quote}
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.
{quote}

Please provide the dialplan used as well as an Asterisk log (warning,error,notice,verbose at least) showing a complete call. Make sure verbose is turned up to 5.

I'd like to see which channel MixMonitor is executed on and with what options.

If the recording is executed on the channel originally dialing then I believe it will follow that party and not the transferred party.

Back in 11 you had to use AUDIOHOOK_INHERIT, but now that is all handled for you of course.

> 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: Leandro Dardini
>            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)



More information about the asterisk-bugs mailing list