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.
Or there’s Jingle, of course, which is XML, and has the interesting property that transport and content are better separated. But for once, I won’t bang this drum, because Philipp proved you could transform between SDP and Jingle pretty easily in client-side javascript.
The point is really that you need an interoperable method of describing sessions. And that needs to be standardized. And SDP already is.
Well… Actually, of course, we could have decided that browsers would expose all the information purely as Javascript APIs, and have webapp developers cook their own session description protocols. But that would be insane – although amusingly, it’s what you argue for federation and signalling layers all the time.
Dave,
SDP is fine for me. There needs to be *something* to express this level of abstraction between browsers for WebRTC to work at all. SDP was there already, so it got used. And it isn’t going anywhere.
How is possible that you do not mention ORTC in your article? Is it a joke?
Go for SDP and be happy, but I don’t think you really understand what comes with it.
My point here was the fact that SDP is going to be with us for some time. Even before WebRTC there were those who hated SDP for what it is. How is ORTC going to change that? Do you see it get standardized and fully adopted in 12 months?
So, SDP is good enough just because it has been definitely mandated by Google and Cisco in WebRTC, and since it is hard to expect that the alternative (ORTC) becomes a standard then SDP is OK.
What are we talking about? Is this a technical discussion? or a “that’s what we have, so go on” resignation?
As a wise saying says “perfect is the enemy of good”.
I had the same feelings as you had, but I grew up. Standardization is a process of compromise between vendors – usally oes that care about their business more than they care about their customers or the end users. As such, the resulting standards are there to serve a purpose that might not be the one of best intentions of the community at large.
In the case of WebRTC, I’d vote for having SDP as it is now defined and implemented for WebRTC and have the spec approved as soon as possilble, than have people bicker around ORTC for another 2 years. I vote for pragmatism over perfection.
There is nothing wrong with SDP per-se. However, explicitly exposing SDP in the API is an unnecessary evil. SDP is a very poor API surface and it would be relatively trivial to replace it with an object-oriented API. You can still use SDP under the hood, if you so wish, but it would become an implementation detail.
While this is true on the client side, it isn’t on the server side.
Servers who wish to play this game need to deal with SDP directly – there’s no WebRTC package for them to handle it.
Which is a mistake which I’ve brought to Justin’s attention. The WebRTC “Native API” should shield the server from this kind of implementation-detail. The server should just be another peer (albeit a headless one).