STUN for NAT Traversal and P2P Communication

Using STUN with Zenitel Devices in SIP mode - Tech Preview

What is STUN

STUN (Session Traversal Utilities for NAT) helps devices behind NAT (Network Address Translation) discover their public IP address and port, allowing direct peer-to-peer RTP (audio/video) between SIP endpoints.

What Happens

Once enabled, the device will communicate with the STUN server to discover its public IP. This address is included in SIP signaling (SDP), allowing peer-to-peer RTP media between endpoints when supported by the network and the SIP server’s media capabilities and configuration.

When should you enable STUN?

Enable STUN when:

• Your intercom devices are behind routers using NAT, and
• They register to a SIP server on the internet or in a data center, and
• You require direct media (P2P) between devices on different networks (for audio and/or video).

You usually do not need STUN when:

• All devices and the SIP server are on the same local network (no NAT between them), or
• If your SIP server is configured to relay media instead of using direct peer-to-peer RTP, STUN is typically not required for media connectivity.

Protocol Support

The feature is available as from version 9.4.3.1 as a tech preview and supports STUN over UDP. TCP or TLS-based STUN is not supported in this setup.

Configuration

System components

A typical solution includes:

1. Zenitel devices behind NAT (local network)
2. NAT router (internet gateway)
3. SIP server in the cloud
   

– e.g. Asterisk or Kamailio

1. STUN server in the cloud
   

– public STUN service or a STUN server you operate yourself

Configuring STUN on a Zenitel device

1. Log in to the Device web interface.
2. Device must be configured in SIP mode,
3. Go to the SIP/Account configuration page, and make sure that the SIP server address, username and password are correctly configured.
4. Locate the STUN settings. You should find:
   • Use STUN
   • Server Domain (STUN)
5. Configure:
   • Check Use STUN (Tech Preview) to enable the feature.
   • In Server Domain (STUN), enter the STUN server hostname or IP and port, e.g.:
     • stun.l.google.com:19302, or
     • stun.mycompany.com:3478
6. Save and apply the configuration.

STUN Settings

Notes and limitations

• STUN requires NAT behavior that allows peer-to-peer RTP.
• STUN is one of several NAT traversal mechanisms (alongside TURN and ICE). The current implementation covers STUN only.
• For devices behind the same NAT router, the router must support NAT hairpinning (loopback) in order for direct peer-to-peer RTP using public addresses to work.
• With Asterisk, STUN helps the device discover its public IP, but Asterisk must still be configured for SIP NAT awareness (for example contact rewriting) to ensure reliable registration and incoming calls.
• Asterisk does not support direct per-to-peer video media; video streams are anchored by Asterisk regardless of STUN configuration
• Direct video media may require SIP servers like Kamailio (as Asterisk doesn’t support direct media for video).
• NAT types
  • STUN alone works in certain NAT environments (like full-cone NAT), but does not support symmetric NAT or scenarios requiring ICE or TURN. Cloud SaaS platforms or enterprise environments that block peer-to-peer media are not supported.
  • Some consumer routers use port‑restricted or symmetric NAT, which can limit what STUN can achieve alone.
  • In such cases, you may need:
    • Additional router configuration (hairpin, endpoint‑independent NAT), or
    • A SIP server that relays media (RTP proxy/relay).
• Security and reliability considerations
  • When using NAT configurations that allow broad UDP mappings (such as full-cone NAT), appropriate firewall and security policies should be applied.
  • Public STUN servers are convenient for testing, but their availability and performance are outside Zenitel’s control. For production use, a privately managed STUN service is recommended.