Great question—you’re exactly right that local networks work because devices can directly reach each other, but cross-network connections need STUN (and sometimes TURN) to traverse NATs. Let’s break down your questions clearly:

When does WebRTC call the STUN server? #

STUN isn’t triggered by an explicit API call you make—it’s handled automatically by WebRTC’s ICE framework, but only if you configure STUN servers when initializing your RTCPeerConnection. Here’s the timeline relative to your existing flow:

1. When you create the RTCPeerConnection with STUN servers (more on this below), the ICE agent is initialized with those servers.
2. After you call createOffer() and setLocalDescription(), the ICE agent starts gathering candidates.
3. For each network interface, the ICE agent will:
   • First collect host candidates (local IP addresses, which work on local networks).
   • Then automatically send a request to your configured STUN server to get a server-reflexive candidate (your public IP address and port, as seen from the internet).
4. These public candidates are then emitted via the onicecandidate event, just like your local candidates.

Without STUN configured, the ICE agent only collects local host candidates—so cross-network peers can’t reach each other.

What extra functions/configuration do you need? #

You don’t need to call any additional WebRTC APIs—you just need to pass a configuration object to RTCPeerConnection that includes STUN servers when you initialize it. Here’s how to adjust your first step:

Example: Initialize RTCPeerConnection with STUN #

// Define your ICE servers (use a public STUN server or your own)
const peerConfig = {
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' } // Google's public, free STUN server
  ]
};

// Create the peer connection with STUN enabled
const peerConnection = new RTCPeerConnection(peerConfig);

Bonus: Adding TURN for tricky NATs #

If you’re dealing with symmetric NATs (common in some corporate networks), STUN might not be enough. In that case, add a TURN server to your config—TURN acts as a relay for traffic when direct connections fail:

const peerConfig = {
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    {
      urls: 'turn:your-turn-server-address:3478',
      username: 'your-turn-username',
      credential: 'your-turn-password'
    }
  ]
};

Rest of your flow stays the same #

Once you’ve configured the RTCPeerConnection with STUN/TURN, the rest of your existing workflow (createOffer/setLocalDescription, send offer/ICE candidates, setRemoteDescription, createAnswer, etc.) works exactly as before. The only difference is that the onicecandidate event will now include public STUN candidates (and TURN relay candidates if configured), which enable cross-network connections.

内容的提问来源于stack exchange，提问作者porente