← View all posts
July 2, 2018

How to avoid Data Channel breaking

Contributed by Nils Ohlmeier, Hacking on real time communications since 2002

All the browser with support for negotiating data channels via SDP are using the same format. But the format is based on a specification from 2013. Since the specification has changed a lot since then it’s time to update the implementations to meet the latest spec.

Current status

If you are negotiating a data channel today in Firefox 61 (or current Chrome release) the SDP will looks something this:

m=application 63743 DTLS/SCTP 5000
a=sctpmap:5000 webrtc-datachannel 256

This is based on version 05 of the SCTP SDP draft which is from 2013.

How to update this without breaking the Web

In Firefox 53 we implemented support to handle the then current format from version 21 of the SCTP SDP draft. The new format looks like this:

m=application 54111 UDP/DTLS/SCTP webrtc-datachannel

But the problem was that the new format is incompatible with the old format. As you can see the old parser expected to find a number, 5000 in the example, where the new parser expects text, webrtc-datachannel in the second example.

If Firefox 53 would started to put the new format into it’s SDP offers, older versions of Firefox and other browsers would have rejected the SDP offer as invalid. So we did contacted the Google Chrome folks and they added support for parsing the new format into Chrome as well. Then the long waiting for Firefox ESR to be able to handle the new format started.

The change is coming

As Firefox ESR 60 now supports the new format we finally flipped the switch in Firefox 63 to start using the new data channel format in SDP offers. The SDP answer is always in the format of the offer, so old offer results in old answer, and new offer results in new answer.

And while the SCTP SDP draft has evolved to version number 26, the SDP format in there hasn’t changed any more in the recent versions. As the draft is now in the RFC editors queue we can be pretty sure the new format is going to be final format used in WebRTC 1.0.