What if WebRTC SDP Munging was Prohibited?

How will we be able to live in a world without… SDP?

The one thing I love best about the WebRTC Standards website is that it looks at a place I neglect most of the time – the IETF and W3C. While I had my share of dealings with standardizaton organizations when I was young and pretty, it isn’t something I like doing much these days.

Last month, it seems a decision was made/in the process of being made – to prohibit SDP munging. As these things go, if this happens at all it will take VERY long to happen. That said, such a change will have huge impact on a lot of services that make use of this practice.

What’s WebRTC SDP munging?

SDP munging is a process of a WebRTC application taking its future in its own hands and deciding to change the SDP. With WebRTC, once the application sets the user media and connects it with a peer connection (=setting up to start a session), it receives the SDP blob that needs to be sent to the other participant in the session. This blob holds all of its capabilities and intents for the session.

If you want to learn more about the contents of the SDP, then this article on webrtcHacks will get you started.

Here’s a quick flow of what happens:

Now that the application holds the SDP blob, the question that must be asked is what can the application should/can do with this SDP blob?

1. The application should pass it to the other participant. Probably by placing it in an HTTP request or a Websocket message
2. The application can change it (=mung it) before well… setting and sending it

The problem is in that second part.

What’s the problem with WebRTC SDP munging?

SDP embodies everything that is wrong about SIP. Or at least some of what’s wrong about SIP 🙂

There are several aspects to it:

1. Being a textual kind of a protocol that is open as hell, it is open to interpretation of humans, making it hard to use. Interoperability is a headache with it, and now we’re leaving it at the hands of web developers. It becomes doubly hard, as there are extensions to SDP – some standardized, some in process and some just proprietary ones. And you need to sift between them all to decide what to do on the SDP level
2. When you modify the SDP, it is assumed that the browser needs to interpret your modifications. Since it already created an SDP, it had its own understanding of what you want, but now he needs to interpret it yet again but instead of doing that through an API, it needs to do it via an ugly text blob. And browsers are created by humans, so they might not interpret it the same way you did when you munged it – or different browsers might interpret it differently
3. New browser versions might not be able to interpret what you munged simply because that isn’t part of their main focus. The smaller you are, the more susceptible you will be to practicing SDP munging – what you do there might not be as popular as you though (or not defined as popular by browser vendors) – and it will break in some future version
4. SDP isn’t that fun to modify with JavaScript. So it frustrates developers which ends up leading to more bugs and inconsistencies

What happens if and when it gets prohibited?

When SDP munging gets banned, existing applications that rely on it will break.

They might break completely, but mostly, they’ll break in ways that are less predictable – codecs won’t be configured in the exact way the developer intended, bitrates won’t be controlled properly, etc.

The whole idea behind SDP munging is to get more control over what the browser decides to do by default, so disabling it means losing that control you had.

When is this change expected?

Not soon, if at all.

That said, I wouldn’t recommend ignoring it.

What I’ve understood is that there’s little chatter about this on the standards mailing lists, so this just might die out.

The reason I think it is important is because at the end of the day, munging the SDP leaves you prone to whims of browser vendors as well as leaves you open to this future option of banning SDP munging.

What should you do about it?

First of all – don’t worry. This one will take time. That said, better plan ahead of time and not be surprised in the future. Here’s what I’d do:

1. Refrain from practicing SDP munging as much as possible
2. Since we’re already starting to see some of the ORTC APIs tricking into WebRTC, you should make an active investment now and in the near future to use these APIs whenever you feel the urge to make changes in the SDP (that’s assuming what you need is supported in the API level and not only via the SDP)
3. If you aren’t sure, then check the code you have to see if you are practicing SDP munging, and if you are, make some kind of a plan on how to wean yourself from it