[asterisk-bugs] [JIRA] (ASTERISK-24507) MixMonitor transmit audio file corrupt after blind transfer

[Alex Barnes (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Barnes updated ASTERISK-24507:
-----------------------------------

    Attachment: pcap.zip
                Example_WAVs.zip
                ASTERISK-24507.log

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

> MixMonitor transmit audio file corrupt after blind transfer
> -----------------------------------------------------------
>
>                 Key: ASTERISK-24507
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24507
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_mixmonitor
>    Affects Versions: 11.12.0
>         Environment: CentOS release 6.6 (Final)
> FreePBX 2.11.0.41
>            Reporter: Alex Barnes
>            Assignee: Alex Barnes
>         Attachments: ASTERISK-24507.log, Example_WAVs.zip, pcap.zip
>
>
> 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}



--
This message was sent by Atlassian JIRA
(v6.2#6252)