SDP — what it is, session description format and role in WebRTC

What is SDP (Session Description Protocol)?

SDP is an application layer protocol designed to describe multimedia session parameters in text format. It was developed within the IETF MMUSIC (Multiparty Multimedia Session Control) working group and first standardized in RFC 2327 in 1998. In 2021, the current specification RFC 8866 was released, replacing the previous version RFC 4566.

The main task of SDP is to provide session participants with all the necessary information for establishing a connection: which media streams will be transmitted, which codecs are supported, and over which network addresses and ports the transmission will occur. SDP does not transmit the media data itself, but only describes how the connection should be organized.

According to IETF RFC 8866, the SDP format consists of a set of lines, each starting with a single-letter type, followed by an equals sign and a value. For example, the line m=audio 5004 RTP/AVP 0 means the session includes an audio stream on port 5004 with RTP/AVP transport protocol and PCMU codec (type 0).

History and standardization of SDP

The first version of SDP was published in RFC 2327 in April 1998 as a result of the MMUSIC group's work. The protocol was originally created for announcing multicast sessions within Mbone (Multicast Backbone). With the development of VoIP and video conferencing, SDP's application scope expanded, and in 2006, the updated specification RFC 4566 was released.

A real breakthrough in SDP usage came with the advent of WebRTC in 2011. Google integrated SDP as the primary mechanism for describing media sessions in its framework for browser-based real-time communication. Since then, SDP has become a mandatory component of any WebRTC implementation — from browsers to mobile applications on iOS and Android.

In 2021, the IETF working group published RFC 8866 — the current SDP specification, replacing RFC 4566. The updated version clarified ICE (Interactive Connectivity Establishment) processing, DTLS (Datagram Transport Layer Security) support, and expanded capabilities for describing group sessions.

Difference between SDP and transport protocols

SDP fundamentally differs from transport protocols in that it does not participate in data transmission. It performs a purely descriptive function — similar to multimedia file metadata. While RTP (Real-time Transport Protocol) transmits audio and video packets, and RTCP controls transmission quality, SDP only specifies which codecs and ports to use.

An analogy from web development: SDP is like HTML markup describing the page structure, while RTP is the actual images and text. Without SDP, session participants do not know how to connect to each other, even if the network connection is already established. The NAT traversal mechanism (ICE) also relies on SDP to transmit information about network candidates.

How is SDP structured

The SDP structure is organized as a sequence of text lines, each following the type=value format. The single-letter type defines the purpose of the line, and the value contains the corresponding value. All lines are separated by a CRLF character.

The RFC 8866 standard defines several mandatory and optional fields. Mandatory fields include the protocol version (v=), session name (s=), and session start and end time (t=). The remaining fields are optional, but for WebRTC sessions, media descriptions (m=), attributes (a=) and network information (c=) are also necessary.

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

The example above shows a typical SDP segment for a WebRTC session. The v=0 line indicates the protocol version. The o= field contains the session owner's identifier and version. The s=- line specifies the session name (a hyphen means an empty name). The t=0 0 field indicates that the session is not time-limited.

The a=group:BUNDLE audio video field is an attribute that groups multiple media streams into one transport channel. The BUNDLE mechanism allows saving network resources by transmitting audio and video through a single connection. This is especially important for mobile devices with limited bandwidth.

Mandatory SDP fields

The RFC 8866 specification defines a set of mandatory and optional fields. Mandatory fields include v= (version), s= (session name) and t= (time). The o= (owner) field, although not strictly mandatory per RFC, is almost always present in real implementations.

The m= (media) field is one of the most important. It describes a specific media stream and contains the media type (audio, video, text, application), port, transport protocol and list of supported codecs. In WebRTC, the most commonly used types are audio and video with transport protocols RTP/SAVPF (Secure Audio/Video Profile with Feedback) or UDP/TLS/RTP/SAVPF.

The a= (attribute) field is the most flexible and extensible. It can contain rtpmap (mapping codec number to name), fmtp (codec parameters), fingerprint (DTLS key fingerprint), ice-ufrag and ice-pwd (ICE credentials) and many other attributes. It is through attributes that SDP supports modern security mechanisms and NAT traversal.

How SDP works in WebRTC

In the WebRTC architecture, SDP serves as a signaling protocol for describing and negotiating media session parameters between two participants. SDP itself does not define the mechanism for transmitting these descriptions — this task is handled by the signaling channel, which the developer implements independently via WebSocket, HTTP or another protocol.

The process begins when the initiator (caller) creates an SDP Offer. To do this, the browser calls the createOffer() method on the RTCPeerConnection object. The generated SDP description contains all session parameters from the initiator's side: supported codecs, network addresses, ICE candidates and security requirements.

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// Add media tracks before createOffer
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Create SDP Offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Send SDP to remote peer via signaling channel
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

After creating the Offer and setting the local description via setLocalDescription(), the initiator sends the SDP string to the remote participant through the signaling channel. The remote participant, having received the SDP Offer, creates an SDP Answer and sends it back. This exchange is called signaling exchange and is a mandatory step before establishing a peer-to-peer connection.

According to the W3C WebRTC Specification, SDP exchange should occur before ICE candidates begin. In practice, many implementations send ICE candidates in parallel with SDP using the ICE trickle mechanism. This reduces connection establishment time, especially for mobile networks with high latency.

The role of ICE in SDP

ICE (Interactive Connectivity Establishment) is a mechanism that uses SDP attributes to transmit information about network candidates. ICE candidates describe possible connection paths: host (local address), srflx (address after NAT, obtained via STUN) and relay (TURN server address).

In SDP, ICE candidates are transmitted via a=candidate: attributes, as well as through ice-ufrag and ice-pwd fields for ICE traffic authentication. Each candidate includes the transport protocol (UDP, TCP), IP address, port and priority. A successful connection is established via the first candidate that passes connectivity checks. The ICE restart mechanism allows updating the connection when the network changes.

For mobile applications, ICE candidates are especially important because devices are often behind NAT or corporate firewalls. The ICE mechanism allows finding a working path even in complex network conditions, and SDP serves as the transport container for this information.

SDP security in WebRTC

SDP in WebRTC necessarily includes security attributes, particularly the DTLS fingerprint and SRTP parameters. The a=fingerprint:sha-256 field contains the fingerprint of the DTLS certificate, used for authentication and encryption of the media stream. Without this attribute, the WebRTC connection will not be established.

Additional security mechanisms include the a=setup: attribute, which defines the DTLS handshake role (active, passive, actpass), and a=ice-lite: for a simplified ICE implementation on the server side. All these parameters are transmitted inside SDP and verified by both parties before media data transmission begins.

SDP types: Offer and Answer

In the WebRTC model, there are two types of SDP messages: Offer and Answer. The Offer is created by the connection initiator and contains a complete description of the desired media session. The Answer is created by the remote participant in response to the Offer and contains their capabilities considering the constraints imposed by the offer.

The main difference between Offer and Answer lies in the semantics of attributes. The Offer lists all supported codecs, transport protocols and network addresses that the initiator can propose. The Answer selects a subset of these capabilities that the remote side supports. For example, if the Offer proposes opus, ISAC and PCMU, the Answer may select only opus as the most preferred codec.

The exchange process is governed by the W3C WebRTC specification and includes several RTCPeerConnection states. After creating the Offer via createOffer() and setting it as the local description, the connection enters the have-local-offer state. After receiving the Answer and setting it as the remote description via setRemoteDescription(), the connection enters the stable state — the final state ready for media transmission.

Using SDP in mobile SDKs

Mobile SDKs for WebRTC — Google WebRTC for Android and WebRTC.framework for iOS — fully support SDP exchange via Offer and Answer. On Android, the PeerConnection class with the createOffer() method is used to create an Offer, similar to the browser API. The resulting SDP description is transmitted as a string via the signaling channel.

On iOS, working with SDP is done through the RTCSessionDescription class from the WebRTC framework. When initializing, the type (RTCSdpTypeOffer or RTCSdpTypeAnswer) and the SDP string are specified. The platform automatically parses the SDP and configures the connection according to the passed parameters.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Create SDP Offer on Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Send SDP string to remote peer
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

The ability to work directly with the SDP string gives developers flexibility: they can modify the SDP before sending, adding or removing specific codecs, configuring ICE parameters or adding custom attributes. For Android applications, it is often necessary to disable video in SDP when network bandwidth is low — this is done by removing the corresponding m= lines from the SDP description.

SDP in mobile development

In mobile development, SDP is used primarily in the context of WebRTC — for creating applications with video calls, voice chats and streaming. Mobile applications on Android and iOS can act both as an initiator and as a receiver of SDP messages, enabling symmetric peer-to-peer connections.

A feature of mobile applications is the need to work with SDP under variable network quality conditions. When switching between Wi-Fi and mobile internet, as well as when bandwidth changes, generating a new SDP description may be required. This is done using the renegotiation mechanism — a repeated SDP exchange via createOffer() and setLocalDescription().

According to the Google WebRTC team (2023), optimizing SDP exchange for mobile devices includes using ICE restart during network changes, prioritizing low-bitrate codecs (opus for audio, VP8 for video) and minimizing the SDP string size by excluding unnecessary media streams. The key advantage is reduced delay when establishing a connection in mobile network conditions.

Optimizing SDP for mobile networks

One of the key tasks when working with SDP on mobile devices is minimizing the SDP description size. A full SDP for a typical WebRTC session with audio and video can take 2–5 KB, which is significant for slow networks. Optimization includes using BUNDLE (stream multiplexing), removing unsupported codecs and compressing ICE candidates.

An additional problem for mobile devices is the limited SDP lifetime. Under unstable connection conditions, the SDP may become obsolete before the remote participant can process it. The solution is to use short timeouts for receiving the Answer and resend the SDP if necessary. The ICE restart mechanism allows updating the connection without fully recreating the RTCPeerConnection. The a=ice-lite attribute simplifies ICE implementation on the server side.

Popular libraries for working with SDP

Mobile application developers have access to ready-made libraries that simplify working with SDP. libjingle_peerconnection (Google WebRTC) is the main library for Android, providing a full API for managing SDP. For iOS, WebRTC.framework with similar functionality is used. Both libraries automatically generate and parse SDP, but provide access to the raw SDP string when necessary.

For finer control over SDP, there are third-party solutions: sdp-transform (JavaScript or Node.js) for parsing and modifying SDP, NICENICE (Java) for working with ICE candidates, and ready-made SDKs from WebRTC infrastructure providers that handle all signaling exchange, including SDP.