Practise vocabulary for real-time performance: jitter, packet loss, RTT, bandwidth estimation, congestion control (GCC), and QoS for video calls.
0 / 5 completed
1 / 5
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 / 5
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 / 5
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 / 5
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 / 5
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.