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

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Jun 11 09:58:52 CDT 2009


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:                     assigned
Asterisk Version:           1.4.22 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-01-12 10:02 CST
Last Modified:              2009-06-11 09:58 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
====================================================================== 

---------------------------------------------------------------------- 
 (0106307) dvossel (administrator) - 2009-06-11 09:58
 https://issues.asterisk.org/view.php?id=14216#c106307 
---------------------------------------------------------------------- 
I'll continue to look into this.  This is kind of puzzling.  Your first
debug output before I closed the issue contained elements that pointed
directly to a negative timestamp (timestamps are unsigned, so a negative
time stamp just looks like a huge positive one) causing the issue.

Example: Timestamp: 19450601ms SCall: 12341 DCall: 09994
[10.xx.xx.xx:4569]

The timestamp should never be that big, especially at the beginning of a
call.  The patch I committed seems to have fixed that as I don't see any
evidence of this in the new output you provided. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-11 09:58 dvossel        Note Added: 0106307                          
======================================================================




More information about the asterisk-bugs mailing list