Practise vocabulary for real-time performance: jitter, packet loss, RTT, bandwidth estimation, congestion control (GCC), and QoS for video calls.
0 / 10 completed
1 / 10
A developer says 'we're seeing 200ms RTT on this call.' What does RTT mean and why does it matter for real-time communication?
Round-Trip Time measures network latency between two endpoints. For WebRTC, RTT is measured via RTCP. 200ms RTT means roughly 100ms one-way latency — acceptable for most calls. ITU-T G.114 recommends one-way latency under 150ms for good quality; above 400ms one-way causes significant conversational disruption (both parties talk simultaneously because they can't hear each other's responses quickly enough).
2 / 10
What is 'jitter' in the context of real-time video call performance?
Jitter is the statistical variation in inter-packet arrival time. If packets are sent every 20ms but arrive at 15ms, 35ms, 10ms, 40ms intervals — jitter is high. WebRTC's jitter buffer absorbs jitter by holding packets briefly and delivering them smoothly, at the cost of added latency. The jitter buffer size is adaptive — it grows when jitter increases, shrinking when the network stabilises. Metrics: jitter is reported in RTCP Receiver Reports in milliseconds.
3 / 10
What is GCC (Google Congestion Control) in WebRTC?
GCC (Google Congestion Control, also called REMB/Transport-CC) is WebRTC's built-in adaptive bitrate algorithm. It works in two ways: (1) delay-based: if packet inter-arrival time increases, the network is becoming congested — reduce bitrate. (2) Loss-based: if packet loss exceeds a threshold, reduce bitrate. GCC signals the desired bitrate back to the sender via RTCP REMB or Transport-CC feedback. The sender's encoder then adjusts resolution/framerate to match the estimated available bandwidth.
4 / 10
An engineer says 'we're experiencing 8% packet loss on the video call.' What is 'packet loss' and what are its effects on WebRTC calls?
Packet loss in UDP-based RTP is unrecoverable without mitigation. WebRTC's strategies: NACK (Negative ACKnowledgement) — receiver requests retransmission of lost packets; useful when RTT is low enough for retransmission to arrive before the playout deadline. FEC (Forward Error Correction) — sender adds redundant data so receivers can reconstruct lost packets without retransmission. RED (Redundant Encoding) — audio redundancy encoding. Above ~10% loss, even these mitigations fail and call quality degrades severely.
5 / 10
What is 'bandwidth estimation' in WebRTC performance vocabulary?
Bandwidth estimation is the heart of WebRTC's adaptive bitrate system. The receiver collects inter-packet arrival time statistics and reports them back to the sender (via RTCP Transport-CC feedback). The sender's GCC algorithm interprets these reports to estimate available bandwidth — then sets the video encoder's target bitrate accordingly. The result: video quality automatically adapts to network conditions, using high bitrate (high quality) when bandwidth is available and reducing quality rather than dropping frames when congestion is detected.
6 / 10
During a code review of the WebRTC implementation, Sarah says, 'The latency is spiking dramatically during peak usage. We need to investigate this further.' What does 'latency' refer to in this context?
Latency in WebRTC describes the overall delay experienced by a signal traveling from one endpoint to another. It's not simply about response time; it's specifically the *time* taken for a message or packet to reach its destination and receive confirmation. Understanding this distinction is crucial for diagnosing performance issues.
7 / 10
You're in a Slack channel discussing network problems with a video conference. David writes: 'We're seeing significant packet loss – it's making the call constantly drop.' What is 'packet loss' and why does it negatively impact real-time communication?
Packet loss occurs when one or more of the data packets sent during a real-time communication session are lost in transit. This happens due to network congestion, errors, or other issues, and directly results in dropped audio/video streams because the receiving endpoint doesn't receive complete messages. It's a fundamental cause of poor call quality.
8 / 10
During a daily standup meeting, Mark reports: 'We've implemented adaptive bitrate streaming for the video calls. We're now actively monitoring our 'bandwidth estimation' metrics.' What is 'bandwidth estimation' and why is it important in this scenario?
Bandwidth estimation is the process where the WebRTC client dynamically assesses the available network bandwidth to determine an optimal data rate. This allows the call quality to adjust in real-time to changing conditions – a lower bandwidth leads to a lower bitrate, and vice versa – maintaining a stable connection.
9 / 10
You're writing a PR description for a change that improves WebRTC performance. You need to explain the concept of 'jitter' to your team. What is jitter?
Jitter represents the variation or inconsistency in latency. It's *not* constant delay; instead, it's fluctuations in timing, which severely disrupt real-time communication because audio/video streams are sensitive to even slight variations in arrival times. High jitter leads to choppy audio and video.
10 / 10
In a code review comment, Alex mentions, 'We're utilizing GCC (Google Congestion Control) in our WebRTC implementation.' What does GCC stand for and what is its primary function?
GCC (Google Congestion Control) is a congestion control protocol specifically designed for WebRTC. Its primary function is to manage the transmission rate of data packets based on network conditions – it dynamically adjusts the sending rate to avoid overwhelming the network and causing further congestion.
What does this WebRTC & Real-Time Language exercise cover?
This exercise, "Real-Time Performance 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.