Practice vocabulary for WebRTC troubleshooting: ICE failures, TURN relay, network congestion, codec negotiation, and WebRTC-internals debugging.
0 / 5 completed
1 / 5
When WebRTC cannot establish a direct peer-to-peer connection between two clients, the likely cause is:
The ICE connection fails — likely a firewall or NAT issue — symmetric NATs and strict firewalls block the UDP ports that WebRTC uses for direct P2P connections.
2 / 5
When direct peer-to-peer connection is blocked, WebRTC falls back to relaying traffic through a server. This server is called:
The TURN server relays traffic when P2P fails — TURN (Traversal Using Relays around NAT) is the fallback; it increases latency and costs more to operate.
3 / 5
When a WebRTC video call's resolution or frame rate decreases due to poor network conditions, this is described as:
The video quality drops due to network congestion — WebRTC's congestion control (GCC/REMB) dynamically adjusts bitrate based on available bandwidth.
4 / 5
When two WebRTC clients cannot agree on a common audio or video format during the offer/answer exchange, this is called:
The codec negotiation failed — during SDP negotiation, if no common codec is found (e.g., one side only supports VP8 and the other only H.264), the connection fails.
5 / 5
The built-in Chrome diagnostic tool that shows detailed WebRTC connection statistics, ICE candidates, and codec information is called:
We use WebRTC-internals to debug connection issues — accessible at chrome://webrtc-internals, it shows ICE state, DTLS state, codec details, and real-time stats graphs.