[asterisk-bugs] [Asterisk 0014216]: Random audio dropouts when jitterbuffer = yes

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14216 
====================================================================== 
Reported By:                Andrey Sofronov
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   14216
Category:                   Channels/chan_iax2
Reproducibility:            random
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.22 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-01-12 10:02 CST
Last Modified:              2009-05-21 14:11 CDT
====================================================================== 
Summary:                    Random audio dropouts when jitterbuffer = yes
Description: 
Sometimes (couple times per month) I get one-way audio issue on IAX2
trunks.
iax.conf looks like:
[general]
autokill = yes

bindaddr = xx.xx.xx.xx
disallow = all

jitterbuffer = yes
maxjitterbuffer = 1000
trunktimestamps = yes
transfer = yes

[guest]
type = user
context = guest

[peer1]
type = user
allow = speex
auth = rsa
inkeys = ....
context = peer1_incoming

[peer2]
type = peer
username = tminsk_speex
host = xx.xx.xx.xx
allow = speex
trunk = yes
qualify = yes
auth = rsa
outkey = ....

When the issue occurs, the calling party can hear the remote party, but
the remote party hears silence. The only way that helps is "unload module
chan_iax2.so && load module chan_iax2.so". Also disabling jitterbuffer and
"iax2 reload" helps. 

http://bugs.digium.com/view.php?id=14044 - that patch doesn't help me
====================================================================== 

---------------------------------------------------------------------- 
 (0105253) svnbot (reporter) - 2009-05-21 14:11
 https://issues.asterisk.org/view.php?id=14216#c105253 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 195995

_U  trunk/
U   trunk/channels/chan_iax2.c

------------------------------------------------------------------------
r195995 | dvossel | 2009-05-21 14:11:50 -0500 (Thu, 21 May 2009) | 20
lines

Merged revisions 195991 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r195991 | dvossel | 2009-05-21 14:04:56 -0500 (Thu, 21 May 2009) | 14
lines
  
  Sign problem calculating timestamp for iax frame leads to no audio on
the receiving peer.
  
  There are rare cases in which a frame's delivery timestamp is slightly
less than the iax2_pvt's offset.  This causes the pvt's timestamp to be a
small negative number, but since the timestamp value is unsigned it looks
like a huge positive number.  This patch checks for this negative case and
sets the ms to zero.  A similar check is already done right below this one
in the 'else' statement.
  
  (closes issue https://issues.asterisk.org/view.php?id=15032)
  Reported by: guillecabeza
  Patches:
        chan_iax2.c.patch_timestamp uploaded by guillecabeza (license 380)
  Tested by: guillecabeza
  
  (closes issue https://issues.asterisk.org/view.php?id=14216)
  Reported by: Andrey Sofronov
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195995 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-21 14:11 svnbot         Checkin                                      
2009-05-21 14:11 svnbot         Note Added: 0105253                          
======================================================================