[Home]

Summary:ASTERISK-24507: MixMonitor transmit audio file corrupt after blind transfer
Reporter:Alex Barnes (abarnes)Labels:
Date Opened:2014-11-07 07:34:20.000-0600Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Applications/app_mixmonitor
Versions:11.12.0 13.0.1 Frequency of
Occurrence
Constant
Related
Issues:
Environment:CentOS release 6.6 (Final) FreePBX 2.11.0.41 or 12.0.13Attachments:( 0) asterisk_config.zip
( 1) ASTERISK-24507.log
( 2) Example_WAVs.zip
( 3) pcap.zip
Description:When using MixMonitor with the 'r' and 't' options set the resulting transmit audio file is corrupt / broken if a blind transfer using feature code takes place during the call.

The issue is that the transmit file is padded at the beginning with the time is takes for the blind transfer to complete (3rd party answers).  If you mix the receive and transmit files together you can hear that the audio is out of sync until AFTER the blind transfer is completed.  Once the transfer is complete the audio is back in sync.

h4. Steps to Reproduce
* Dial Party B from Party A
* Wait for a few seconds before answering
* Answer Party B
* Have a conversation to track audio sync
* Initiate blind transfer on Party B to Party C using feature code
* Wait for a few seconds before answering
* Answer Party C
* Have a conversation to track audio sync
* Hangup

h4. Example Results
|| ||Event Log||Receive Audio||Transmit Audio||
|Answer|14s|15s|30s|
|Speaker| |19s|35s|
|Xfr Start|37s|37s|50s|
|Xfr End|53s|52s|52s|
|Speaker| |58s|59s|

We can see that the time taken to complete the blind transfer is 16secs which if you add on the 14s it took for the first call leg to answer gives us the 30sec delay at the start of Transmit Audio.

Note that the times for the audio feeds are rough as taken when listening to the wav files.

{panel:title=Affects Version}
I've marked the affects version as 11.12.0 as that's the version running on my test box but we've been investigating this bug since March this year.
{panel}
Comments:By: Alex Barnes (abarnes) 2014-11-07 07:37:50.311-0600

Happy to attach some example WAV files but I don't suppose they will be of great use beyond proving that the bug exists :)

By: Rusty Newton (rnewton) 2014-11-07 16:44:54.830-0600

Thanks for the detailed report. Can you also attach [an Asterisk full log including debug type channels|https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information] during one of the demonstrated transfers.

For that same demonstration can you attach a correlating pcap?

By: Alex Barnes (abarnes) 2014-11-10 10:13:58.405-0600

Attached log, pcap and the associated WAV's.

Note that in this test audio starts at 17secs on in.wav but not until 31secs on out.wav.

This example is ISDN to VoIP then transfer to another VoIP extension.

I did another test using pure VoIP and the resulting recordings while still out of sync were NOT showing exactly the same issue as my original test and the one I just repeated.  The pure VoIP test was only out of sync by a matter of a second or so.

Let me know if you need any other logs or tests etc.

Thanks

By: Rusty Newton (rnewton) 2014-11-10 17:29:05.218-0600

Thanks for the additional debug Alex.

By: Rusty Newton (rnewton) 2014-11-10 17:32:19.655-0600

You know, you might as well go ahead and provide the dialplan and channel driver configuration for the extensions and endpoints/devices involved, just in case. Be sure to scrub any passwords or private info.

By: Rusty Newton (rnewton) 2014-11-10 17:37:51.613-0600

Another note... also curious if this happens in 13/Trunk or not..

By: Alex Barnes (abarnes) 2014-11-12 04:52:16.840-0600

Please see attached config files.

Unfortunately its FreePBX based so will be quite convoluted.

I'll try and test this with Asterisk 13 but as I've not tried installing this before it may take me some time.

Cheers

By: Alex Barnes (abarnes) 2014-12-01 06:58:20.907-0600

Hi,

We have repeated the test using Asterisk 13.0.1 and FreePBX 12.0.13 and the problem is still appearing.

Hope this helps.

Alex