I am using the r() and t() options with MixMonitor to record the transmit and receiving channels separately and then mix them together in a stereo file using sox. All is going perfectly, but I had this single case where in an over than 2-minute call, the transmit and receiving party just swapped after 34 seconds. At first, I thought of a bug in the sox, but after listening to the separate transmit and receiving audio files, the swap was in that single files. By checking the Asterisk logs, nothing happened between when the channel was answered and hung up. I even recovered the pcap of both legs of the call, and nothing happened between the OK/ACK and BYE. Have you ever found a similar problem?
I am running Asterisk 18.22.0
After careful investigation, the “swap” problem happens only when more than one MixMonitor is hooked to the call. I used two MixMonitor, saving to the same recording file, one for each of the call legs to handle optional transfers. The problem was the first leg has r(receive.wav)t(transmit.wav) and the second leg has the same, but obviously what is received by one leg is what is transmitted by the other leg. If I invert the receive.wav and transmit.wav in the r() and t() option, the problem doesn’t happen. However, the big question is “Why does it happen ALWAYS at exactly 34 seconds?” I have tested it from asterisk 13.x to asterisk 18.x
I imagine that is related to the user space buffering in the stdio library. However, having two threads write to the same file, in this way, is never going to be a good thing.