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
