How WebRTC RTCPeerConnection Manages SDP and ICE

Establishing a direct peer-to-peer connection in WebRTC requires two critical signaling mechanisms: the Session Description Protocol (SDP) handshake and Interactive Connectivity Establishment (ICE) candidate gathering. JavaScript’s RTCPeerConnection API orchestrates this process by negotiating media capabilities through an offer/answer exchange while concurrently discovering viable network paths to bypass firewalls and NATs.

The SDP Handshake (Offer/Answer Exchange)

The SDP handshake is a negotiation protocol that allows two peers to agree on the media formats, codecs, encryption keys, and session parameters required for streaming. This process follows a structured sequence between the initiating peer (caller) and the receiving peer (callee):

  1. Creating the Offer: The caller instantiates an RTCPeerConnection object and attaches any local media tracks using addTrack(). The caller then calls peerConnection.createOffer() to generate an SDP offer blob containing its media and networking capabilities.
  2. Applying the Local Description: The caller sets this generated offer as its local configuration by calling peerConnection.setLocalDescription(offer).
  3. Transmitting the Offer: The caller sends the SDP offer to the callee across an out-of-band signaling mechanism (such as WebSockets or HTTP).
  4. Receiving and Answering: The callee receives the offer and invokes peerConnection.setRemoteDescription(offer). Next, the callee calls peerConnection.createAnswer(), sets it locally using peerConnection.setLocalDescription(answer), and sends the generated SDP answer back to the caller.
  5. Finalizing the Negotiation: The caller receives the answer and applies it using peerConnection.setRemoteDescription(answer). At this point, both sides have reached a consensus on how media will be encoded and encrypted.

ICE Candidate Gathering and Exchange

While the SDP negotiation establishes what to transmit, the ICE framework determines how the two devices will physically route data packets across the internet.

  1. Candidate Discovery: Once setLocalDescription() is executed, the RTCPeerConnection begins querying local interfaces, STUN (Session Traversal Utilities for NAT) servers, and TURN (Traversal Using Relays around NAT) servers to discover available endpoints. These endpoints are called ICE candidates (host, srflx, or relay candidates).
  2. The icecandidate Event: Every time a new network route is discovered, the browser fires the peerConnection.onicecandidate event.
  3. Signaling Candidates (Trickle ICE): Modern WebRTC implementations use Trickle ICE, sending each candidate immediately via the signaling server to the remote peer as soon as it is generated, rather than waiting for all candidates to be gathered.
  4. Adding Remote Candidates: When a peer receives an ICE candidate from the signaling server, it registers the route with its local connection instance by invoking peerConnection.addIceCandidate(candidate).

Connection Establishment

As ICE candidates are exchanged and verified through connectivity checks, the RTCPeerConnection pairs matching candidates to determine the lowest-latency, highest-priority network path. Once a valid path is confirmed and the SDP exchange is complete, the iceConnectionState transitions to connected, allowing media and data channels to flow directly between peers without passing through a media server.