[Home]

Summary:ASTERISK-13645: [patch] Patch to improve NAT handling for Polycoms behind proxy
Reporter:Alistair Cunningham (acunningham)Labels:
Date Opened:2009-02-24 19:42:53.000-0600Date Closed:2009-03-27 08:28:44
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) rtp_1.4.diff
( 1) rtp_1.6.diff
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.
Comments:By: Alistair Cunningham (acunningham) 2009-02-24 19:45:51.000-0600

s/net=yes/nat=yes/ in the description.
By: Joshua C. Colp (jcolp) 2009-03-11 12:47:00

Can you please attach the configuration and console output? I'm trying to reproduce this to see why the nat value is getting set to 0 to begin with but can't make it happen.
By: Alistair Cunningham (acunningham) 2009-03-11 20:20:00

I'm afraid this was tested on a production system, and the customer isn't going to be willing to revert to a configuration that breaks their Polycoms. I do have wireshark traces from before the patch. These contain confidential information so I won't attach them to the ticket, but if you can please let me know an email address I can send them to you.

Basically the problem is that OpenSER is making the source IP address seem to Asterisk to be the OpenSER address rather than the Polycom address. Since the OpenSER is outside NAT, Asterisk thinks that it doesn't need to do NAT handling on this call.


By: Joshua C. Colp (jcolp) 2009-03-12 08:44:30

Those won't help, I need to see exactly what chan_sip is doing. I've looked over the code and the only time the nat setting for RTP is changed is when the call is initially setup and the nat value from sip.conf is used to set the value. The only time then that rtp->nat would be unset is if it was not set in sip.conf on the peer entry. I've even confirmed this with my stuff here, I'm using stuff locally on a LAN with nat=yes and it most certainly is still doing symmetric RTP.
By: Alistair Cunningham (acunningham) 2009-03-12 18:51:51

I will ask the customer.
By: Leif Madsen (lmadsen) 2009-03-23 12:32:13

acunningham: ping? any luck?
By: Alistair Cunningham (acunningham) 2009-03-23 17:46:22

The customer is not willing to revert a production system to a state that they know to be broken when the system is now working perfectly, so we're not going to be able to get a trace them. I'm trying to get a trace from other sources. Please leave this open for now.
By: Alistair Cunningham (acunningham) 2009-03-25 18:52:07

I now have an Asterisk console trace with "sip debug" and a wireshark .pcap file on the Asterisk from another customer who was suffering the same problem with Aastra phones. Again, the patch fixed the problem for them and has not affected other phones.

The trace and .pcap file contain private information. The .pcap file is also rather large (5MB zipped) as they didn't run any filters when taking it. Is there an email address at Digium I can send it to to avoid making it public? I have permission from the customer to send the file to Digium but not to make it visible to the world.
By: Leif Madsen (lmadsen) 2009-03-26 07:26:47

I suggest you send it to "file -at- digium -dot- com"
By: Alistair Cunningham (acunningham) 2009-03-26 07:36:41

Thank you, will do.
By: Alistair Cunningham (acunningham) 2009-03-26 07:58:55

Email on the way...
By: Joshua C. Colp (jcolp) 2009-03-26 14:26:03

As I said in a reply email - are you dialing to an IP address and not the peer entry? It looks like nat=yes isn't respected for RTP in that scenario, which is the underlying bug.
By: Emmanuel BUU (neutrino88) 2009-03-26 15:28:33

Hello,

I reviewed the submitted patch. While I find it useful (as we are using the same kind of setup), there is some security issue here where an attacker could interfere (and maybe intercept) the communication by sending some RTP packet to the Asterisk and forcing it to replay back to ITS IP address even for no NAT

I am puzzled because we should have met this issue and we did not.
By: Alistair Cunningham (acunningham) 2009-03-26 17:50:35

Yes, we are dialling by IP address. Shouldn't the nat=yes in [general] take effect in this case?
By: Digium Subversion (svnbot) 2009-03-27 08:06:46

Repository: asterisk
Revision: 184565

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r184565 | file | 2009-03-27 08:06:46 -0500 (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 ASTERISK-13645)
Reported by: acunningham

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

http://svn.digium.com/view/asterisk?view=rev&revision=184565
By: Digium Subversion (svnbot) 2009-03-27 08:15:28

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 ASTERISK-13645)
 Reported by: acunningham
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=184566
By: Digium Subversion (svnbot) 2009-03-27 08:20:11

Repository: asterisk
Revision: 184580

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r184580 | file | 2009-03-27 08:20:11 -0500 (Fri, 27 Mar 2009) | 23 lines

Merged revisions 184566 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r184566 | file | 2009-03-27 10:15:26 -0300 (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 ASTERISK-13645)
   Reported by: acunningham
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=184580
By: Digium Subversion (svnbot) 2009-03-27 08:22:34

Repository: asterisk
Revision: 184587

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r184587 | file | 2009-03-27 08:22:34 -0500 (Fri, 27 Mar 2009) | 23 lines

Merged revisions 184566 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r184566 | file | 2009-03-27 10:15:26 -0300 (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 ASTERISK-13645)
   Reported by: acunningham
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=184587
By: Digium Subversion (svnbot) 2009-03-27 08:28:43

Repository: asterisk
Revision: 184612

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r184612 | file | 2009-03-27 08:28:43 -0500 (Fri, 27 Mar 2009) | 23 lines

Merged revisions 184566 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r184566 | file | 2009-03-27 10:15:26 -0300 (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 ASTERISK-13645)
   Reported by: acunningham
 ........
................

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

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