Role of SDP Negotiation in WebRTC Connections

Session Description Protocol (SDP) negotiation is the foundational mechanism that allows two browsers or devices to establish a direct, peer-to-peer WebRTC connection in JavaScript. This article explains the role of SDP in WebRTC, detailing how the offer/answer model works, what metadata is exchanged, and why this negotiation process is essential for coordinating media formats, network paths, and encryption parameters between peers.

What is SDP in WebRTC?

Session Description Protocol (SDP) is a standard text-based format used to describe the parameters of a multimedia communication session. In WebRTC, browsers do not exchange actual media streams during the initial handshake; instead, they exchange SDP messages. These messages act as a blueprint that specifies what each peer can send and receive, ensuring both sides agree on communication parameters before any audio, video, or data is transmitted.

The Core Functions of SDP Negotiation

SDP negotiation accomplishes four critical tasks during the setup of an RTCPeerConnection:

1. Media Capability and Codec Alignment

Before streaming starts, both peers must agree on supported audio and video formats. SDP payloads contain: * Supported audio and video codecs (such as Opus, VP8, VP9, or H.264). * Media types (audio, video, data channel). * Sampling rates, channel counts, and video resolutions. * Directionality attributes (e.g., sendrecv, sendonly, recvonly).

2. Network Routing and Transport (ICE Parameters)

To bypass Network Address Translation (NAT) and firewalls, WebRTC uses Interactive Connectivity Establishment (ICE). The SDP contains: * ICE credentials (ufrag and password) used to authenticate connection checks. * Initial ICE candidates (IP addresses, ports, and protocols like UDP/TCP).

3. End-to-End Security Setup

WebRTC mandates encryption for all media and data channels. The SDP includes: * Datagram Transport Layer Security (DTLS) fingerprints. * Setup roles (determining which peer acts as the DTLS client or server). * Information necessary to derive Secure Real-time Transport Protocol (SRTP) encryption keys.

4. Session Control and Synchronization

SDP defines synchronization source (SSRC) identifiers and media stream identification attributes, allowing the receiving peer to correctly match incoming packet streams to specific HTML <audio> or <video> elements.

The JavaScript Offer/Answer Negotiation Flow

The SDP negotiation process follows an “Offer/Answer” model executed through JavaScript WebRTC APIs:

1. Initiating the Offer (Caller):
   • The initiating peer calls peerConnection.createOffer() to generate an SDP offer containing its local configuration and capabilities.
   • The caller applies this description locally using peerConnection.setLocalDescription(offer).
   • The offer is sent to the remote peer via a signaling server (e.g., using WebSockets).
2. Receiving and Responding (Callee):
   • The receiving peer gets the offer and applies it via peerConnection.setRemoteDescription(offer).
   • The callee calls peerConnection.createAnswer() to generate an SDP answer that matches compatible codecs and parameters.
   • The callee sets its own local state via peerConnection.setLocalDescription(answer) and transmits the answer back through the signaling server.
3. Finalizing Negotiation (Caller):
   • The caller receives the answer and applies it using peerConnection.setRemoteDescription(answer).

Once both peers have set both their local and remote descriptions, the SDP negotiation is complete, enabling direct P2P media and data transmission.

Renegotiation

SDP negotiation is not limited to initial connection setup. If session parameters change during a call—such as adding a screen-sharing track, turning off a camera, or changing network conditions—the negotiationneeded event fires on the RTCPeerConnection instance. This triggers a new offer/answer exchange to update the session configuration without terminating the active connection.