SDP Format for WebRTC: Media Negotiation Essentials and Its Relationship to SIP INVITE

SDP (Session Description Protocol) is the core session description format used by WebRTC to carry media negotiation and connection parameters. SIP (Session Initiation Protocol) is a signaling protocol. This article focuses on SDP in WebRTC and explains its differences and relationship with SIP INVITE.

SDP fundamentals and positioning

SDP is defined by RFC 4566 as a text-based session description format. It expresses parameters of a multimedia session; it is not a transport/signaling protocol. In WebRTC, SDP conveys media capabilities and negotiation parameters.

SDP quick facts

Item	Meaning	Example
Standards doc	Defines the content format of SDP	RFC 4566
Format type	Session description (plain text)	key-value / line semantics
Primary use	Media session description	codecs, bandwidth, direction, etc.
WebRTC host	Object that holds SDP	RTCSessionDescription (offer/answer)

What SDP describes

Media line cheatsheet

Info type	SDP marker	Meaning	Common values
Media line	m=	Media stream type	audio, video, application
Connection	c=	Network address	IN IP4 0.0.0.0
Attributes	a=	Media/session attributes	rtpmap, ice-ufrag, sendrecv
Session info	s=	Session name	- (often empty)
Timing	t=	Session time	0 0 (permanent)

Common codec mappings

Media	Codec	PT	Clock	Notes
audio	Opus	111	48000/2	High quality, low latency
audio	PCMU	0	8000	G.711
audio	PCMA	8	8000	G.711
video	VP8	96	90000	Open
video	VP9	98	90000	Efficient
video	H.264	97	90000	Widely supported

Offer/Answer in WebRTC

SDP exchange sequence (WebRTC)

sequenceDiagram
    participant A as Caller
    participant S as Signaling Server
    participant B as Callee

    A->>S: Send Offer (SDP)
    S->>B: Forward Offer (SDP)
    B->>S: Send Answer (SDP)
    S->>A: Forward Answer (SDP)
    Note over A,B: Offer/Answer complete → media starts

SDP state table (WebRTC)

Stage	Caller state	Callee state	SDP type	Description
1	Create Offer	Waiting	offer	Caller generates local media capability description
2	Waiting for Answer	Process Offer	offer	Callee sets remote description
3	Waiting for Answer	Create Answer	answer	Callee generates answer description
4	Process Answer	Waiting for connection	answer	Caller sets remote description
5	Connected	Connected	-	Media negotiation completed

SDP and SIP INVITE: differences and relationship

Conclusion first: SDP is the “description”; SIP INVITE is the “signaling carrier”. In a typical SIP call, the INVITE body carries SDP (Offer); the peer returns SDP (Answer) in 200 OK, completing the Offer/Answer model—conceptually the same as in WebRTC.

Concept map

Dimension	SDP (description format)	SIP INVITE (signaling request)	Relationship
Positioning	Text format describing media/session parameters	Request method to initiate/modify/terminate a session	INVITE body may carry SDP
Function	Codecs, media direction, bandwidth, network	Call control and routing	Signaling carries description
Standard	RFC 4566	RFC 3261 (and extensions)	Different specs, complementary
Negotiation	Offer/Answer (RFC 3264)	Driven by INVITE/200 OK/ACK	Offer/Answer embedded in SIP

SIP sequence with SDP (maps to Offer/Answer)

sequenceDiagram
    participant UAC as UAC (Caller)
    participant Proxy as SIP Proxy
    participant UAS as UAS (Callee)

    UAC->>Proxy: INVITE (SDP = Offer)
    Proxy->>UAS: INVITE (SDP = Offer)
    UAS-->>Proxy: 180 / 183 (optional, early media)
    UAS->>Proxy: 200 OK (SDP = Answer)
    Proxy->>UAC: 200 OK (SDP = Answer)
    UAC->>Proxy: ACK
    Proxy->>UAS: ACK
    Note over UAC,UAS: Media (RTP/RTCP) can start

SIP INVITE key fields

Element	Location	Example/Notes	Purpose
Method	Start-line	INVITE sip:[email protected] SIP/2.0	Initiate session
Routing	Headers	Via/Route/Record-Route	Path propagation/recording
Identity	Headers	Call-ID / From / To / CSeq	Identify session and order
Capabilities	Headers	Contact / Allow / Supported	Terminal features
Payload type	Headers	Content-Type: application/sdp	Declare body type
Description	Body	SDP text (Offer/Answer)	Carry media parameters

Mapping to WebRTC signaling

Step	SIP world	WebRTC world	Commonality
Offer generated	INVITE with SDP	createOffer()/setLocalDescription	Local capability description
Answer returned	200 OK with SDP	createAnswer()/setLocalDescription	Answer capability description
Confirmation	ACK	setRemoteDescription(Answer)	Agreement reached
Transport	SIP signaling (UDP/TCP/TLS)	Custom signaling (WS, etc.)	Carry SDP, drive negotiation

Common misconceptions

• SDP is a session description format, not a protocol; it does not transport signaling.
• SIP is a signaling protocol; it can carry SDP in message bodies. WebRTC uses custom signaling to carry SDP as well.
• Offer/Answer (RFC 3264) is a negotiation model used in both SIP (INVITE/200 OK/ACK) and WebRTC (createOffer/createAnswer).
• Media (RTP/RTCP) and signaling (SIP/custom) are layered and separate: media transports streams; signaling orchestrates negotiation/routing.

SIP–WebRTC interop (supplement)

Protocol comparison

Feature	WebRTC	SIP	Common
Transport	UDP/TLS/RTP/SAVPF	RTP/AVP	RTP media layer
Security	DTLS mandatory	Optional TLS	Encryption supported
NAT traversal	ICE required	Optional STUN/TURN	Connectivity
Session description	SDP (format)	SDP (format)	Same content format, different signaling carriers
Signaling	Custom (WebSocket, etc.)	SIP stack	Different implementations

Interop architecture

graph TB
    subgraph "WebRTC"
        W1[Browser] --> W2[WebRTC API]
        W2 --> W3[SDP Offer/Answer]
    end
    
    subgraph "Gateway"
        G1[Protocol Gateway]
        G2[SDP Adaptation]
        G3[Media Relay]
    end
    
    subgraph "SIP"
        S1[SIP Client] --> S2[SIP Stack]
        S2 --> S3[SDP Handling]
    end
    
    W3 --> G1
    G1 --> G2
    G2 --> G3
    G3 --> S3

SDP adaptation cheat sheet

WebRTC attr	SIP equivalent	Action
UDP/TLS/RTP/SAVPF	RTP/AVP	Rename transport profile
a=ice-ufrag	n/a	Remove
a=ice-pwd	n/a	Remove
a=fingerprint	n/a	Remove DTLS fingerprint
a=setup:actpass	n/a	Remove DTLS setup
a=mid	n/a	Remove media ID

Use cases

Scenario	WebRTC strengths	SIP strengths	Interop value
Enterprise UC	Browser-native access	Mature PBX	Unified platform
Contact center	Fast rollout	Stability	Hybrid agent
Mobile apps	Native integration	Carrier interop	End-to-end reach
Video meetings	Rich media	Standards	Cross-platform

Troubleshooting and optimization

Diagnostic matrix

Symptom	Likely cause	SDP checkpoint	Fix
No audio	Codec mismatch	a=rtpmap (audio)	Align codec set
No video	Video negotiation failure	a=rtpmap (video)	Ensure VP8/H.264
Failed connect	ICE issues	a=ice-ufrag/pwd	Check STUN/TURN
Poor quality	Codec choice	Payload order	Reorder codecs
High latency	Bandwidth limit	b=AS line	Tune bitrate

Signaling state (WebRTC)

stateDiagram-v2
    [*] --> stable: initial
    stable --> have_local_offer: createOffer()
    have_local_offer --> stable: setRemoteDescription(answer)
    stable --> have_remote_offer: setRemoteDescription(offer)
    have_remote_offer --> stable: setLocalDescription(answer)
    
    have_local_offer --> have_local_offer: setLocalDescription(offer)
    have_remote_offer --> have_remote_offer: setRemoteDescription(offer)
    
    stable --> closed: close()
    have_local_offer --> closed: close()
    have_remote_offer --> closed: close()

Optimization cheat sheet

Goal	SDP tweak	Example	When
Lower latency	Codec priority	Opus > PCMU	Realtime calls
Save bandwidth	Limit bitrate	b=AS:500	Mobile networks
Better quality	High profile	H.264 High Profile	Conferences
Compatibility	Baseline codecs	PCMU/PCMA	Legacy interop