The figure below illustrates the NAT problem faced by the SIP networks where the device
is located behind a NAT:
Figure 11-10: Device behind NAT and NAT Issues
11.8.1.1 Configuring STUN
Simple Traversal of UDP through NATs (STUN), based on RFC 3489 is a client / server
protocol that solves most of the NAT traversal problems. The STUN server operates in the
public Internet and the STUN clients are embedded in end-devices located behind NAT.
STUN is used for signaling and the media streams. STUN works with many existing NAT
types and does not require any special behavior.
STUN enables the device to discover the presence (and types) of NATs and firewalls
located between it and the public Internet. It provides the device with the capability to
determine the public IP address and port allocated to it by the NAT. This information is later
embedded in outgoing SIP / SDP messages and enables remote SIP user agents to reach
the device. It also discovers the binding lifetime of the NAT - the refresh rate necessary to
keep NAT ‘pinholes’ open.
On startup, the device sends a STUN Binding Request. The information received in the
STUN Binding Response (IP address:port) is used for SIP signaling. This information is
updated every user-defined period (NATBindingDefaultTimeout).
At the beginning of each call and if STUN is required (i.e., not an internal NAT call), the
media ports of the call are mapped. The call is delayed until the STUN Binding Response
(that includes a global IP:port) for each media (RTP, RTCP and T.38) is received.
Notes:
• STUN is applicable only to UDP connections (not TCP and TLS).
• STUN can’t be used when the device is located behind a symmetric NAT.
• Use either the STUN server IP address (STUNServerPrimaryIP) or
domain name (STUNServerDomainName) method, with priority to the
first one.
To Next Page
Loading...
Need help?
General
