5 exercises — 5 exercises practising RTCPeerConnection, ICE candidates, STUN/TURN, and the WebRTC connection setup vocabulary.
0 / 10 completed
1 / 10
A developer explains WebRTC to a product manager: "The connection is peer-to-peer." The PM asks, "Does that mean our servers are not involved at all?" Which answer is accurate?
WebRTC is P2P for media but requires server infrastructure for signaling, STUN, and TURN — "no servers needed" is a common misconception.
The three server components: (1) Signaling server — a WebSocket server your application provides to relay SDP offers/answers and ICE candidates between peers before the P2P connection exists. WebRTC deliberately doesn't specify the signaling protocol — you build it. (2) STUN server — a stateless service peers query to discover their public IP/port (e.g., Google's stun.l.google.com:19302). Required for NAT traversal in most networks. (3) TURN server — a relay server that forwards media when direct P2P is blocked by symmetric NAT (corporate firewalls, carrier-grade NAT). TURN is expensive: all media flows through it. Good news: TURN is only needed for ~20-30% of connections in typical deployments.
Key vocabulary: • signaling server — application-provided WebSocket server relaying SDP and ICE candidates between peers before P2P is established • STUN server — discovers public IP/port; stateless; needed for NAT traversal • TURN server (relay) — forwards media when direct P2P is impossible; required for symmetric NAT
2 / 10
A colleague describes the ICE candidate gathering process. Which explanation is most accurate?
ICE collects all possible network paths (host, server-reflexive, relay) and systematically tests them to find the best working pair.
The three candidate types serve different scenarios: host candidates work when both peers are on the same LAN (office or home network). Server-reflexive candidates (public IP from STUN) work when both peers are behind NAT but the NAT types are compatible (most home routers). Relay candidates (TURN) are the last resort when both peers are behind symmetric NAT that prevents direct connections. ICE connectivity checks test every candidate pair combination — source A's host → destination B's host, source A's reflexive → B's host, etc. The highest-priority working pair is selected as the active candidate pair. This process is called the ICE check list.
Key vocabulary: • host candidate — local network IP:port; works for same-LAN connections • server-reflexive candidate — public IP:port discovered via STUN; works for most NAT scenarios • relay candidate — TURN server address; fallback when direct P2P is blocked by symmetric NAT
3 / 10
An engineer reports: "The WebRTC call works perfectly on our office Wi-Fi but fails completely for users on corporate networks." What is the most likely explanation?
Symmetric NAT is the #1 cause of WebRTC connection failures in enterprise environments — TURN relay is required, and TURN itself may need to be configured for TCP port 443 to pass through firewalls.
Symmetric NAT assigns a unique external IP:port combination for each remote destination. STUN discovers the external port for the STUN server connection — but when the browser tries to connect to the remote peer using that port, the NAT assigns a different port for the peer's IP. The remote peer's ICE connectivity check fails. Solution: TURN relay. But corporate firewalls often block UDP entirely. TURN servers should be configured to listen on TCP port 443 (same as HTTPS) so traffic passes through corporate HTTP proxies. This is why enterprise-ready WebRTC deployments must run TURN on port 443 TCP.
Key vocabulary: • symmetric NAT — NAT assigns a unique external port per (source IP, source port, destination IP, destination port) tuple; defeats STUN hole punching • hole punching — technique where both peers send packets simultaneously to create NAT mappings; fails with symmetric NAT • TURN on TCP 443 — TURN configured to use the HTTPS port so traffic passes through corporate firewalls
4 / 10
A developer explains the WebRTC connection setup sequence to a new team member: "First we create the offer, then the answer." What is the offer/answer model and what does each message contain?
SDP offer/answer is a capability negotiation — peers exchange what they can send/receive and agree on codecs, encryption parameters, and ICE credentials.
The SDP offer contains: media sections (audio, video, data channel) each with supported codecs and their parameters, ICE credentials (username/password for connectivity checks), DTLS fingerprint (certificate hash for secure key exchange), and RTP/RTCP port information. The remote peer's answer accepts compatible codecs and provides its own ICE credentials and DTLS fingerprint. The offer/answer model is an IETF standard (RFC 3264) that WebRTC builds on. After both setLocalDescription and setRemoteDescription are called, ICE gathering begins and candidates are exchanged via the signaling channel in parallel.
Key vocabulary: • SDP (Session Description Protocol) — text format describing media capabilities, ICE credentials, and DTLS fingerprint • setLocalDescription — stores own SDP and starts ICE gathering • setRemoteDescription — stores the peer's SDP; triggers ICE connectivity checks with newly gathered candidates
5 / 10
A senior engineer reviews WebRTC infrastructure costs and says: "We need to minimise TURN relay usage." Why is TURN usage expensive, and what strategies reduce it?
TURN is expensive because it handles the full media stream — not just a small signaling message — so every TURN-relayed call consumes bandwidth proportional to audio/video bitrate times duration.
Cost calculation example: a 30-minute HD video call at 2Mbps through TURN = 450MB of relay traffic. At 1000 such calls per day = 450GB/day. At $0.10/GB bandwidth, that's $45/day just for TURN. Compare to STUN: the entire STUN exchange for a call is a few hundred bytes. Target metrics for a healthy WebRTC deployment: relay (TURN) candidate type should be under 20-30% of all calls. Above 50% indicates network configuration problems. Monitoring: log the selected candidate pair type (host/srflx/relay) for every call — srflx and host are essentially free; relay is the cost driver.
Key vocabulary: • relay candidate — TURN-based candidate; all media flows through the TURN server; expensive at scale • srflx candidate — server-reflexive; discovered via STUN; free (STUN is stateless) • ICE candidate type breakdown — metric showing what percentage of calls use host/srflx/relay paths; key infrastructure health indicator
6 / 10
Sarah (Lead Frontend) is reviewing a PR that uses the WebRTCDataChannel. She comments: 'This channel is bidirectional – it allows for real-time data exchange between the client and server. But what happens if the connection drops?' Which of the following best describes the expected behavior?
WebRTCDataChannels are designed for bidirectional communication. When a connection is lost (a 'peer connection failure'), the protocol dictates that the channel will attempt to re-establish itself. Option A is incorrect because permanent loss isn't typical; options C & D misrepresent how error handling and reconnection attempts work within the WebRTC specification.
7 / 10
Mark (Backend Engineer) is debugging a failed WebRTC call. He examines the network traffic and sees numerous messages related to 'ICE candidates'. Which of the following statements accurately explains the purpose of ICE candidates?
ICE (Interactive Connectivity Establishment) candidates are crucial for WebRTC's ability to work across diverse networks. They aren't server addresses or cryptographic keys; instead, they represent network routes that both peers can discover, allowing them to find the most efficient path to communicate. Understanding this is key to troubleshooting connectivity issues.
8 / 10
David (DevOps Engineer) notices high costs associated with a WebRTC deployment. He investigates and discovers that the TURN server is being heavily utilized. Which of the following reasons *most* likely explains this increased cost?
TURN (Traversal Using Relays around NAT) servers are critical for enabling communication between peers behind firewalls. However, they function as relays and introduce latency. The more calls using TURN, the greater the bandwidth consumption and processing load on the server – this is why it's expensive to operate. Options A & D are inaccurate; the application isn't *initiating* connections in this scenario.
9 / 10
Emily (Senior Engineer) is explaining WebRTC's signaling process to a junior developer. She says: 'We first create an 'offer' – this describes the media capabilities of our client. Then we send it to the other peer, who responds with an 'answer', matching their capabilities.' What does each message contain?
The 'offer/answer' model is fundamental to WebRTC. The 'offer' (SDP - Session Description Protocol) specifies the capabilities of one peer—the codecs they support, their network parameters, etc. The 'answer' (also SDP) describes the other peer's capabilities, allowing them to negotiate a compatible connection. Misconceptions often arise from confusing the roles of SDP and the actual media stream.
10 / 10
Ben (System Architect) is discussing WebRTC infrastructure costs. He states: 'We need to minimize TURN relay usage.' Which of the following strategies would *most* effectively reduce the reliance on TURN relays?
TURN relays are used when direct peer-to-peer connections aren't possible due to NAT or firewall restrictions. STUN (Session Traversal Utilities for NAT) servers help clients determine their public IP address and port, allowing them to establish direct connections where feasible. Minimizing TURN usage directly reduces the load on the relay server and associated costs – this is the most impactful strategy.
What does this WebRTC & Real-Time Language exercise cover?
This exercise, "WebRTC Fundamentals — Core 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.