Thanks — I understand you can send audio (server shows transcripts and RMS) but can’t hear others when on VPN + slow Wi‑Fi. That’s consistent with one-way audio caused by network/VPN issues. A few quick checks and steps to narrow/fix it: 1) Quick checks • Can you temporarily disable the VPN and test? If audio returns, the VPN is the cause. • Try a different network (cell hotspot) to confirm it’s Wi‑Fi related. • Make sure the remote audio

<audio>

element isn’t muted and autoplay isn’t blocked by the browser. 2) Run connection diagnostics • Run LiveKit’s ConnectionCheck:

checkWebRTC()

and

checkTURN()

. Share results if you can. If TURN fails or WebRTC fails, VPN/firewall is blocking required traffic. 3) Inspect WebRTC stats (or send them) • Look at

packetsReceived

,

packetsLost

,

jitter

, and codec decode status in chrome://webrtc-internals or SDK stats. High incoming packet loss/jitter or decoder inactivity points to downstream issues. 4) Likely causes and fixes • VPN blocking or throttling UDP: switch VPN protocol (WireGuard vs OpenVPN) or disable VPN. UDP blocking often breaks inbound media. • TURN relay congestion or blocked: ensure TURN is reachable and working; switching to a nearer LiveKit region can help. • Downstream bandwidth/jitter: try lower bitrate or enable adaptive streaming so LiveKit reduces quality to keep audio flowing. 5) If you can, gather and share • Results from ConnectionCheck (webrtc + turn). • Relevant SDK logs or browser webrtc-internals snapshot. • Which client (browser/mobile), OS, VPN provider, and whether audio element is attached on subscribe. If you prefer, tell me which checks you’ve already run and the client/OS/VPN — I’ll suggest the exact commands and what to look for. Sources: Diagnosing Connection Errors with Connection Test Utility | Bringing Zoom's end-to-end optimizations to WebRTC | Bringing Zoom's end-to-end optimizations to WebRTC