Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN), described in RFC 3489, enables SIP clients to discover the presence and types of NATs and firewalls that exist between them and the public Internet. In addition to providing a way for an application to traverse a NAT, the protocol provides for a connectivity check between a client and server separated by a NAT. It helps prevent NAT-associated network application failures by transmitting exploratory STUN messages, over UDP port 3478, between the server and clients.
STUN allows a client to not only determine its publicly addressable IP interface and port, but to set criteria for keeping those NAT bindings open. For example, a VoIP phone or software package may include a STUN client, which will send a request to a STUN server. The server then reports back to the STUN client with:
The public IP address of the NAT router.
The port opened by the NAT (for that client) to allow traffic back in to the network.
The ME Media Engine provides a STUN/TURN server integrated into the signaling and media proxy architecture. The TURN server provides support for straight UDP relays, as well as for TCP-to-UDP conversion. The ME supports both standard STUN (with binding discovery) and the newer version (with connectivity check usage).
As a STUN server, the ME receives STUN requests from clients and responds. (The STUN client uses DNS to find the ME/STUN server.) The ME identifies the public-side NAT details by inspecting exploratory messages from STUN-enabled clients, sent to determine which transmit and receive UDP port to use. The ME STUN server examines the incoming message and informs the client which public IP address and ports were used by the NAT. These are then used in the call establishment messages sent to the SIP destination server.
The client may also send a TURN allocate request. The ME finds an unused port on the relay-interface and sends a message back to the client with the port and IP address. The client then sends data to the ME, which forwards the data to its final destination, changing the packet to look like it originated from that port on the ME, which forwards return packets back to the client.
For complete information on STUN and TURN refer to:
The following discussion only applies to RFC 3489 (standard STUN). The updated STUN protocol (RFC 3489bis, as no RFC has yet been assigned to it) does not apply to this discussion. The discussion only applies if clients in your network are using advanced features of RFC 3489 STUN.
As a STUN server, the ME listens on configured interfaces for STUN client requests. When using STUN for Binding Discovery, the client sends a Binding Request packet to the STUN server, and the server responds with a Binding Response. This response indicates the IP address and port the packet seemed to originate from (which may be different from the address/port the client sent the packet from, if there is an intervening NAT device). This address is often known as the public address, or NAT mapping. The client can then use that public IP address when registering with the ME.
Some NAT implementations base their mappings not only on the client IP address and port, but also on the server IP address and port. A packet sent from the same client address/port to a different server (or even a different port on the same server) may be given a different NAT mapping by the NAT device. Any address information learned by doing Binding Discovery with the STUN server is unusable by other devices. To determine whether or not this is the case, a STUN Binding Request can request that the STUN response be sent from a different address (presumably a different interface on the same machine), different port, or both. For the same reason, when the server sends the Binding Response, it adds information indicating which address/port it would use if the client had asked for a response from a different address/port. The client can then use this information to send a new Binding Request to the alternate address/port.
For STUN to operate properly, follow these rules when configuring STUN servers:
Create STUN server instances in pairs
Put each instance of the pair on a different IP address
Assign exactly two UDP ports to each; the port number assignments must be identical for each
The secondary interface (configured in the stun-server object) of each instance must point at the IP address of the other instance
For example, with a STUN server configured on interface A, ports 100 and 200, configure an additional STUN server on interface B, ports 100 and 200. In the interface A configuration, set the secondary-interface property to B, and vice versa.
Configures the STUN and TURN server functionality on the ME.
config cluster box number interface ethX ip name stun-server config cluster box number interface ethX vlan number ip name stun-server config box interface ethX ip name stun-server config box interface ethX vlan number ip name stun-server
admin: Sets the administrative state of the STUN protocol, either enabled (running) or disabled.
Default: enabled
Values: enabled | disabled
Example: set admin disabled
port: Specifies the protocol and port number over which STUN messages are transmitted between a SIP client and the system STUN server.
In addition, you can specify whether to enable the TURN-redirector. When enabled for a port, TURN Allocate requests to that port may be redirected to another port on another box in the cluster (using the 300 Redirect error response). If no other systems in the cluster are configured to share TURN ports, or if the local machine is the best choice, the request is fulfilled locally. When the TURN-redirector is disabled, requests to this port are fulfilled locally or fail.
If using the TURN-redirector, you must set the cluster > share-turn-ports property to true to determine which systems have their TURN ports available as a target for redirection.
Default: UDP 3478 disabled Values: <UDP | TCP | TLS> portNumber <enabled | disabled>
Example: set port tcp 3478 enabled
certificate: Specifies the certificate used to connect to the STUN server over TLS. This is the certificate that the system presents to the client.
Default: There is no default setting
Example: set certificate vsp tls certificate my NetworkCert.pfx
stun-auth-level: Specifies the level of authentication to require from the client for STUN requests when the transport protocol used is not TLS. (Note that this setting does not apply to TURN requests, which always use long-term authentication.)
Default: allow
Values: ignore: The system does not require authentication from the client, and ignores any authentication presented. Even if the authentication is incorrect, when set to ignore, the system accepts the request.
allow: The system does not require authentication from the client, but if it is presented, verifies it. If the authentication is correct or there is none, the system accepts the request. If it is incorrect, the system refuses the request.
short-term: The system requires the client to use authentication that has short-term credentials. The client requests a shared secret from the system, via a TLS connection, which is given in the form of an automatically generated username and password. These credentials are used for a fixed time period of either nine minutes (when used outside the context of a TURN allocation), or for the lifetime of the allocation (when used inside the context of a TURN allocation).
Example: set stun-auth-level short-term
short-term-user-secret: Sets a private secret used to seed the random number generator for generated short-term credentials. This value does not need to be known by the client. If you do not configure this value, the system uses a fixed default value. If multiple systems use TURN servers cooperating in a cluster, they must all be configured with the same short-term-user-secret setting.
Default: There is no default setting
Example: set short-term-user-secret pswd1
secondary-interface: Specifies the interface to use when the CHANGE-REQUEST attribute requests a response from a different IP address. The interface you specify as the secondary interface must:
Have a STUN server configured,
Use the same port number assignments as the primary interface
Have a secondary-interface that points back to this interface.
See Understanding STUN Configuration for ”old-style STUN” configuration requirements.
Default: There is no default setting
Example: set secondary-interface ”cluster box 1 interface eth0 ip a”
allow-turn: Enables or disables TURN on the system STUN server.
Default: enabled
Values: enabled | disabled
Example: set allow-turn disabled
relay-interface: Specifies the interface over which the client receives public visibility; the interface from which the system allocates TURN relay ports.
Create a reference to a configured interface. The interface that you select must have media-ports enabled and a port pool range defined, but does not require a STUN server instance configured.
Default: There is no default setting
Example: set relay-interface ”cluster box 1 interface eth1 ip z”
allocation-lifetime-max: Specifies the maximum number of seconds that a TURN relay port allocation remains valid. Prior to expiration, the client must send a reallocation (renewal) request. The client can also send a request to immediately close the port.
Default: 3600
Values: Min: 1 / Max: 100000
Example: set allocation-lifetime-max 750
allocation-bandwidth-default: Specifies the amount of bandwidth allotted to a TURN relay port if the client did not request a specific amount.
Default: 150
Values: Min: 1 / Max: 1000000
Example: set max-udp-tunnel-inactivity 7200
ta: Sets the duration in milliseconds of the Active Destination state transition timer (as defined in draft-ietf-behave-turn-01.txt, section 8.3). This timer is used in cases when the client sets an active destination, so that all subsequent data received from the active peer is forwarded without STUN encapsulation to the client (and vice versa) and then later sets a different active destination. This property sets the amount of time, during the switch from old to new active destination, that forwarded traffic is encapsulated inside STUN Data Indications (to avoid confusion about the destination from which it came).
Leave this value set to the default unless you have pressing reason to change it.
Default: 3000
Values: Min: 0 / Max: 10000
Example: set max-proxy-transactions-per-vsp automatic