Issues with NAT/Routers

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

Table of Contents:

1. Behavior Classification
   1. Inspection and Modification of SIP/SDP Messages
   2. Wrong forwarding to internal address
   3. Immediate binding remapping of SIP address
2. Known Behavior of Some Router Brands
   1. Belkin Wireless ADSL Router

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 some STUN resolutions are 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

This is not wall of shame! :)

Belkin Wireless ADSL Router

Reported in:	UK
Reported by:	Benny Prijono
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 messages

When STUN is not used, the router modifies the (private) IP addresses/ports in Via and Contact headers of outgoing REGISTER request to the public address/port mapping of the SIP socket, and translates these addresses back to private IP addresses/ports in the REGISTER response. When STUN is used and public IP addresses are specified in Via/Contact? headers of REGISTER request, there don't seem to be any modifications done by the router.

Inspects and modifies SDP

The router modifies the (private) IP addresses in SDP c= line, and port number in SDP m= line. In addition, it also modifies the private IP address in a=rtcp attribute to the public IP address, but it doesn't modify the port number on this attribute (the port number stays private). It also replaces the private IP addresses of the ICE host candidate in ICE a=candidate attribute to the public IP address, but as with a=rtcp attribute, it doesn't modify the port number of the host candidate. This will make ICE offer/answer negotiation fails with ice-mismatch.

Interestingly, it doesn't seem to modify the private IP address in ICE host candidate when STUN is enabled. Perhaps the router has a heuristic to disable IP mangling when it sees the SDP contains parts with public IP address in it (which indicates that the client is NAT aware).

Below is the SDP as sent by client and as received by server, when STUN is not used:

v=0
o=- 3435482710 3435482710 IN IP4 192.168.0.15
s=pjmedia
c=IN IP4 192.168.0.15
t=0 0
a=X-nat:0
m=audio 3160 RTP/AVP 118 0 8 119 120 101
a=rtcp:3161 IN IP4 192.168.0.15
a=rtpmap:118 iLBC/8000
a=fmtp:118 mode=30
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:119 AMR/8000
a=rtpmap:120 AMR-WB/16000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ice-ufrag:4fdc3f4e
a=ice-pwd:03476f5f
a=candidate:H 1 UDP 39 192.168.0.15 3160 typ host
a=candidate:H 2 UDP 38 192.168.0.15 3161 typ host

v=0
o=- 3435482710 3435482710 IN IP4 81.178.58.134
s=pjmedia
c=IN IP4 81.178.58.134
t=0 0
a=X-nat:0
m=audio 3176 RTP/AVP 118 0 8 119 120 101
a=rtcp:3161 IN IP4 81.178.58.134
a=rtpmap:118 iLBC/8000
a=fmtp:118 mode=30
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:119 AMR/8000
a=rtpmap:120 AMR-WB/16000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ice-ufrag:4fdc3f4e
a=ice-pwd:03476f5f
a=candidate:H 1 UDP 39 81.178.58.134 3160 typ host
a=candidate:H 2 UDP 38 81.178.58.134 3161 typ host

And below is the SDPs as sent by client and as received by server when STUN is used:

v=0
o=- 3435482833 3435482833 IN IP4 81.178.58.134
s=pjmedia
c=IN IP4 81.178.58.134
t=0 0
a=X-nat:5
m=audio 3174 RTP/AVP 118 0 8 119 120 101
a=rtcp:3175 IN IP4 81.178.58.134
a=rtpmap:118 iLBC/8000
a=fmtp:118 mode=30
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:119 AMR/8000
a=rtpmap:120 AMR-WB/16000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ice-ufrag:7c334999
a=ice-pwd:32960288
a=candidate:S 1 UDP 31 81.178.58.134 3174 typ srflx raddr 192.168.0.15 rport 3174
a=candidate:H 1 UDP 23 192.168.0.15 3174 typ host
a=candidate:S 2 UDP 30 81.178.58.134 3175 typ srflx raddr 192.168.0.15 rport 3175
a=candidate:H 2 UDP 22 192.168.0.15 3175 typ host

v=0
o=- 3435482833 3435482833 IN IP4 81.178.58.134
s=pjmedia
c=IN IP4 81.178.58.134
t=0 0
a=X-nat:5
m=audio 3174 RTP/AVP 118 0 8 119 120 101
a=rtcp:3175 IN IP4 81.178.58.134
a=rtpmap:118 iLBC/8000
a=fmtp:118 mode=30
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:119 AMR/8000
a=rtpmap:120 AMR-WB/16000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ice-ufrag:7c334999
a=ice-pwd:32960288
a=candidate:S 1 UDP 31 81.178.58.134 3174 typ srflx raddr 192.168.0.15 rport 3174
a=candidate:H 1 UDP 23 192.168.0.15 3174 typ host
a=candidate:S 2 UDP 30 81.178.58.134 3175 typ srflx raddr 192.168.0.15 rport 3175
a=candidate:H 2 UDP 22 192.168.0.15 3175 typ host

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