[asterisk-bugs] [Asterisk 0015105]: [patch] Random loss of sound when using G.729

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15105 
====================================================================== 
Reported By:                bamby
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15105
Category:                   Core/RTP
Reproducibility:            random
Severity:                   major
Priority:                   normal
Status:                     new
Target Version:             1.4.25
Asterisk Version:           1.4.24 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-05-14 02:32 CDT
Last Modified:              2009-05-15 06:56 CDT
====================================================================== 
Summary:                    [patch] Random loss of sound when using G.729
Description: 
I'v faced strange problem recently and have at least two confirmations for
it using Asterisk 1.4.21 and 1.4.24.1. 

Here is a scenario that helped to discover the problem:

The asterisk has no G.729 codec installed but all calls are made using
G.729 and UAs participating in the scenario use VAD. 

Initial call is placed to the Asterisk from the first UA. Asterisk plays
several prompts and then places a call to another UA. After some time the
calling UA sends DTMF to forcibly disconnect second call leg. Asterisk
successfully disconnects the call leg and tries to play some more prompts.
The problem appears during last step. With some probability the RTP stream
completely stops in direction from the Asterisk to the first UA for the
rest of the session, and lots of messages:

   "Dropping extra frame of G.729 since we already have a VAD frame at the
end"

are printed on the console.

After examination of the source code I've found the line that I believe
contains a typo. The ast_smoother_read() function checks the 'size' member
of the ast_smoother structure to find out if the VAD frame is in the
buffer. But the 'size' contains the buffer size (and so always has size %
10 == 0), and the length of the data in buffer is kept in the 'len'
attribute. So if data containing in the buffer does not exceed the 'size'
then the check in the ast_smoother_read() guarantees the NULL value to be
returned regardless of buffer content.

On the other hand if the buffer contains a VAD frame then the
smoother_frame_feed() function does not accept any data until the buffer is
flushed.

So here we have a deadlock. To resolve the problem the check in the
ast_smoother_read() has to use the 'len' instead the 'size'. I've applied
this change to my Asterisk and since then no loss of the sound has been
occurring.

I'm attaching my patch.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-15 06:56 lmadsen        Target Version            => 1.4.25          
======================================================================