A user reports their call "dropped". You check the WebRTC logs and see the iceConnectionState transitioned to disconnected and then to failed. What is the difference between these two states?
Disconnected is recoverable — failed is not. Handling both states correctly prevents a brief network blip from destroying a call.
ICE connection state lifecycle: new → checking → connected (→ completed) → disconnected → failed (or back to connected if recovery). Disconnected typically happens during brief network changes: switching Wi-Fi networks, going through a tunnel (mobile), or temporary packet loss. WebRTC's ICE agent continues sending keepalives and connectivity checks during disconnected state. If connectivity resumes within ~5 seconds (browser-configurable), the state transitions back to connected — seamless to the user. If not, it transitions to failed. Application strategy: on disconnected, show "Connection unstable — trying to reconnect..."; start a timer; on failed, attempt ICE restart (pc.restartIce()); on timeout, end the call and prompt the user to rejoin.
Key vocabulary: • disconnected state — transient; ICE lost connectivity but still attempting recovery; may return to connected • failed state — terminal; all ICE candidates exhausted; requires ICE restart or call teardown • ICE restart — pc.restartIce(); generates new ICE credentials and triggers fresh candidate gathering to recover from failed state
2 / 16
An engineer uses the getStats() API to diagnose call quality. They see packetsLost: 45 and packetsReceived: 900. How do they calculate the packet loss rate and what does it mean for call quality?
Packet loss rate = lost / (lost + received) — the denominator is total expected packets. 4.8% is mild-to-moderate: audio survives with Opus FEC; video will show noticeable freezing.
WebRTC quality thresholds (approximate): 0-1% packet loss — excellent; 1-3% — good; 3-5% — degraded video quality, audio acceptable; 5-10% — significant video freezing, audio still intelligible with Opus FEC; 10%+ — video unusable, audio struggles. The getStats() inbound-rtp report also provides framesDecoded, framesDropped, and jitterBufferDelay — together with packetsLost, these give a complete picture of video quality. For the audio track, packetsLost and concealment metrics show how often the jitter buffer had to synthesise audio to cover lost packets. In dashboards, track packet loss rate by candidate pair type — relay paths often have lower packet loss than direct paths in lossy networks.
Key vocabulary: • packet loss rate — packetsLost / (packetsLost + packetsReceived); key video quality metric • framesDropped — video frames the decoder dropped due to decode errors or missing reference frames • jitter buffer — WebRTC's adaptive buffer that absorbs network timing variation; delay vs. smoothness trade-off
3 / 16
A developer uses chrome://webrtc-internals during debugging. What information can they find there that they cannot get from application-level getStats() calls?
chrome://webrtc-internals is the power tool — it captures everything Chrome's WebRTC engine knows, including data not exposed via application APIs.
Critical debugging workflows with chrome://webrtc-internals: (1) codec negotiation debugging — read the full SDP offer and answer side-by-side to see which codecs were negotiated and why; (2) ICE candidate debugging — see ALL gathered candidates (not just the selected pair), which TURN servers were contacted, and which candidate pair is actually in use; (3) quality degradation analysis — getStats() time-series graphs show exactly when packet loss spiked or jitter increased, correlating with user-reported quality issues; (4) DTLS handshake timing — see how long TLS setup took (should be under 100ms; longer suggests TURN relay issues). For non-Chrome browsers, Firefox has about:webrtc and Safari has no equivalent — use getStats() programmatically and log to your own analytics.
Key vocabulary: • chrome://webrtc-internals — Chrome's internal WebRTC debug page; shows full SDP, all ICE candidates, and stats graphs • SDP dump — the complete offer/answer SDP content; chrome://webrtc-internals shows this; critical for codec debugging • active candidate pair — the ICE candidate pair currently being used for media; shown in chrome://webrtc-internals
4 / 16
A user reports that the video freezes periodically but audio remains clear. The getStats() data shows roundTripTime: 0.85 seconds. What does this RTT value indicate and how does it relate to the video freezing?
High RTT compounds packet loss damage for video — each recovery cycle takes longer, extending freeze duration. 850ms RTT means a lost packet can freeze video for nearly 2 seconds (loss detected + NACK sent + retransmission received).
The video freeze/RTT relationship: (1) a packet carrying video frame data is lost; (2) the receiver notices the gap and sends a NACK; (3) with 850ms RTT, the NACK arrives at the sender 425ms after the packet was sent; (4) the sender retransmits; (5) the retransmitted packet arrives another 425ms later — ~850ms of total freeze time for a single lost packet. For comparison, at 50ms RTT (good condition), the same recovery takes ~50ms — imperceptible. Mitigation: if RTT is consistently high, look at TURN relay server geography (the relay may be on the wrong continent), check for bufferbloat on the network path, and consider switching from VP8/VP9 to a lower-latency encoding profile.
Key vocabulary: • RTT (Round-Trip Time) — total time for a packet to reach the remote peer and the acknowledgement to return; in seconds • NACK (Negative Acknowledgement) — RTCP message from receiver requesting retransmission of a lost video packet • bufferbloat — excessive buffering in network equipment causing very high RTT while packet loss remains low
5 / 16
During debugging, a developer sees the ICE connection state is checking for over 30 seconds and never reaches connected. What does the checking state mean and what should they investigate?
Permanent checking state means ICE is running connectivity checks but none succeed — a classic symptom of NAT traversal failure with a misconfigured or absent TURN server.
Debugging checklist for stuck-in-checking: (1) open chrome://webrtc-internals and check the ICE candidate table — are relay candidates listed? If no relay candidates appear, the TURN server URL is wrong or unreachable; (2) check that ICE candidates from both peers are being received by the other side — if the signaling server has a bug and candidates are dropped, checking will run forever on wrong candidates; (3) test the TURN server directly with a STUN/TURN testing tool (e.g., Trickle ICE online tool); (4) check if TCP TURN (port 443) is configured as a fallback for environments where UDP is blocked; (5) verify the TURN server's authentication credentials (username/password or time-limited token) have not expired.
Key vocabulary: • checking state — ICE is sending connectivity checks on candidate pairs; waiting for a successful response • connected state — at least one candidate pair has passed connectivity checks; media can flow • ICE candidate pair — a combination of local candidate and remote candidate; ICE tests pairs to find a working path
6 / 16
Sarah (Senior Engineer) comments on a PR adding WebRTC debugging to the application: 'I'm seeing a lot of `iceConnectionState:failed` entries in the logs. What's the key difference between this and `iceConnectionState:disconnected'?'. Which statement best describes the distinction?
`iceConnectionState:disconnected` signifies that the peer has temporarily lost connectivity but might be able to re-establish it. `iceConnectionState:failed`, on the other hand, indicates a persistent problem preventing reconnection – often due to network issues or firewall restrictions. Using the terms correctly helps with accurate troubleshooting.
7 / 16
Mark (Frontend Developer) is investigating intermittent audio dropouts during calls. He's using getStats() and observes the following: `codecs: [ {rtpPayloadType: 96, rtpPSSequenceNumberMax: 1000 } ]` and `audioEobs: 128`. What is the most likely root cause of these audio dropouts?
The rtpPayloadType (96) is commonly used for audio. An inefficient codec configuration can lead to congestion and packet loss. While EOBS *can* indicate packet loss, the provided value of 128 doesn't immediately scream 'high loss'. The server load is a possible factor but not directly indicated by these stats.
8 / 16
David (Backend Engineer) is reviewing a PR that implements WebRTC diagnostics. The PR includes logging of the `iceConnectionState` property. He notices frequent entries stating `iceConnectionState:failed`. What's the *most* likely underlying reason for this state, assuming no network issues?
iceConnectionState:failed typically signifies a failure in the ICE (Interactive Connectivity Establishment) process – specifically, that the peer cannot establish a reliable IP connection with the remote peer. This commonly occurs due to NAT traversal issues or problems with signaling during the initial connection phase. While other options *could* contribute to connectivity problems, iceConnectionState:failed directly reflects this core ICE issue.
9 / 16
Emily (QA Engineer) reports a call with high latency. She's using Chrome's DevTools to analyze the WebRTC connection. Which metric would provide the *most* immediate insight into the cause of this high latency?
Round-Trip Time (RTT) is a direct measurement of the time it takes for data to travel from one endpoint to another and back. High RTT almost invariably indicates latency issues – the longer the round trip, the greater the delay in communication. While other metrics are relevant for diagnosis, RTT provides the most immediate indication of the core problem.
10 / 16
John, a junior developer, is troubleshooting a recurring issue where users report dropped calls. He's reviewing the WebRTC logs and sees frequent messages like `iceConnectionState:failed`. What does this specifically indicate about the connection's stability?
iceConnectionState:failed primarily reflects problems during the ICE (Interactive Connectivity Establishment) negotiation phase. This means the peers couldn't find a mutually acceptable route to connect, often due to network issues or firewall restrictions. While packet loss can *cause* this state, `failed` is the specific status of the ICE process itself.
11 / 16
Maria, a backend engineer, is debugging performance issues with WebRTC calls. She's using the getStats() API and observes `rtpPss: 50`. What does this metric primarily measure and what range of values generally indicates good call quality?
rtpPss (RTP Packet Loss per Second) measures the *reliability* of the RTP stream. A value close to zero indicates minimal packet loss and good call quality. High rtpPss values suggest jitter or unreliable transmission, leading to audio distortion and dropped packets – this is often more directly related to latency than a simple bandwidth measurement.
12 / 16
Liam (a Frontend Developer) is investigating a reported issue where users experience dropped audio during calls. He's examining the iceConnectionState property in the WebRTC logs and sees frequent entries indicating iceConnectionState:failed. What's the *most likely* underlying cause of this, based on what this state signifies?
iceConnectionState:failed indicates that the ICE (Interactive Connectivity Establishment) algorithm has been unable to establish a reliable connection path between the peers. This typically points to network issues – like high packet loss or firewall restrictions – preventing the establishment of a stable UDP channel needed for real-time communication. Options B and C are less direct causes; option D is unrelated.
13 / 16
Chloe (a Backend Engineer) is monitoring WebRTC call performance using the getStats() API. She observes a consistently high value for rtpPss (Receive Packet Loss per Second): 75. What does this primarily indicate and what range of values would typically be considered *problematic*?
rtpPss measures the rate at which RTP (Real-time Transport Protocol) packets are lost. A value of 75% signifies a significant amount of packet loss, directly impacting the quality of the audio and video streams. Values consistently above 30-40% generally indicate a performance bottleneck requiring investigation – typically network congestion or issues with the media codecs.
14 / 16
Olivia (a QA Engineer) is investigating a reported issue where users report high latency during WebRTC calls. She's using Chrome's DevTools to analyze the WebRTC connection and observes a consistently high value for rtpBargainTimeoutMs. What does this metric primarily indicate, and what *specific* area should she focus on to reduce it?
rtpBargainTimeoutMs measures the time it takes for the ICE algorithm to negotiate a connection path between peers. A high value indicates that the negotiation process is taking an excessively long time, often due to network instability or mismatched codec preferences. Focus should be on troubleshooting network connectivity and codec compatibility.
15 / 16
During a standup meeting, Alex (a Backend Engineer) explains that the application is experiencing intermittent WebRTC call failures. He mentions seeing frequent entries in the logs stating `iceConnectionState:failed`. Which of the following best describes what this state signifies?
The `iceConnectionState:failed` entry indicates that the ICE protocol is actively attempting to establish a connection but failing repeatedly. This typically points to network problems, issues with signaling (e.g., SDP negotiation errors), or potential firewall restrictions preventing a stable connection. It's *not* a successful connection.
16 / 16
As a Code Reviewer, you're examining a PR that includes logging of `rtpPss` (Receive Packet Loss per Second) during WebRTC calls. The PR author reports high values consistently observed in the logs. What does a persistently elevated rtpPss value primarily indicate?
A persistently elevated `rtpPss` value directly corresponds to receive packet loss. This means that a significant percentage of packets sent by the WebRTC endpoint are not reaching the destination, leading to corrupted audio and video streams. It's a key indicator of network congestion or problems.
What does this WebRTC & Real-Time Language exercise cover?
This exercise, "WebRTC Debugging and Diagnostics Language", tests your understanding of webrtc & real-time language vocabulary and phrasing through 16 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 16 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.