[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:
-----------------------------------

    Description: 
When using MixMonitor with the 'r' and 't' options set the resulting transmit audio file is corrupt / broken if a blind transfer 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
* 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 Receive Audio.

Note that the times for the audio feeds are rough as taken when listening to the 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}

  was:
When using MixMonitor with the 'r' and 't' options set the resulting transmit audio file is corrupt / broken if a blind transfer 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
* 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 Receive Audio.

Note that the times for the audio feeds are rough as taken when listening to the 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}


> 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
>
> When using MixMonitor with the 'r' and 't' options set the resulting transmit audio file is corrupt / broken if a blind transfer 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
> * 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 Receive Audio.
> Note that the times for the audio feeds are rough as taken when listening to the 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)