[asterisk-dev] Asterisk 13 - Mixmonitor & Attended transfer
Joshua Colp
jcolp at digium.com
Mon May 9 09:10:35 CDT 2016
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
More information about the asterisk-dev
mailing list