[asterisk-bugs] [Asterisk 0012670]: some RTP packets sent to NAT IP instead of public IP; breaks built-in jitterbuffer on some phones

noreply at bugs.digium.com noreply at bugs.digium.com
Fri May 16 16:52:56 CDT 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12670 
====================================================================== 
Reported By:                jolan
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12670
Category:                   Core/RTP
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.19-rc3 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-16-2008 15:55 CDT
Last Modified:              05-16-2008 16:52 CDT
====================================================================== 
Summary:                    some RTP packets sent to NAT IP instead of public
IP; breaks built-in jitterbuffer on some phones
Description: 
I am experiencing the same symptoms as
http://bugs.digium.com/view.php?id=0012566 but with 1.4.20-rc3, not
trunk.  The bug was fixed in trunk, but not in 1.4.x.

To reiterate the problem:

Phone 100 calls phone 102.  Phone 102 answers and starts counting "1 2 3 4
5".  Phone 100 doesn't hear anything until "3" or "4".
====================================================================== 

---------------------------------------------------------------------- 
 file - 05-16-08 16:52  
---------------------------------------------------------------------- 
12566 had nothing to do with NAT, it was an internal locking issue on the
Asterisk channel itself.

There's nothing that we can do to solve what you are seeing. Until the
other side sends us audio we have NO idea they are behind NAT. The best we
can do is send audio to where they told us until then. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-16-08 16:52  file           Note Added: 0086965                          
======================================================================




More information about the asterisk-bugs mailing list