[Home]

Summary:ASTERISK-25674: Mixmonitor stop recording after atxfer
Reporter:Leandro Dardini (ldardini)Labels:
Date Opened:2016-01-09 14:55:49.000-0600Date Closed:2016-01-14 07:25:26.000-0600
Priority:MinorRegression?Yes
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:13.6.0 Frequency of
Occurrence		Constant
Related
Issues:
is duplicated byASTERISK-25801 app_mixmonitor: Does not continue after attended transfer
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 problemAttachments:
Description: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.

Comments:By: Asterisk Team (asteriskteam) 2016-01-09 14:55:51.159-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Rusty Newton (rnewton) 2016-01-11 14:36:37.981-0600

{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].
By: Leandro Dardini (ldardini) 2016-01-13 15:41:00.153-0600

This is the log

{noformat}
[2016-01-13 22:29:05] VERBOSE[3263][C-000005b7] pbx.c: Executing [55512345@authenticated:1] Set("SIP/104-DEVEL-0000001e", "__TRANSFER_CONTEXT=authenticated") in new stack
[2016-01-13 22:29:05] VERBOSE[3263][C-000005b7] pbx.c: Executing [55512345@authenticated:2] Set("SIP/104-DEVEL-0000001e", "RECORDINGFORMAT=wav") in new stack
[2016-01-13 22:29:05] VERBOSE[3263][C-000005b7] pbx.c: Executing [55512345@authenticated:3] Set("SIP/104-DEVEL-0000001e", "__MIXMONITOR_FILENAME=srv01-1452720545.73.wav") in new stack
[2016-01-13 22:29:05] VERBOSE[3263][C-000005b7] pbx.c: Executing [55512345@authenticated:4] MixMonitor("SIP/104-DEVEL-0000001e", "srv01-1452720545.73.wav,ab") in new stack
[2016-01-13 22:29:05] VERBOSE[3263][C-000005b7] pbx.c: Executing [55512345@authenticated:5] Dial("SIP/104-DEVEL-0000001e", "SIP/onlytest/55512345") in new stack
[2016-01-13 22:29:05] VERBOSE[3264][C-000005b7] app_mixmonitor.c: Begin MixMonitor Recording SIP/104-DEVEL-0000001e
[2016-01-13 22:29:05] VERBOSE[3263][C-000005b7] netsock2.c: Using SIP RTP TOS bits 184
[2016-01-13 22:29:05] VERBOSE[3263][C-000005b7] netsock2.c: Using SIP RTP CoS mark 5
[2016-01-13 22:29:05] VERBOSE[3263][C-000005b7] app_dial.c: Called SIP/onlytest/55512345
[2016-01-13 22:29:05] VERBOSE[3263][C-000005b7] app_dial.c: SIP/onlytest-0000001f answered SIP/104-DEVEL-0000001e
[2016-01-13 22:29:05] VERBOSE[3270][C-000005b7] bridge_channel.c: Channel SIP/onlytest-0000001f joined 'simple_bridge' basic-bridge <d27615ad-8fbf-4514-8273-1aff120054df>
[2016-01-13 22:29:05] VERBOSE[24765] chan_sip.c: Extension Changed 104-DEVEL[authenticated] new state InUse for Notify User 100-DEVEL
[2016-01-13 22:29:05] VERBOSE[3263][C-000005b7] bridge_channel.c: Channel SIP/104-DEVEL-0000001e joined 'simple_bridge' basic-bridge <d27615ad-8fbf-4514-8273-1aff120054df>
[2016-01-13 22:29:21] VERBOSE[3270][C-000005b7] res_musiconhold.c: Started music on hold, class 'default', on channel 'SIP/onlytest-0000001f'
[2016-01-13 22:29:25] VERBOSE[24969][C-000005b9] netsock2.c: Using SIP RTP TOS bits 184
[2016-01-13 22:29:25] VERBOSE[24969][C-000005b9] netsock2.c: Using SIP RTP CoS mark 5
[2016-01-13 22:29:25] VERBOSE[3807][C-000005b9] pbx.c: Executing [105@authenticated:1] Set("SIP/104-DEVEL-00000020", "__TRANSFER_CONTEXT=authenticated") in new stack
[2016-01-13 22:29:25] VERBOSE[3807][C-000005b9] pbx.c: Executing [105@authenticated:2] Set("SIP/104-DEVEL-00000020", "RECORDINGFORMAT=wav") in new stack
[2016-01-13 22:29:25] VERBOSE[3807][C-000005b9] pbx.c: Executing [105@authenticated:3] Set("SIP/104-DEVEL-00000020", "__MIXMONITOR_FILENAME=srv01-1452720565.75.wav") in new stack
[2016-01-13 22:29:25] VERBOSE[3807][C-000005b9] pbx.c: Executing [105@authenticated:4] MixMonitor("SIP/104-DEVEL-00000020", "srv01-1452720565.75.wav,ab") in new stack
[2016-01-13 22:29:25] VERBOSE[3807][C-000005b9] pbx.c: Executing [105@authenticated:5] Dial("SIP/104-DEVEL-00000020", "SIP/105-DEVEL") in new stack
[2016-01-13 22:29:25] VERBOSE[3808][C-000005b9] app_mixmonitor.c: Begin MixMonitor Recording SIP/104-DEVEL-00000020
[2016-01-13 22:29:25] VERBOSE[3807][C-000005b9] netsock2.c: Using SIP RTP TOS bits 184
[2016-01-13 22:29:25] VERBOSE[3807][C-000005b9] netsock2.c: Using SIP RTP CoS mark 5
[2016-01-13 22:29:25] VERBOSE[3807][C-000005b9] app_dial.c: Called SIP/105-DEVEL
[2016-01-13 22:29:25] VERBOSE[3807][C-000005b9] app_dial.c: SIP/105-DEVEL-00000021 is ringing
[2016-01-13 22:29:25] WARNING[3807][C-000005b9] translate.c: no samples for ulawtolin
[2016-01-13 22:29:28] VERBOSE[3807][C-000005b9] app_dial.c: SIP/105-DEVEL-00000021 answered SIP/104-DEVEL-00000020
[2016-01-13 22:29:28] VERBOSE[4077][C-000005b9] bridge_channel.c: Channel SIP/105-DEVEL-00000021 joined 'simple_bridge' basic-bridge <ce4af82b-34a9-45b4-9cf3-68a081029ac6>
[2016-01-13 22:29:28] VERBOSE[3807][C-000005b9] bridge_channel.c: Channel SIP/104-DEVEL-00000020 joined 'simple_bridge' basic-bridge <ce4af82b-34a9-45b4-9cf3-68a081029ac6>
[2016-01-13 22:29:42] VERBOSE[24969][C-000005b7] bridge_channel.c: Channel SIP/onlytest-0000001f left 'simple_bridge' basic-bridge <d27615ad-8fbf-4514-8273-1aff120054df>
[2016-01-13 22:29:42] VERBOSE[24969][C-000005b7] bridge_channel.c: Channel SIP/104-DEVEL-00000020 left 'simple_bridge' basic-bridge <ce4af82b-34a9-45b4-9cf3-68a081029ac6>
[2016-01-13 22:29:42] VERBOSE[24969][C-000005b7] bridge_channel.c: Channel SIP/onlytest-0000001f swapped with SIP/104-DEVEL-00000020 into 'simple_bridge' basic-bridge <ce4af82b-34a9-45b4-9cf3-68a081029ac6>
[2016-01-13 22:29:42] VERBOSE[3263][C-000005b7] bridge_channel.c: Channel SIP/104-DEVEL-0000001e left 'simple_bridge' basic-bridge <d27615ad-8fbf-4514-8273-1aff120054df>
[2016-01-13 22:29:42] VERBOSE[3263][C-000005b7] pbx.c: Spawn extension (authenticated, 55512345, 5) exited non-zero on 'SIP/104-DEVEL-0000001e'
[2016-01-13 22:29:42] VERBOSE[3264][C-000005b7] app_mixmonitor.c: MixMonitor close filestream (mixed)
[2016-01-13 22:29:42] VERBOSE[3264][C-000005b7] app_mixmonitor.c: End MixMonitor Recording SIP/104-DEVEL-0000001e
[2016-01-13 22:29:42] VERBOSE[3807][C-000005b9] pbx.c: Spawn extension (authenticated, 105, 5) exited non-zero on 'SIP/104-DEVEL-00000020'
[2016-01-13 22:29:42] VERBOSE[3808][C-000005b9] app_mixmonitor.c: MixMonitor close filestream (mixed)
[2016-01-13 22:29:42] VERBOSE[3808][C-000005b9] app_mixmonitor.c: End MixMonitor Recording SIP/104-DEVEL-00000020
[2016-01-13 22:29:42] VERBOSE[3270][C-000005b7] res_musiconhold.c: Stopped music on hold on SIP/onlytest-0000001f
[2016-01-13 22:29:42] VERBOSE[24765] chan_sip.c: Extension Changed 104-DEVEL[authenticated] new state Idle for Notify User 100-DEVEL
[2016-01-13 22:30:00] VERBOSE[4077][C-000005b9] bridge_channel.c: Channel SIP/105-DEVEL-00000021 left 'native_rtp' basic-bridge <ce4af82b-34a9-45b4-9cf3-68a081029ac6>
[2016-01-13 22:30:00] VERBOSE[3270][C-000005b7] bridge_channel.c: Channel SIP/onlytest-0000001f left 'native_rtp' basic-bridge <ce4af82b-34a9-45b4-9cf3-68a081029ac6>
{noformat}

This is the dialplan:

{noformat}
context authenticated {
      104 => {
          Set(__TRANSFER_CONTEXT=authenticated);
          Set(RECORDINGFORMAT=wav);
          Set(__MIXMONITOR_FILENAME=${UNIQUEID}.${RECORDINGFORMAT});
          MixMonitor(${MIXMONITOR_FILENAME},ab);
          Dial(SIP/104-DEVEL);
          }

      105 => {
          Set(__TRANSFER_CONTEXT=authenticated);
          Set(RECORDINGFORMAT=wav);
          Set(__MIXMONITOR_FILENAME=${UNIQUEID}.${RECORDINGFORMAT});
          MixMonitor(${MIXMONITOR_FILENAME},ab);
          Dial(SIP/105-DEVEL);
          }

      55512345 => {
          Set(__TRANSFER_CONTEXT=authenticated);
          Set(RECORDINGFORMAT=wav);
          Set(__MIXMONITOR_FILENAME=${UNIQUEID}.${RECORDINGFORMAT});
          MixMonitor(${MIXMONITOR_FILENAME},ab);
          Dial(SIP/onlytest/55512345);
          }
}
{noformat}

In /var/spool/asterisk/monitor I can find the following files:

{noformat}
# ls -lat /var/spool/asterisk/monitor/ | more
totale 1,3M
-rw-r--r--  1 root root 441K 13 gen 22:29 srv01-1452720545.73.wav
-rw-r--r--  1 root root 223K 13 gen 22:29 srv01-1452720565.75.wav
drwxr-xr-x  3 root root  16K 13 gen 22:29 .
{noformat}


By: Rusty Newton (rnewton) 2016-01-13 18:18:51.315-0600

The log appears to confirm what I was thinking.

The MixMonitor is started on the calling channel and therefore follows the calling channel (and ends when it hangs up). This is expected and appropriate behavior.

If you want MixMonitor to follow the called party then you need to call MixMonitor on the called channel. You probably want to call MixMonitor within a [pre-bridge handler|https://wiki.asterisk.org/wiki/display/AST/Pre-Bridge+Handlers] on the called channel(dialed party).
By: Leandro Dardini (ldardini) 2016-01-14 02:19:48.780-0600

I can make a test on this way, but starting the MixMonitor on the called channel will just "move the problem a bit farther", without solving the general user problem of "I want to record this call... whatever it happens". I will make some tests,  but what happens if it will be the called party to make an attended transfer?

A wants all his calls recorded
A calls B (the call is recorded because the MixMonitor is attached to B)
B make an attended transfer to C (call is not recorded and that can be right because that will be a "private" talk between B and C)
B transfer the call from A to C
A and C talks (but I think the call will not be recorded)

Maybe the AUDIOHOOK_INHERIT was not so bad?



By: Rusty Newton (rnewton) 2016-01-14 07:25:26.406-0600

{quote}
I can make a test on this way, but starting the MixMonitor on the called channel will just "move the problem a bit farther", without solving the general user problem of "I want to record this call... whatever it happens". I will make some tests, but what happens if it will be the called party to make an attended transfer?
A wants all his calls recorded
A calls B (the call is recorded because the MixMonitor is attached to B)
B make an attended transfer to C (call is not recorded and that can be right because that will be a "private" talk between B and C)
B transfer the call from A to C
A and C talks (but I think the call will not be recorded)
{quote}

MixMonitor is following a channel, not following a call. "calls" in Asterisk are quite ambiguous. In the case you describe - if you want MixMonitor to follow both channels then you should call MixMonitor on both channels.

Going beyond that you are asking for a new feature. I'm also not sure it would make sense to have MixMonitor by default follow the channel and all bridged/connected channels. I could imagine that getting out of hand quickly in some situations.

{quote}
Maybe the AUDIOHOOK_INHERIT was not so bad?
{quote}

As far as I can tell the behavior is the same as with AUDIOHOOK_INHERIT, you simply don't have to call the function now.


I'm closing this out as Not a Bug since it appears to be operating by design. We try to avoid discussing new features in depth on the tracker when we don't have a patch. It makes more sense on the mailing list so that others can join the conversation. Feel free to bring the issue up on the asterisk-dev mailing list if you want to suggest and discuss changes or propose a patch.
By: Joseph Tingiris (jtingiris) 2018-02-13 12:58:14.721-0600

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 StopMixMonitor stop both?