5 exercises — 5 exercises practising SDP offer/answer exchange, signaling server roles, perfect negotiation, and WebRTC signaling vocabulary.
0 / 17 completed
1 / 17
A developer asks: "What exactly does the signaling server do in WebRTC?" Which description is most accurate?
The signaling server is a "dumb relay" — it forwards opaque blobs of SDP and ICE data without understanding their content. WebRTC deliberately leaves signaling unspecified.
The WebRTC specification describes what needs to be exchanged (SDP and ICE candidates) but not HOW — there is no required signaling protocol. Teams use WebSocket (most common), HTTP long-polling, Firebase Realtime Database, or even copy-paste (useful for manual testing). The signaling server's job: receive an SDP offer from peer A → forward it to peer B → receive ICE candidates from A → forward to B, and vice versa. It doesn't parse, modify, or store these messages. After both peers have exchanged SDP and set up their P2P connection, they may keep the signaling channel open for in-call messages (mute/unmute events, chat), but media never flows through it.
Key vocabulary: • signaling channel — the application-provided communication channel for SDP and ICE exchange before P2P is established • out-of-band signaling — signaling via a separate channel (WebSocket) outside the WebRTC P2P connection itself • signaling protocol agnostic — WebRTC does not specify the signaling protocol; applications choose their own
2 / 17
A developer encounters the term SDP munging in a WebRTC codebase. What is it and why is it discouraged?
SDP munging is a hack — it works until the browser changes its SDP format slightly, then silently breaks calls. Modern APIs (setCodecPreferences, setParameters) should be used instead.
Common SDP munging use cases and their modern alternatives: (1) codec reordering — forcing VP9 before VP8 by sorting codec lines in SDP. Modern alternative: RTCRtpTransceiver.setCodecPreferences([VP9, VP8]). (2) Bandwidth limiting — adding b=AS:500 to the SDP to limit to 500kbps. Modern alternative: RTCRtpSender.setParameters() with encodings[0].maxBitrate. (3) Forcing stereo audio — adding a=fmtp:111 stereo=1. Modern alternative: AudioContext configuration. The WebRTC spec actively discourages SDP munging and has been adding proper APIs to replace the most common use cases.
Key vocabulary: • SDP munging — manually parsing and modifying the SDP text before calling setLocalDescription; fragile hack • setCodecPreferences — modern API for specifying codec priority order without SDP manipulation • setParameters — RTCRtpSender method for updating encoding parameters (bitrate, resolution) after connection is established
3 / 17
A team implements WebRTC with "perfect negotiation" and assigns one peer as polite and one as impolite. What problem does this solve?
Offer collisions happen when both peers call createOffer() at the same time — perfect negotiation provides a deterministic resolution without manual coordination.
Scenario: both peer A and peer B add a video track simultaneously (e.g., both users click "share screen" at the same moment). Both call createOffer() and send their offers to each other via the signaling server. Both receive a remote offer while their own offer is pending — this is a collision. Without a resolution strategy, both peers may get stuck. Perfect negotiation: the polite peer receives the remote offer and calls setLocalDescription({type: 'rollback'}) to cancel its own pending offer, then accepts the remote offer and sends an answer. The impolite peer receives the remote offer while its own is pending and simply ignores the incoming offer (it knows the polite peer will roll back). Result: clean resolution every time.
Key vocabulary: • offer collision — both peers send offers simultaneously; requires a resolution strategy • polite peer — rolls back its own offer when it receives a remote offer during a collision • rollback — setLocalDescription({type: 'rollback'}); cancels a pending local offer and returns to stable signaling state
4 / 17
A developer says: "We use Trickle ICE rather than waiting for all candidates to be gathered before sending the offer." What is Trickle ICE and why is it faster?
Trickle ICE dramatically reduces call setup time by allowing early candidate pairs to be tested immediately rather than waiting for TURN allocation (which can take 100-500ms).
Without Trickle ICE (vanilla ICE): (1) peer A gathers ALL candidates (host + STUN + TURN) — takes 200-800ms; (2) puts all candidates in the SDP offer; (3) sends offer. Peer B does the same for the answer. ICE checking only starts after both SDPs are exchanged. With Trickle ICE: (1) peer A sends SDP offer immediately with ICE credentials (but no candidates yet); (2) as candidates are gathered, they are sent immediately via the signaling channel using addIceCandidate(); (3) connectivity checks start with the first host candidate — often establishing connection before TURN candidates are even gathered. Time to first media typically 200-500ms faster than vanilla ICE.
Key vocabulary: • Trickle ICE — sending ICE candidates to the remote peer as they are gathered, not batched in the SDP • addIceCandidate() — WebRTC API call for adding a received ICE candidate to the peer connection • vanilla ICE — waiting for all candidates before sending the offer; slower but simpler to implement
5 / 17
A new developer asks why the signaling server logs show SDP messages being sent twice for a renegotiation. What is renegotiation in WebRTC?
Renegotiation is a new offer/answer cycle within an existing connection — triggered whenever the media topology changes after the initial connection is established.
Common renegotiation triggers: (1) pc.addTrack() — adding a screen share track mid-call; (2) pc.removeTrack() — stopping the camera; (3) changing transceiver direction (sendrecv → sendonly); (4) the remote peer adding or removing tracks. When renegotiation is needed, the browser fires the onnegotiationneeded event. The application must handle this by creating a new offer and restarting the signaling exchange — but only for the changed portions of the SDP. Renegotiation must be implemented carefully to avoid race conditions (both peers renegotiating simultaneously) — this is the problem that perfect negotiation solves.
Key vocabulary: • renegotiation — a new offer/answer exchange after the initial connection; triggered by media topology changes • onnegotiationneeded — browser event fired when renegotiation is required; application must handle it by creating a new offer • renegotiation collision — both peers trigger renegotiation simultaneously; handled by perfect negotiation polite/impolite roles
6 / 17
Sarah (Senior Engineer) just posted a comment on your PR describing the `signalingServer`'s role. Which of the following best captures her intent?
'The signaling server is responsible for establishing and maintaining the connections between the peers, exchanging SDP offers, answers, and updates to negotiate the media stream configuration.'
Incorrect options focus on overly simplistic or misleading interpretations. The signaling server's core function is indeed the complex negotiation process outlined in the correct answer: exchanging SDP messages to determine compatible codecs and network settings. This highlights a common misunderstanding that it's merely a relay; it actively participates in configuring the WebRTC connection.
7 / 17
Mark (Lead Developer) sends you this Slack message: 'I'm seeing some issues with ICE candidates. It seems like our peers are constantly sending new candidate reports, even after a stable connection is established. We need to investigate if there's a problem with SDP munging.' What does Mark likely mean by 'SDP Munging'?
'SDP Munging refers to the automatic modification of the SDP (Session Description Protocol) messages during the negotiation phase, often due to differences in network conditions or browser implementations.'
The key misunderstanding is equating munging with encryption or bandwidth optimization. SDP Munging specifically describes browser-driven modifications to SDP messages – often due to differences in how browsers interpret and handle those messages. This can lead to inconsistencies during negotiation, requiring careful attention.
8 / 17
During a standup update, David (Junior Developer) explains the team's approach to WebRTC. 'We're using perfect negotiation – one peer is always polite and sends offers, while the other is impolite and waits for them.' What problem does this setup *primarily* address?
'This strategy helps avoid potential issues with SDP offer/answer cycles when peers have different capabilities or network conditions.'
The core problem solved is avoiding SDP offer/answer cycles. When peers have differing capabilities (e.g., one has a faster network), an 'impolite' peer constantly sending offers can overwhelm the more capable peer, leading to inefficient negotiation and potential connection problems. The 'polite' peer acts as a buffer.
9 / 17
You're reviewing a WebRTC codebase and notice that the signaling server logs show SDP messages being sent twice for a renegotiation. What does this likely indicate about the renegotiation process?
'This suggests an inefficient or misconfigured negotiation flow, potentially due to a loop where the peers are repeatedly exchanging identical SDP updates.'
The key indicator of an issue is the repeated sending of identical SDP messages. This strongly suggests a loop in the negotiation flow – often caused by misconfigured logic or a lack of proper termination conditions for renegotiations. This isn't a standard feature; it's a symptom.
10 / 17
John, a new team member, asks: 'I'm reviewing the PR for our WebRTC implementation. I see mentions of 'session description protocol' (SDP). What is SDP and why does it appear in this context?'. Which explanation best describes its role?
SDP (Session Description Protocol) isn't a database or a shell. It's a crucial part of the signaling process in WebRTC. SDP messages are exchanged between peers to negotiate the technical details of their connection – things like supported audio and video codecs, bandwidth limits, and IP addresses. It's essentially a description of the 'session' that needs to be established.
11 / 17
Maria, a senior engineer, sends this Slack message: 'We're observing inconsistent ICE candidate reporting. Some peers are sending new candidates frequently even after a stable connection is established. This impacts performance significantly. What's the most likely cause of this behavior?
While all options could *potentially* contribute to issues with ICE candidates, Maria's observation – frequent updates even after a stable connection – strongly suggests the peer's ICE stack is actively searching for better routes. This is normal behavior and not necessarily a bug; it's how the ICE protocol works to optimize connections.
12 / 17
Liam (Senior Developer) comments on a PR describing the use of a signaling server: 'To ensure reliable connection establishment, we're leveraging a signaling server to exchange SDP offers and ICE candidates. The server acts as a central hub for negotiation, streamlining the process and reducing peer-to-peer latency.' Which statement best reflects Liam's primary justification?
Liam is emphasizing the core function of the signaling server: facilitating the exchange of SDP offers and ICE candidates. This is crucial because WebRTC relies on these messages to establish a connection. The other options misrepresent the purpose – network topology isn't directly addressed, immediate establishment isn't guaranteed, and manual gathering is typically avoided through negotiation.
13 / 17
Elena (Lead Engineer) sends a Slack message to the team: 'We're seeing some intermittent disconnections when using WebRTC. I suspect it's related to the signaling server handling ICE candidate updates – it might be overwhelmed by the frequency of changes.' What is Elena most likely referring to when discussing 'ICE candidate updates' in relation to the signaling server?
Elena is highlighting a potential bottleneck: the signaling server's capacity to handle frequent changes in ICE candidate information. WebRTC uses ICE candidates for routing traffic efficiently; if the server can't manage these updates quickly enough, it can lead to disconnections and instability. The other options describe desirable behaviors but aren't the root of her concern.
14 / 17
Reviewing a PR for our new WebRTC implementation, you see the following log message from the signaling server: 'SDP Offer Sent - Peer A'. What is the primary purpose of this SDP Offer in the context of establishing a WebRTC connection?
Option A: To securely transmit the user's audio and video capabilities. Option B: To exchange information about the network conditions between the peers. Option C: To initiate the negotiation process for establishing a peer-to-peer connection. Option D: To encrypt all subsequent communication between the peers.
The SDP (Session Description Protocol) offer contains crucial details about each peer's media capabilities – audio and video codecs, supported resolutions, etc. This exchange is the first step in negotiating a compatible connection. Sending an SDP Offer signals the intention to begin this negotiation; encrypting isn't its primary function.
15 / 17
During a standup update, David (Junior Developer) explains the team's approach to WebRTC. 'We're using perfect negotiation – one peer is always polite and sends offers, while the other is impolite and waits for them.' What potential problem does this seemingly unusual design choice *attempt* to address?
Option A: It guarantees faster connection establishment by forcing a single peer to be proactive. Option B: It simplifies debugging by isolating the negotiation logic to one participant. Option C: It mitigates potential issues related to inconsistent ICE candidate reporting and asymmetrical negotiation behavior. Option D: It ensures that the polite peer always receives higher priority for establishing a connection.
The 'perfect negotiation' strategy is designed to address imbalances in ICE candidate reporting. One peer acting as 'polite' proactively sends offers, while the other waits, helping to synchronize and resolve potential discrepancies that can lead to connection failures. This creates a more balanced negotiation process.
16 / 17
Sarah (Senior Engineer) just posted a comment on your PR describing the `signalingServer`'s role. Which of the following best captures her intent?
'The signaling server is responsible for establishing and maintaining session descriptions, facilitating peer-to-peer communication by exchanging SDP offers and ICE candidates. It acts as the central hub for initiating and managing the WebRTC connection.' What does Sarah *specifically* mean by 'session descriptions'? Option A: The actual audio and video streams being transmitted. Option B: The metadata describing the capabilities of each peer involved in the connection. Option C: The cryptographic keys used to secure communication between the peers. Option D: The sequence of messages exchanged during the initial negotiation phase.
Session descriptions (SDP) are *not* the audio or video streams themselves. They're a structured data format that defines the technical parameters for the WebRTC connection – codecs, resolutions, bandwidth constraints - describing each peer's capabilities to the other.
17 / 17
You're reviewing a WebRTC codebase and notice that the signaling server logs show SDP messages being sent twice for a renegotiation. What does this likely indicate about the renegotiation process?
Option A: The signaling server is correctly handling multiple negotiation attempts. Option B: The signaling server is implementing a robust mechanism to automatically retry negotiations in response to network changes. Option C: There's an issue with the signaling server's logic, potentially leading to duplicate SDP message transmission during renegotiation. Option D: The peer connections are intentionally designed for frequent and dynamic renegotiations.
Duplicate SDP messages during a renegotiation strongly suggest a bug in the signaling server's code. It indicates that the same negotiation process is being triggered multiple times, likely due to an error in how the server handles network changes or connection failures.
What does this WebRTC & Real-Time Language exercise cover?
This exercise, "WebRTC Signaling — Vocabulary and Language", tests your understanding of webrtc & real-time language vocabulary and phrasing through 17 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 17 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.