wiki:NAT_Routers_Issues

Version 3 (modified by bennylp, 11 years ago) (diff)

--

Issues with NAT/Routers

Lets use this page to document peculiar things that NAT/routers do when it comes to processing SIP/STUN messages.

Behavior Classification

Inspection and Modification of SIP/SDP Messages

Some routers inspect and modify SIP/SDP message content in its naive attempt to assist NAT traversal. Parts of the SIP/SDP message elements that the router modifies include the Via and Contact header, and SDP c= and m= lines. Some router goes even further with doing what seems to be simple text search/replace operation, replacing all occurrences of private IP address/ports in SIP/SDP message with the public IP address/port.

This behavior may break ICE offer/answer negotiation. If the router replaces the default candidate with IP address/port which is not listed in the candidate list in SDP, remote callee will reject ICE offer with ice-mismatch, and ICE negotiation will not take place.

Wrong forwarding to internal address

Some routers are known to forward inbound UDP packet (from public interface) to wrong port number of the (internal) host. This could well be caused by multiple/simultaneous outgoing UDP packets confusing the NAT, causing it to forward the inbound response to the wrong port (not the port where the original outbound request was sent from).

One sample scenario happened when the client is resolving multiple UDP sockets with STUN simultaneously. Each of these socket sent STUN Binding request to the STUN server, and although the STUN server has responded to each request correctly, some of the sockets did not get the STUN Binding response since the NAT router forwarded the response to wrong port number of the host (not the port number where the original STUN request was sent from). This caused STUN resolution to fail for these sockets.

Immediate binding remapping of SIP address

The router immediately changes the public map of an internal SIP UDP address after STUN resolution is performed on other client sockets.

Scenario:

  1. SIP registration is done against the server, and this gets port number N.
  2. Some STUN resolutions are done on other UDP ports, e.g. for the RTP/RTCP sockets.
  3. Short moments later, when the client sends INVITE request to the server, the server will see the INVITE request coming from different port number than it previously saw (in one case, it's port number N+1).

Known Behavior of Some Router Brands

Belkin Wireless ADSL Router

Reported in: UK
Version: Firmware: 6.01.06 (Jun 7 2006 20:25:29), boot version: 0.70.2v6, hardware: 01
Base type: Full cone
Inspects and modifies SIP/SDP messages
This router inspects and modifies SIP/SDP messages if the outer address is UDP port 5060. It seems to do simple text search/replace against SIP/SDP message elements, replacing all occurrences of private IP address/port with the corresponding public/mapped IP address/port. It seems to recognize SIP and SDP message structure.

This behavior can be stopped by changing the destination/public server port to port number other than 5060, or by using TCP.