WebRTC Signaling — Vocabulary and Language

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

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

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

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

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