Skip to content
Thirdlane

STUN/TURN Servers

When phones and softphones sit behind NAT (as almost all do on home and office networks), they do not know their own public address, and audio can fail to flow even though the call connects. Thirdlane solves this with the ICE (Interactive Connectivity Establishment) protocol, which combines STUN (Session Traversal Utilities for NAT - lets a client discover its public address) and TURN (Traversal Using Relays around NAT - relays media when a direct path is impossible). This is essential for WebRTC clients (Thirdlane Connect in the browser) and for remote endpoints.

This screen registers the STUN/TURN servers the platform advertises to clients. For background, see the Thirdlane blog posts on NAT, STUN, TURN, and ICE and how to build and configure a STUN and TURN server.

Starting with Thirdlane 10.0.1, a local STUN and TURN server is installed and configured automatically. You only need this screen when you want to add your own STUN/TURN servers - for example a geographically closer relay for remote users, or a hardened server for a large deployment.

Create/Edit ICE Server

“Creating a server” here does not install a STUN or TURN server - it simply makes an existing server available to the Thirdlane platform. You must run the actual STUN/TURN service yourself.

Name. A unique name for this server entry.

Server Type. Whether this entry is a STUN or a TURN server. A single physical server can provide both, but you add a separate entry for each role.

Server URL. The server address, for example myturn.mydomain.com.

Transport. The transport the server supports (for example UDP, TCP, or TLS).

Username. The username for TURN authentication (TURN relays require credentials; STUN does not).

Credential. The password/secret for TURN authentication.

Best practices

  • Because TURN relays media, it consumes server bandwidth and adds a little latency; STUN is preferred whenever a direct path can be found, with TURN as the fallback. Provide both so clients can negotiate the best route.
  • Place relays close to your users - a distant TURN server adds round-trip delay to relayed audio.
  • If remote users report one-way or no audio while calls otherwise connect, a missing or unreachable TURN server is the usual cause.