MixMonitor doesn't continue recording after transfer

Hello. We have a problem recording calls with MixMonitor after it’s been transferred, I’ll detail:

John (here in the office) calls a customer, they talk and John realizes the customer should speak with Carl (here in the office as well), so John puts the customer on hold, calls Carl and announces he’ll transfer a customer, then hits “transfer” and immediately the customer is talking fine with Carl, and John puts the earpiece back on hook because the call ended OK for him.

All the communication takes places perfectly. But the recording doesn’t.

We call MixMonitor before any call in our dialplan.
So, when John calls the customer, MixMonitor starts a file with the conversation.
When John puts the customer on hold, the recording continues, we can hear the customer’s side on the recording, for example.
When John dials Carl, MixMon starts another file, OK, where you can hear John saying “I’m trasnferring you a customer blah blah”, fine.
When John hits the TRANSFER button, all recording stops. The first file created with the customer, ends when John hits the button. And the second file between John and Carl, also stops.

Since the TRANSFER button in the phone (grandstream hard phones, if it helps) doesn’t make a call, there is not any part of the dialplan where I could even start another recording, which wouldn’t be the best solution (the best scenario would be if the first file, between John and customer, would continue with the audio between Carl and customer).

I googled and found the AUDIOHOOK_INHERIT func, but it didn’t help with this case.

Do you have any suggestions?

I’m using Asterisk 13.6


Based on the wiki documentation, starting from Asterisk 12.5+, all audiohooks are inherited without needing other controls expressing which audiohooks should be inherited under which conditions. so audiohook should be inherited to another channel.

I think you could use hangup handlers to follow the channel until the hangup, then an small script using sox to merge recordings

It wasn’t clear how you were doing the transfer, but I don’t think a SIP transfer is an inheritance situation because the PABX does not know that it is going to be a transfer when the channel is created; it is just a second line call from the same device.

The transfer is done like this:

John calls customer. John puts customer on hold using FLASH key. This gives him dial tone. He calls Carl. He hits TRANSFER key. Now customer is speaking with Carl.

Thanks. Surely that’s why I didn’t see any change when I implemented audiohook.

I know nothing about hangup handlers, I’ll look it up. If it’s not much trouble, can you give me an example of how you think I should use them? I don’t mean ready to use dialplan, but an explanation. Thanks!!

So this is a DAHDI analogue line?

It depends. We have a DAHDI digital MFCR2 line, some DAHDI POTS lines, and GSM gateways. Calls to cellphones go out thru gsm gateways. Most calls to landlines go out thru the digital line.

Do you think it matters?

In the office we all have IP hard phones, Grandstream.

Most people with transfer issues are using SIP phones.

As far as I know, Asterisk only has native support for incoming transfers on SIP and analogue DAHDI. For everything else, you need to use DTMF to request a transfer. Many people use DTMF, even with SIP. The outgoing channel type is less important.

For native SIP attended transfers, Asterisk has no idea it is dealing with a transfer when it creates the outgoing channel. For flash recall on analogue DAHDI, it should know, and the same is true for DTMF, although they may not be handled the same at the point where the channel is created. Even if it does know, it might not treat the channel as being created as from the channel with the audioihook.

Hangup handlers are subroutines attached to a channel that will execute when that channel hangs up.