[asterisk-bugs] [Asterisk 0014546]: [patch] Patch to improve NAT handling for Polycoms behind proxy

Asterisk Bug Tracker noreply at bugs.digium.com
Fri Mar 27 08:15:28 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14546 
====================================================================== 
Reported By:                acunningham
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   14546
Category:                   Core/RTP
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     closed
Asterisk Version:           1.6.0.6 
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-02-24 19:42 CST
Last Modified:              2009-03-27 08:15 CDT
====================================================================== 
Summary:                    [patch] Patch to improve NAT handling for Polycoms
behind proxy
Description: 
Attached will be very similar patches to 1.4.21.1 and 1.6.0.6 to prevent
one-way audio in the following scenario:

1. A Polycom is behind NAT.

2. The Polycom registers to a SIP proxy outside NAT, such as OpenSIPS.

3. Asterisk calls the Polycom via the proxy. The sip.conf entry for the
proxy has net=yes set.

4. The Polycom is slow to start sending RTP.

5. Asterisk starts sending RTP to the port in the SDP.

6. The Polycom then starts sending RTP. The NAT device changes the RTP
source port.

7. Because the proxy isn't behind NAT, Asterisk fails to recognize that
the Polycom is behind NAT, and doesn't change the RTP destination to the
port it's receiving RTP from on the NAT device. This leads to one-way audio
for the duration of the call.

The patch cures this by always changing the RTP destination port based on
what's received from the client, even if Asterisk doesn't think the client
is behind NAT. This is safe to do for non-NAT clients as the change of port
will not happen. The patch has been tested with both NAT and non-NAT
phones.
====================================================================== 

---------------------------------------------------------------------- 
 (0102289) svnbot (reporter) - 2009-03-27 08:15
 http://bugs.digium.com/view.php?id=14546#c102289 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 184566

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r184566 | file | 2009-03-27 08:15:27 -0500 (Fri, 27 Mar 2009) | 16 lines

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

........
  r184565 | file | 2009-03-27 10:06:45 -0300 (Fri, 27 Mar 2009) | 9 lines
  
  Fix an issue where nat=yes would not always take effect for the RTP
session on outgoing calls.
  
  If calls were placed using an IP address or hostname the global nat
setting was copied over
  but was not set on the RTP session itself. This caused the RTP stack to
not perform symmetric RTP
  actions.
  
  (closes issue http://bugs.digium.com/view.php?id=14546)
  Reported by: acunningham
........

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-27 08:15 svnbot         Checkin                                      
2009-03-27 08:15 svnbot         Note Added: 0102289                          
======================================================================




More information about the asterisk-bugs mailing list