User`s manual

MediaPack
SIP User's Manual 248 Document #: LTRT-65408
The way SIP is designed creates a problem for VoIP traffic to pass through NAT. SIP uses
IP addresses and port numbers in its message body. The NAT server can’t modify SIP
messages and therefore, can’t change local to global addresses.
Two different streams traverse through NAT: signaling and media. A gateway (located
behind a NAT) that initiates a signaling path will have problems in receiving incoming
signaling responses (they will be blocked by the NAT). Furthermore, the initiating gateway
must notify the receiving gateway where to send the media to.
To solve these problems the following mechanisms are available:
 STUN (refer to Section 9.2.1).
 First Incoming Packet Mechanism (refer to Section 9.2.2 on page 249)
 RTP No-Op packets according to the avt-rtp-noop draft (refer to Section 9.2.3 on page
249).
 For SNMP NAT traversal, refer to Section 14.10 on page 322.
9.2.1 STUN
Simple Traversal of UDP through NATs (STUN) (according to 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 both for the signaling and the media streams. STUN works with many
existing NAT types, and does not require any special behavior from them.
STUN enables the gateway to discover the presence (and types) of NATs and firewalls
located between it and the public Internet. It provides the gateway 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 gateway. It also discovers the binding lifetime of the NAT (the refresh rate necessary to
keep NAT ‘Pinholes’ open).
On startup, the gateway 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 NATBindingDefaultTimeout.
At the beginning of each call, if STUN is needed (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.
To enable STUN:
 Set the parameter EnableSTUN to 1.
 Define the STUN server's address by performing one of the following:
• Define the STUN server's address by assigning it a domain name. The STUN
client can perform the required SRV query to resolve it to an IP address and port,
sort the server list, and use the servers according to the sorted list.
• Determine the IP address of the primary and (optionally) the secondary STUN
servers using the parameters STUNServerPrimaryIP and
STUNServerSecondaryIP. If the primary STUN server isn’t available, the gateway
tries to communicate with the secondary server.
 Use the parameter NATBindingDefaultTimeout to determine the default NAT binding
lifetime in seconds. STUN is used to refresh the binding information after this time
expires.
Notes:
• STUN only applies to UDP (doesn’t support TCP and TLS).
• STUN can’t be used when the gateway is located behind a
symmetric NAT.
• For defining the STUN server's address, either use the
stunServerPrimaryIpAddress or the StunServerDomainName
method, with priority to the first one.