Why is SDP used in WebRTC?

5 Jun 2025 · 1 min

Watch on YouTube

1:10

Short conversational excerpt from a video titled "Why is SDP used in WebRTC?" Speakers explain why SDP became the signaling/description format in WebRTC: around 2011 the community chose an existing format for signaling, attempts to replace SDP (e.g., "STP Next Generation") failed, and SDP is now effectively baked into the WebRTC API. SDP is described as the compact string/blob that conveys what a peer can/can't do inside a call (media types: voice/video, who sends/receives, ports and IPs, supported codecs). Speakers note dislike for SDP but accept it as a working API surface even if implementations may not use it on-the-wire.

Here's a big one. Why is SSDP used in WebRTC?
Well, because in 2011, everybody was like, okay, we need to use something for signaling, something as the API service. And everybody's like, okay, let's use SDP for now. At that point, people had tried to replace SDP with something called STP Next Generation nge, but that didn't work out. And we keep saying we will stop using sdp, but by now it's baked into the API. There's no good way to replace it.
I think it's too much work and effort. And we have sdp. We love to hate it, but it's working.
Yes, it's working. We built our systems. We may not use SDP on the wire, but it's okay as an API surface.
Yes. And if we look at why we need something like that, it's because we want to convey within the call what we can and can't do. For example, is this only voice or video, who is sending, who is receiving, which ports and IP addresses do I want to use and which codecs am I even supporting?
Yes. And stp, this STP blob just gives you all that information in a string. You just take it, send it to the other side and you're done.
Okay?