Chapter 21: NAT firewall traversal
The objective of putting devices behind a Network Address Translator (NAT) is to protect the
devices from external interruption and to extend the public IP address space. However, the shield to
stop unsolicited incoming traffic also has the drawback of breaking a number of IP applications,
including SIP.
If a device is behind a NAT, transport addresses obtained are not publicly routable, and therefore,
not useful in a number of multimedia applications. The limited lifetime of the NAT port mapping can
also cause the SIP signaling to fail. If a port mapping is idle, it can be released by the NAT and
reassigned to other applications.
The STUN protocol lets an IP Deskphone discover the presence and type of NATs between the
IP Deskphone and the public Internet. In addition, an IP Deskphone can discover the mapping
between the private IP address and port number and the public IP address and port number.
Typically, a service provider operates a STUN server in the public Internet, with STUN-enabled
IP Deskphones embedded in end-devices, which are possibly behind a NAT.
A STUN server can be located using DNS SRV records using the domain of the service provider as
the lookup. STUN typically uses the well-known port number 3478. STUN is a binary encoded
protocol with a 20-octet header field and possibly additional attributes. The STUN protocol learns
the public IP addresses, and therefore, some security is necessary.
To initiate a STUN lookup, the IP Deskphone sends one or more Binding Request packets using
UDP to the STUN server. These packets must be sent from the same IP address that the
IP Deskphone uses for the other protocol, because this is the address translation information that
the IP Deskphone tries to discover.
The server returns Binding Response packets, which tell the IP Deskphone the public IP address
and port number from which it received the Binding Request. The IP Deskphone knows the private
IP address and port number it used to send the Binding Request, and therefore, it learns the
mapping between the private and public address space being performed by the NAT. If the Binding
Response packets indicate the same address and port number as the request, the IP Deskphone
knows no NATs are present.
The IP Deskphone supports two methods for NAT traversal of the signaling path:
• SIP_PING
• STUN
The NAT traversal method can be selected manually through the Device Settings menu or
configured through the device configuration file. The default NAT traversal method is NONE.
The IP Deskphone can conduct SIP dialogs through a Symmetric NAT using UDP. This allows the
IP Deskphone to work from behind and/or in front of a symmetrical NAT with servers and/or clients
that support RFC3581. For this feature to work properly, the receiving end device must support
March 2015 SIP Software for Avaya 1200 Series IP Deskphones-Administration 223
Comments? infodev@avaya.com
To Next Page
Loading...
