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

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:                     feedback
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:              06-20-2008 15:21 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".
====================================================================== 

---------------------------------------------------------------------- 
 jolan - 06-20-08 15:21  
---------------------------------------------------------------------- 
The patch in http://bugs.digium.com/view.php?id=12679 lowers the reproducibility
rate but I think it's
incomplete.

And yes, I know that the RFC recommends a random initial value.

I can reproduce this across the 2.0.x, 2.2.x, and 3.x Polycom firmware
branches with every model I tried (300, 301, 500, 501, 601).

I've tried other patches from the bug tracker in addition to my own.  I
can confirm it definitely isn't a NAT issue or else this probably would
have fixed it:

   if (p->rtp) {                                                          
     
      if (portno > 0) {                                                   
     
         sin.sin_port = htons(portno);                                    
     
+        if (ast_test_flag(&p->flags[0], SIP_NAT)) {                      
     
+           if (debug)                                                    
     
+              ast_verbose("NAT active; using %s instea                   
     
d of %s\n", ast_inet_ntoa(p->recv.sin_addr), ast_inet_ntoa(sin.sin_addr));
     
+           sin.sin_addr = p->recv.sin_addr;                              
     
+        }                                                                
     
         ast_rtp_set_peer(p->rtp, &sin);                                  
     
         if (debug)                                                       
     
            ast_verbose("Peer audio RTP is at port %s:%d\n",              
     
 ast_inet_ntoa(sin.sin_addr), ntohs(sin.sin_port));

But nothing has solved the issue 100% other than the workaround patch I
already posted:

Index: rtp.c
===================================================================
--- rtp.c	(revision 120859)
+++ rtp.c	(working copy)
@@ -2663,8 +2663,10 @@
     if (rtp->lastts > rtp->lastdigitts)
         rtp->lastdigitts = rtp->lastts;
 
+	/* XXX polycoms can't cope with high timestamps on the initial packet
     if (ast_test_flag(f, AST_FRFLAG_HAS_TIMING_INFO))
         rtp->lastts = f->ts * 8;
+	*/

I don't know what else I need to do to prove that this is a real problem. 
You don't have a polycom phone to try to reproduce?  This is still a
problem for me with stock 1.4.21. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-20-08 15:21  jolan          Note Added: 0089031                          
======================================================================