Why we will Continue to Hate SDP in WebRTC for Years to Come

Or... why the hell do we need SDP in WebRTC?

People whine all the time about SDP. Saying it is too complex. It has nuances you need to know. The works.

It begs the question: why do we really need it in WebRTC?

The quick answer:

It is a necessary evil.

While WebRTC is geared towards being as simple as possible, with no options whatsoever (non-secured media streams anyone?), there are areas where WebRTC leaves things wide open, as all other VoIP systems out there:

• What codecs are supported and used in a given session? This one is left open because future advancements will bring with them better performing codecs that WebRTC will be adopting
• What limits do we see on the device for the current session? What's the resolution of the display? What's the camera's resolution? How capable is the CPU? How much bitrate can we sustain?
• What scenario are we going to do? Is it voice only? With video? Multiple channels? Only data?
• How is the network like? Do we need to change what we're doing dynamically due to the network? Can it be done on the media or do we need to renegotiate stuff to get it done based on our service's specific policy?

You see, there are a lot of things that needs to get expressed and conveyed before (and during) a media session, and to that end, we have SDP.

SDP might not be the best option, but it is what it is: it is here, and it is working.

What other options are there?

• Use H.245, which is a protocol incorporated into H.323. It is a lot more structured. And complex. And it uses ASN.1 and binary encoding scheme making it unsuitable for the task
• Write something new, which in standardization terms means delaying everything by 2-3 years at the very least – letting people start collecting the use cases, talking them through, raising various options for solutions, debating a bit more, politicking on the "best" solution, debating some, getting to a compromise that nobody likes, debating yet again, and then writing the worst possible draft

I'd go for SDP if you don't mind.

Sure – change the API on top of it that Javascript will be using, but don't expect the innards of that negotiation to change from SDP any time soon.