Call Recording does not stop when call is transfered

eek - The dialpaln command StopMixMonitor? does not exist in asterisk 1.2 (ok in 1.4 and 1.6). It may be necessary to live with the problem on 1.2 unless there is a workaround.

To fix this bug, core/functions.inc.php will need to have an asterisk version check before building the macro-record-enable context i.e. if asterisk >1.2 use ext_stopmixmonitor() class

Also ext_stopmixmonitor() class will need to be added to the file extensions.class.php

Nick,

interesting. I wonder if in 1.2, StopMonitor? used to stop the previous StartMixMonitor? since there was no StopMixMonitor?? We can clearly generate StopMixMonitor? (and add that to the class) but if it used to stop a StartMixMonitor? call, you would hope it still does in post 1.2 (although as you point out it does not.)

(In [7757]) add StopMixMonitor? to extension class re #3696

(In [7758]) fixes #3696

(In [7759]) Merged revisions 7647,7649-7683,7686,7690-7758 via svnmerge from http://svn.freepbx.org/modules/branches/2.5

........

r7735 | mickecarlsson | 2009-05-18 22:04:21 -0700 (Mon, 18 May 2009) | 1 line

Re #3657 updates Brazilian Portuguese translation for various modules

........

r7758 | p_lindheimer | 2009-05-27 13:02:22 -0700 (Wed, 27 May 2009) | 1 line

fixes #3696

........

(In [7771]) Merged revisions 7646-7699,7701-7705,7707-7755,7757-7770 via svnmerge from http://svn.freepbx.org/freepbx/branches/2.5

........

r7729 | p_lindheimer | 2009-05-15 08:40:02 -0700 (Fri, 15 May 2009) | 1 line

fixes #3680 undefined variable conf

........

r7736 | mickecarlsson | 2009-05-18 22:05:11 -0700 (Mon, 18 May 2009) | 1 line

Closes #3657 updates Brazilian Portuguese translation for core

........

r7744 | mickecarlsson | 2009-05-22 08:21:01 -0700 (Fri, 22 May 2009) | 1 line

Closes #3690, updated Ukranian language for ARI. Thank you Oleh

........

r7757 | p_lindheimer | 2009-05-27 12:54:11 -0700 (Wed, 27 May 2009) | 1 line

add StopMixMonitor? to extension class re #3696

........

r7768 | p_lindheimer | 2009-05-28 15:31:16 -0700 (Thu, 28 May 2009) | 1 line

fixes #3698 Voicemail Instctions in vmx and voicemail

........

A potential workaround in asterisk 1.2 may be to use the System() dialplan command to access the asterisk cli. For example: exten => s,n,System(asterisk -rx 'mixmonitor stop ${CHANNEL}')

To clarify, I have tested the existing StopMonitor? command in Asterisk 1.2 and it does NOT stop the mixmonitor. I have not yet tested my proposed System() workaround.

The following works ok for asterisk 1.2 exten => s,3,System(/usr/sbin/asterisk -rx " mixmonitor stop ${CHANNEL} ") Note that this does give a syntax warning in the log: pbx.c: Can't find trailing parenthesis? The warning does not affect operation as pbx.c uses the line ending instead I have tried single quotes, escaped double quotes and escaped single quotes but they either produce the syntax warning or break the system command so perhaps the system command in 1.2 has a bug in the passing of quotes.

Sorry the syntax warning related to a typo on the next line after the system command so the proposed asterisk 1.2 workaround is fine. exten => s,n,System(/usr/sbin/asterisk -rx " mixmonitor stop ${CHANNEL} ")

I still use some asterisk 1.2 so will be implementing this in place of StopMonitor?.

ouch - is there really no way on 1.2 to get a monitored channel to stop? Have you checked on the IRC or elsewhere?

IF something like this is needed, I would much prefer to go a route of executing this from within the AGI script. Both are very ugly, but I think the AGI script would be the "cleaner" of the ugly approaches. And if we did that, we could do it from within the existing AGI recording script. The suggestion would be to pass in a 3rd optional parameter to the recording script that defaults to 'false' and is passed is added to the dialplan when the call is generated. If set to true, then it opens a connection to the manager and executes the command.

Here is some pseudo code that would effectively do this. Have a look, you'll have to modify the dialplan generation to add in the option 3rd parameter that you see this would be expecting, and add this into the recordingcheck script after it has opened it's AGI connection:

// Add this before doing anything else, after the AGI is open. It expects a line in
// the dialplan that looks like:
// exten => s,n(check),AGI(recordingcheck,${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)},${UNIQUEID},STOPMIXMONITOR)
//
$stop_mixmonitor = isset($argv[3]) ? $argv[3] : false;
if ($stop_mixmonitor == 'STOPMIXMONITOR') {
  $ampmgruser   = get_var( "AMPMGRUSER" );
  $ampmgrpass   = get_var( "AMPMGRPASS" );
  $channel      = get_var( "CHANNEL" );
  require_once "phpagi-asmanager.php";
  $astman = newAGI_AsteriskManager();
  if (!$astman->connect("127.0.0.1", $ampmgruser , $ampmgrpass)) {
    $response = $astman->send_request('Command',array('Command'=>"mixmonitor stop $channel"));
    $astman->disconnect();
  }
}
// Remainder of current script

I have not asked around but code examination of app_mixmonitor.c for asterisk 1.2 does not raise hopes.

I think a cleaner AGI solution would be a direct substitute for StopMixMonitor? rather than bundling it into recordingcheck for example

exten => s,n,AGI(stopmixmonitor)

Alternatively leave it to the users to patch asterisk 1.2

Replying to Nick_Lewis:

I think a cleaner AGI solution would be a direct substitute for StopMixMonitor? rather than bundling it into recordingcheck for example exten => s,n,AGI(stopmixmonitor)

Nick, given the size of the population now on 1.4+ vs. 1.2, I'm not looking for a general solution to get access to the non-existent stopmixmonitor for 1.2. I prefer the idea of bundling it with the recordingcheck agi script because it avoids the overhead of firing off two agi scripts back-to-back when the single script can do it. And since this AGI script is in the call patch of virtually every call made on the system, sometimes being called more than once, it would seem much more efficient. Even if there were a need for a stopmixmonitor.agi script elsewhere, it would still make sense to bundle it with the recordingcheck agi script here for the above stated reason. Thoughts?

As far as your subsequent comment of patching Asterisk to fix the problem, that is an alternative. However, modifying the recordingcheck agi script is not a bad workaround to address the general populous?

I am easy. The point is probably moot. One disadvantage is a double condition check i.e. if BLINDTRANSFER in the dialplan plus if STOPMIXMONITOR in the agi. Perhaps recordingcheck could operate directly on BLINDTRANSFER?

I missed that, glanced too briefly at the code. I guess I would handle it by generating the dialplan a bit differently when it is 1.2, have a couple calls to recordingcheck with and with out it and change the targets. It's the more straight forward way then messing with that in the recordinghcheck script. This would be how to generate it on 1.2 systems:

[macro-record-enable]
include => macro-record-enable-custom
exten => s,1,GotoIf($["${BLINDTRANSFER}" = ""]?check
exten => s,n,ResetCDR(w)
exten => s,n,StopMixMonitor()
exten => s,n,AGI(recordingcheck,${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)},${UNIQUEID},STOPMIXMONITOR)
exten => s,n,MacroExit()
exten => s,n(check),AGI(recordingcheck,${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)},${UNIQUEID})
exten => s,n,MacroExit()
exten => s,1+998(record),MixMonitor(${MIXMON_DIR}${CALLFILENAME}.${MIXMON_FORMAT},,${MIXMON_POST})