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

[Rusty Newton (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223463#comment-223463 ] 

Rusty Newton commented on ASTERISK-24507:
-----------------------------------------

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.

> 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
>         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)