The STUN Protocol and VoIP – Part 1

STUN stands for Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NAT’s). Typically it is used in several different network implementations and scenarios, one of which is in VoIP implementations. Because of the way protocols used in a SIP based VoIP call work, making calls between two SIP entities running behind NAT devices such as a router or firewall (common scenarios found in home and business networks), users typically encounter several problems, such as one way audio during a phone call or phone registration failures when trying to register to a VoIP provider or a IP PBX not residing on the same network. STUN is a protocol that helps in resolving problems in such VoIP implementations. Since v10 the 3CX Phone System acts like a STUN server on port 5060.

Purpose of the STUN Protocol

The main purpose of the STUN protocol is to enable a device running behind a NAT device to discover its public IP and what type of NAT is running on the gateway it is connected to. It also enables the device connected behind a gateway to discover the port translation done by the gateway itself (NAT); i.e. which port other devices can use to connect to it from outside the network. Note that gateways and routers do not always make port translations; it depends on the type of NAT they are running and how it is configured. E.g. a full cone NAT configuration does not translate ports.

STUN can also be used to refresh NAT bindings; as a keep-alive mechanism when using Restricted Cone NAT or Port Restricted cone NAT. When passing traffic through such NAT configurations, internal address and port are mapped to a specific external address and port. But if such address translation is not used after a particular amount of time (depending on the device’s configuration), such address mapping is dropped. Therefore when the internal device tries to connect again to an external entity (which could be the same entity previously it connected to) using the same internal IP and port, the router will still assign a different address mapping, i.e. a different IP and port from the previous assigned ones.

The STUN Protocol

STUN is a server-client protocol. A STUN server usually operates on both TCP and UDP and listens on port 3478. A client usually contacts the STUN server on a specific IP and port (3478) but the server can hint clients to perform tests on alternate IP address and port number too, as such port and IP are arbitrary.

STUN Request and Response Scenario

In the below diagram we can see how a typical STUN request and response works:

stun_voip1

  • Phase1: Computer A sends a STUN request through gateway 192.168.1.1 to STUN server outside the network, listening on 64.25.58.65 using source port 5060.
  • Phase2: The gateway (192.168.1.1) forwards the request to STUN server (64.25.58.65) and changes port 5060 to port 15060.
  • Phase3: The STUN Server (64.25.58.65) sends a response back to Computer A through the gateway with public IP 212.128.56.125 specifying that the request was received from IP 212.128.56.125 and port 15060

When computer A establishes a session, e.g. a SIP based VoIP call with an external entity; it can notify the external entity to send responses back to it on IP 212.128.56.125 and port 15060. As seen above, the STUN protocol plays a very important role in aiding two devices running behind a network gateway configured with NAT to establish a UDP connection.

STUN also has its cons; it does not work properly with networks using Symmetric NAT, because Symmetric NAT creates a new address and port mapping each time an internal host tries to connect to an external host, STUN is not a good solution for such a scenario. In our next article we will see a sample capture of STUN requests from VoIP devices and will explain how it helps in solving connection establishment problems in a VoIP environment.

More information about STUN

Liked this article?


Get notified of new articles
or share
You might also be interested in:
  1. Pingback: 3CX VOIP, SIP & Phone System blog » The STUN Protocol and VoIP – Part 2

  2. Pingback: 3CX VOIP, SIP & Phone System blog » The STUN Protocol Details

  3. Anonymous

    thank you, this is really helpful

    January 11, 2010 at 7:06 am