Practice vocabulary for WebRTC troubleshooting: ICE failures, TURN relay, network congestion, codec negotiation, and WebRTC-internals debugging.
0 / 10 completed
1 / 10
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 / 10
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 / 10
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 / 10
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 / 10
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.
6 / 10
Code Review Comment: Sarah flagged a comment in the PR describing a connection issue during a test call. She wrote: 'Seems like ICE candidates aren't resolving quickly – could be related to high latency on user's network. Check chrome://net-internals/#media-candidates for details.' What does Sarah likely mean by 'ICE candidates aren't resolving quickly'?
ICE (Interactive Connectivity Establishment) candidates are pieces of information that browsers exchange to find the most efficient route for data transmission. 'Not resolving quickly' means the browser isn't successfully finding optimal paths through the network, likely due to latency – Sarah is pointing out a potential cause in the user's environment. The term itself doesn't directly relate to audio quality or bugs.
7 / 10
Slack Message: John from QA sent a message in the #webrtc-dev channel. He wrote: 'We're seeing frequent dropped calls during peak hours. The server logs show a lot of 'failed offer/answer' messages. Anyone have insights into why this might be happening?' What is John most likely referring to when he mentions 'failed offer/answer'?
During an offer/answer exchange, one peer proposes its media capabilities (offer), and the other responds with its acceptance (answer). 'Failed' indicates that this negotiation wasn't successful – typically because the browsers couldn't agree on a common audio or video format. This is a very frequent cause of dropped calls in WebRTC.
8 / 10
PR Description: The developer writing the PR for a new WebRTC feature included this description: 'To improve user experience, we've implemented adaptive bitrate streaming. If network conditions degrade, the call will automatically reduce the resolution and frame rate to maintain stability.' What is the primary benefit of 'adaptive bitrate streaming' in the context of WebRTC?
Adaptive bitrate streaming is a technique used to optimize WebRTC calls for varying network conditions. By automatically adjusting the video quality (resolution and frame rate), it aims to maintain a stable connection and prevent dropped calls when bandwidth fluctuates – this is crucial for a good user experience.
9 / 10
Standup Update: During the daily standup, David reported: 'I'm still struggling to get consistent audio quality. I've checked my microphone and internet connection, but it keeps fluctuating.' What is a likely technical reason for David's inconsistent audio?
Inconsistent audio quality during WebRTC calls often stems from issues with media codecs – if the browser and server can't agree on a compatible codec (like Opus or VP8), it will lead to fluctuating audio. Latency is also a common cause but this describes a more general problem.
10 / 10
Debugging Tool: You are troubleshooting a WebRTC call and need to analyze the connection details. Which Chrome tool provides detailed information about ICE candidates, codecs, and connection statistics?
The chrome://net-internals/#rtp-monitor page is the dedicated Chrome tool for WebRTC diagnostics. It displays real-time information about ICE candidates (which are crucial for establishing a connection), codec details, and other connection statistics – it's specifically designed for debugging WebRTC issues.
What does this WebRTC & Real-Time Language exercise cover?
This exercise, "WebRTC Troubleshooting Vocabulary", tests your understanding of webrtc & real-time language vocabulary and phrasing through 10 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this WebRTC & Real-Time Language exercise for?
It's designed for IT professionals and learners who want to sound natural discussing webrtc & real-time language topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more WebRTC & Real-Time Language exercises?
Browse the full WebRTC & Real-Time Language exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.