WebRTC + STUN/TURN in LiveKit

1. LiveKit is an SFU — not peer-to-peer

Participants don't connect to each other. Every participant — the user and the tm-agent — opens one WebRTC connection to the LiveKit server (the SFU), which forwards a copy of each track to everyone else.

P2P mesh: every pair connected → explodes with participants, kills client bandwidth.
SFU: client ↔ server only; the server fans media out.
So the SFU is the "middleman" between participants — STUNner is not.

"LiveKit is an opinionated, horizontally-scaling WebRTC Selective Forwarding Unit… a publisher sends media to the server, and the server forwards a copy of each track to each interested subscriber."— LiveKit docs, SFU internals

2. ICE, STUN & TURN — crossing NAT

Each client→SFU leg is a WebRTC connection that must punch through NAT. WebRTC uses ICE to find a working path by gathering candidates:

host — your local IP (same LAN only)
srflx — your public NAT address, discovered via STUN ("what's my public IP?")
relay — media relayed through a TURN server when no direct path works (always works, one extra hop)

STUN = discover address. TURN = relay the media. Both exist purely to traverse NAT — like your teammate said, "macam NAT."

LiveKit "will attempt to use STUN to discover the true IP… if a direct path can't be found, TURN relays the media."— LiveKit docs, Ports & firewall

3. Why STUNner — SFU behind a load balancer

The SFU runs as a pod on a private IP, behind a load balancer — a browser can't reach a pod IP directly (exactly your lead's point: "livekit server lives behind load balancer").

STUNner is a Kubernetes-native TURN server. LiveKit advertises it as its TURN server, so clients relay media through STUNner → (UDPRoute) → the SFU pods.
It replaces the hostNetwork anti-pattern (exposing media ports on the node).
The tm-agent reaches the SFU directly in-cluster — so the agent's media never touches STUNner.

"LiveKit itself will not use STUNner… we are just telling LiveKit to instruct its clients to use STUNner to reach the LiveKit media servers."— STUNner docs, LiveKit example

On CAE: STUNner's 3478 is exposed internally only — all WebRTC clients are on the VPN, so no public IP needed.

4. Two doors into the same room

Different participant types join the same SFU room via different paths — this is why both a TURN server and a SIP service exist:

WebRTC user (browser / BTW / LiveKit Meet) → STUNner (TURN 3478) → SFU. Needs STUN/TURN.
SIP Nubitel (phone) → LiveKit SIP service (5060, on the VM) → SFU. SIP protocol, not WebRTC → no STUNner. (delayed on CAE)
The tm-agent joins the room directly in-cluster — no STUNner, no SIP.

"This has nothing to do with Nubitel. STUNner is for LiveKit participants using WebRTC… Nubitel joins LiveKit as a SIP participant, not WebRTC."— the design clarification, in plain terms