Under the Hood of WebRTC: From SDP to ICE and DTLS in Production

WebRTC enables rich, real-time audio/video (and data) directly in browsers without plugins. Under the hood, it combines multiple layers – a high-level JavaScript API (RTCPeerConnection) sits atop native engines (voice, video, transport) and protocols like SDP, ICE/STUN/TURN, DTLS, and SRTP (see diagram).

At a glance, a WebRTC connection involves two peers (say Alice and Bob) exchanging signaling messages (via your own server/channel) containing Session Description Protocol (SDP) offers/answers and ICE candidates. The peers gather all possible network paths (ICE), choose the best one, perform a DTLS handshake to establish encryption keys, and then begin streaming media over Secure RTP. Below we unpack each step in detail: how an SDP offer/answer is negotiated, how ICE/STUN/TURN works to traverse NATs, and how DTLS bootstraps the secure media path.

Signaling and the SDP Offer/Answer

WebRTC itself does not define signaling ...