[asterisk-dev] Asterisk 13 - Mixmonitor & Attended transfer

Mon May 9 10:32:18 CDT 2016

Hello Joshua,

Thank you for your response. 
I am not trying to record a call in a single file. 
My goal is to create different files, each for the corresponding part of the
call.
It is my belief that in each leg of the call a check should be carried out
if the parties participating would like the call recorded or not,
using some criteria like recording priority implemented in freepbx. The
means or criteria is not important.

However, right now, after an attended transfer there is no way of
re-checking if any of the participating parties wants 
the call recorded and this is what I am bringing up here.

Take for instance the following dialplan already published in asterisk bug
tracker - issue 25674: 
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);
           }
}

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.
-------------

In this dialplan the aim is to record all parts of the conversation
including the part between 555-12345 and 105. This is not happening because
mixmonitor is started on the caller's channel. Furthermore there is no way -
at least I am not aware of any - to recheck if 555-12345 or 105 want the
call 
recorded after the attended transfer and in my opinion this is a major
feature missing now.

I am now getting around this by starting - without any check - a mixmonitor
session on the called party channel using the U option on the dial
application.
As I mentioned before this approach has a significant drawback. In all calls
without a transfer the conversation is recorded twice:
a. mixmonitor is initiated before the dial command from the caller
b. mixmonitor is initiated after the dial command on the called channel

I know that hard disk size is not an issue nowdays but this is not an
elegant approach because the second drawback is that a call is recorded
without actually
checking if any of the parties want their conversation recorded.

I know that what I am asking is some sort of a new feature, however I think
that it is a very important feature that is now missing from asterisk.
I am not expert in coding, however I think that one way to handle this
(possibly not the most optimal or elegant) 
is to send the calls in some sort of context (i.e. TRANSFER_CONTEXT), after
an attended or a blind transfer to check if the next conversation leg should
be recorded or not. 

My post here aims to bring this matter to your attention and discuss ways
for proper an implementation.

Best regards,

Ioannis

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Joshua Colp
Sent: Monday, May 09, 2016 5:11 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Asterisk 13 - Mixmonitor & Attended transfer

Ioannis Kampolis wrote:
> Hello,
>
> This issue has been discussed in bug tracker before in the following
issues:
>
> https://issues.asterisk.org/jira/browse/ASTERISK-25674
>
> https://issues.asterisk.org/jira/browse/ASTERISK-25801
>
> To summarize quickly extension A calls extension B and the call is
recorded.
> Extension A puts the call (with extension B) on hold and dials 
> extension C and the call is also recorded.
> Then extension A performs an attended transfer and the call between B 
> and C is not recorded.
>
> It seems that mixmonitor is started on the caller's channel and that's 
> why the 3rd leg of the conversation is not recorded.
> Even though the operation is according to the design I am sure that it 
> is not what most pbx users want.

I think ultimately there are groups of people who want both behaviors, which
makes things complicated.

>
> This can be fixed if mixmonitor is also started on the called channel, 
> too, recording the entire conversation (A+B & B+C).
> However this would require twice the hard disk size for simple (not 
> transferred conversations).

Ah - do you have a conversation before on A that is also to be recorded? 
If so, then yes, I understand.

>
> Do you have any good ideas on how to get the same results (all legs of 
> the conversations recorded) without the extra HDD space?

Not really I'm afraid - not without trying to implement some sort of feature
to do it. You could post-process things to make one file which follows the
concept of a call.

> Now I am using a pre-bridge handler on Dial command (U option) to 
> start mixmonitor on the called party's channel as well, however I am 
> not happy with the entire result.
> Is it possible to pass all attended transfers (using feature code or 
> SIP
> transfer) through the TRANSFER_CONTEXT that will make the checks? I 
> have not been able to do so.

No, for SIP an attended transfer is not known to be an attended transfer
until it is actually completed. Before that it is just a normal call.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at:
www.digium.com & www.asterisk.org

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus