Consistent 5-Second Lag When Using WebRTC Endpoint

[ionizedatom]

Disclaimer: I used Gemini to help write this up but I made the code changes myself and confirmed that this fixed the issue consistently.

Description
Hey, I’ve been using the service on a corporate LAN and ran into a massive lag issue where the WebRTC endpoint takes exactly 5 seconds to load every single time. It’s a huge pain for real-time use cases (like our gate cameras) because users think the stream is broken. We dug into it and it’s definitely a timeout happening on the server-side during the WebRTC handshake. We found a way to patch it so it hits 44ms instead of 5000ms. Here is the breakdown of what’s happening and the couple lines of code we changed to fix it. We believe this specifically affects the WebRTC endpoint.

The Problem
On corporate LANs or restricted networks, the server hangs for exactly 5 seconds trying to contact default STUN servers (like Google’s). If the firewall drops these UDP requests, the server sits there waiting for a response that never comes until it hits a hardcoded timeout. Only after this 5-second timeout does it fall back to local IPs and finally respond to the client.

The Fix
We patched the adapter to prevent this forced wait. By allowing the server to proceed even if the ICE gathering isn't "complete" within a very short window, the stream starts almost instantly on a local network.

File modified: github.com/deepch/vdk/format/webrtcv3/adapter.go

1. Stop Forcing External STUN
   We removed the else block that forces stun.l.google.com when the configuration's ice_servers list is empty. This prevents the server from attempting external lookups when they aren't requested.

2. Implement a Gathering Timeout
   We replaced the blocking promise wait with a select statement and a tiny timeout.

From this:
Go
<-gatherCompletePromise
\

To this:
Go
select {
case <-gatherCompletePromise:
case <-time.After(500 * time.Millisecond):
}

Results
After implementing these changes, our latency dropped from a consistent 5.05s down to 0.044s (44ms). This makes the WebRTC implementation viable for real-time security and monitoring tasks where instant feedback is required.