A free, simple, easy-to-implement, standards-based,
feature-rich dialtone for your SIP hardware or softphone...

Engineers Testing or Implementing Plug-N-Dial

NAT Traversal Policy

The biggest (and perhaps the only) problem SIP has today is NAT traversal The idea here is not to engineer for a specific type of NAT or engineer for specific or class of behavior of NATs but to simply to try as many alternative measures as possible automatically (not requiring end-user intervention) to try and traverse the NAT seemlessly rather than become in-operable.

All Plug-N-Dial devices must at minimum implement the following NAT traversal polcies:

Non Universal Plug and Play NATs (non UPNP)

(1) All SIP user agents behind a NAT/Firewall must implement NAT discovery through STUN -- Simple Traversal of User Datagram Protocol (UDP) as defined in RFC 3489

(2) STUN discovery process implemented must distiguish the following NAT types (including the NAT types defined in the STUN RFC) :

        (a) Full Cone NAT
        (b) Restricted Cone NAT
        (c) Port Restricted Cone NAT
        (d) Symmetric NAT
        (e) Open
        (f) Symmetric Firewall
        (g) Blocked (or could not reach STUN server)
        (h) Unknown


(3) The STUN implementation must identify NAT types described in IETF Internet draft http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-02.txt document (txt) for classifying NATs except the NAT type classified as "Bad" in this document which is optional and the test for which requires that SIP UAs use two ip addresses to run the STUN test.

        This IETF document describes four (4) groups of NATs based on what applications they can support: Group A, Group B, Group D and Group F.

(4) IP Address mapping for the Contact and Via headers and the SDP payload media ip addresses in SIP Signals -- that is all ip addresses that point to the sip user agent and orginate from the user agent must not be mapped using STUN queries for the following NAT types/Groups to faciliate the intervention of our RTP relays:

        (a) Symmetric NAT
        (b) Symmetric Firewall
        (c) Group F

        Note that In these cases the replies to SIP signals must be expected at the address and port the Signal was sent from. That is, responses to signals with private Via and/or Contact ip addresses will be returned to the ip address and port the signal originated from.

(5) Port mapping for the Contact and Via headers and the SDP payload media ip addresses must be carried for all NAT types.

(6) Group B and Group D NAT types must not use static SIP, RTP or RTCP ports and must bind to and announce random SIP ports per bootup/startup and random RTP/RTCP ports per session.

(7) If all attempts to communicate out side fail the client shall try to use the following port in order of preference for SIP, RTP or RTCP traffic should any of them are discovered (by nat / port discovery steps) as available for use:

        (1) port 21
        (2) port 20
        (3) port 22
        (4) port 443
        (5) port 80


(8) If client defaults to using UDP protocol for signalling and UDP communication fails the client shall switch to use TCP transport protocol to communicate. When using TCP transport protocol the UA must actively bind and ensure NAT port bindings are kept alive to guarantee asynchronous delivery of data.

(9) Requirements 7 and 8 shall be tried in combination to seemelessly traversae NAT/Firewalls.

(10) MTU: Sip signals may exceed the maximum MTU specied at an orignating interface depending on conditions. For example if the application/sdp payload is too large or if the contact field headers are numerous. These conditions must not cause the unit cease responding.

(11) Optionally implement ICE (Interactive Connectivity Establishment) protocol for traversing NATs. "ICE is not a new protocol, but rather makes use of existing protocols, such as Simple Traversal of UDP Through NAT (STUN), Traversal Using Relay NAT (TURN) and even Real Specific IP (RSIP)" (txt).