Mastering WebRTC SDP: A Complete Guide to Analyzing Session Descriptions

0. Introduction

SDP (Session Description Protocol) is a historic format used in 20th‑century conferencing systems to exchange connection and media attributes. Although JSON is more extensible today, understanding SDP remains valuable for system development and debugging, especially in WebRTC.

1. SDP Protocol Specification Overview

SDP consists of one session‑level part followed by zero or more media‑level parts.

Session‑level starts with “v=” line and continues until the first media‑level part.

Each media‑level part starts with “m=” line and continues to the next media‑level part or the end of the description.

Session‑level values serve as defaults for all media unless overridden.

SDP lines follow the <type>=<value> format; spaces are not allowed around “=”. Complex lines may use “;” as a separator.

SDP session description includes session name, duration, media components, and required information (address, port, format, etc.). The following fields may appear (optional fields marked with *): v=, o=, s=, i=, u=, e=, p=, c=, b=, t=, r=, z=, k=, a=, and zero or more media descriptions (m=...). The order of fields is fixed.

2. WebRTC SDP Content Analysis

In WebRTC, the SDP must contain at least the v, o, s, t, m, c, b, a lines (Version/Owner/Session/Timing/Media/Connection/Bandwidth/Attributes). Example:

v=0
o=mozilla...THIS_IS_SDPARTA-82.0.3 485627351772987711 0 IN IP4 0.0.0.0
s=-
t=0 0
m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 0.0.0.0
b=AS:1000
a=sendrecv
...

Media description example:

m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:audio
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1

m=video 9 UDP/TLS/RTP/SAVPF 96 97
a=mid:video
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96

2.1 WebRTC‑SDP Introduction

WebRTC requires the presence of the v, o, s, t, m, c, b, a lines. The “a=” lines carry most of the information, including media (RTP parameters) and connection (ICE, DTLS) details.

2.2 Plan B and Unified Plan

Plan B groups multiple tracks in a single “m=” line, while Unified Plan creates a separate “m=” line for each track. Unified Plan avoids attribute conflicts when multiple audio or video streams are present.

2.3 SDP Extension Information

Key “a=” line categories:

Codec parameters (a=rtpmap, a=fmtp, a=rtcp-fb)

Header extensions (a=extmap)

Encoding parameters (a=ssrc, a=ssrc-group)

RTCP parameters (a=rtcp, a=rtcp-mux, a=rtcp-rsize)

ICE candidates (a=candidate, a=end-of-candidates)

ICE options (a=ice-options, a=ice-lite, a=ice-ufrag, a=ice-pwd)

DTLS parameters (a=setup, a=fingerprint)

Miscellaneous (a=sendrecv, a=group, a=mid, a=rid, a=simulcast, a=bundle-only, a=msid-semantic)

Examples of codec parameters:

a=rtpmap:108 H264/90000

a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

a=rtcp-fb:108 goog-remb

Header extension example: a=extmap:14 urn:ietf:params:rtp-hdrext:toffset Encoding parameters example:

a=ssrc:3245189021 cname:nYAodpnTebS8lziR
a=ssrc-group:FID 3245189021 3715850271

ICE candidate example:

a=candidate:0 1 UDP 2122252543 192.168.0.111 56774 typ host

DTLS example:

a=setup:actpass
a=fingerprint:sha-256 9D:58:00:00:00:FF:FF:00:00:00:FF:FF:FF:FF:FF:FF:FF:FF:FF:00:00:00:00:00:00:00:00:00:00:00:00

2.4 Miscellaneous Attributes

Direction attributes (a=sendrecv, a=sendonly, a=recvonly, a=inactive) control media flow. The a=group:BUNDLE attribute bundles multiple media on a single transport. a=mid identifies each media line. a=rid and a=simulcast enable simulcast support. a=msid-semantic declares the media‑stream identifier semantics.