WebRTC’s jump forward: SCTP-based implementation (Post #2)

Jan. 7, 2015

This text is the second in a series of publications on the topic of the WebRTC data channel. At the end of the previous post, we left WebRTC back in year 2013, problem-ridden, though full of potential. Time for redemption.

[Go to Post#1: WebRTC Data Channel: An Overview]

Around December 2013, a new implementation of the data channel (DC) based on the Stream Control Transmission Protocol (SCTP) was released. It replaced the previous “lazy” RTP protocol and solved many of the issues it created for WebRTC users. This happened around the time of Chrome v30, but it took a couple of months to smooth out issues so the first version that got everything right was Chrome 33. The situation with Firefox was similar: the SCTP-based DC was released in Firefox 26-27.

SCTP is a feature-rich protocol that does a lot of things. One important feature is traffic and congestion control, something that used to be a gaping void in the RTP-based WebRTC. This means no more artificial throttling and, therefore, a much, much faster DC. As fast, in fact, as the network can handle; no other speed limits.

Besides the speed limit, the new SCTP-based implementation also removed the message size limitation; size is no longer network dependent. One can now also send messages over 1 KByte in size without a problem. Presently, SCTP supports messages of up to 64 KBytes and the DC implements some additional functionality on top to allow messages larger than 64 KBytes. So, at least in theory, messages larger than 64 Kbytes should be supported. However, there are still a couple of issues in the current WebRTC implementations that interfere with sending large messages. More on this latter.

Another major improvement the new version brought is support for binary messages. So now one can indeed send all kinds of data, regardless of its nature. No more of that Base64 encoding madness.

And, finally, SCTP also allows for a reliable mode of operation. If a message is lost, the DC will retransmit it again and again until the message is delivered or the connection is deemed broken.

The SCTP based implementation fixed previous limitations and made the DC what it should had been initially - a general-purpose communication technology suitable for a variety of problem domains far beyond just chats.

[Go to Post #3: Key WebRTC data channel characteristics]

Author: Svetlin Mladenov, Chief Architect