Key WebRTC data channel characteristics (#3)

Jan. 16, 2015

After exploring how the SCTP implementation changed WebRTC forever and for the better, in this post, we will go over the main characteristics of WebRTC data channel's latest implementations.

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


The data channel (DC) is message-oriented. This means that when a message is sent, either the whole message is delivered, or no message at all (it is lost). This is in contrast to stream protocols that deliver an endless stream of bytes that has no clear structure or message delimiters. There is a bug in Chrome that causes messages larger than 64 KBytes to be split in two or more smaller messages. In effect, when you send one message, on the receiving side you get two! Obviously, this is a violation of the message-orientedness characteristic, and therefore, a bug, not a feature! Hopefully, it will be fixed soon.


As was already mentioned in the previous post, WebRTC’s jump forward: SCTP-based implementation, the DC is reliable. A message will either be delivered or an error will be reported and the DC closed. There is also checksumming built into the SCTP protocol.


SCTP is a protocol that is positioned at the same layer as TCP and UDP. This means and it has low overhead and is suitable for a wide range of problems. Support for SCTP is built-into most (if not all) routers, which makes it routable on the Internet.


An important advantage of the DC is the fact that all messages sent over it are encrypted. There is no way to turn encryption off. This is a splendid feature and a brilliant idea because usually encrypting messages (through OpenSSL or a similar library) is a huge pain in the neck and developers either do not do it at all or do it in a buggy and insecure manner. However, a warning is in order - one should not get too confident with the security of WebRTC! The mere fact that data sent over the DC is encrypted does not make an application secure. Developing a truly secure application is a wide subject and encrypting data is just a part of it.

Attention should be payed to signaling. In certain situations, passwords that will later be used for encrypting the data may be transmitted as part of the SDP messages exchanged during signaling. Because of that, a secure channel should always be used for signaling. Examples of such channels include wss (websocket secure) and https (http secure).

The next publication on the DC will cover signaling: how to set it up and what to be wary of. 

[Go to Post #4: WebRTC data channel: signaling and connecting]

Author: Svetlin Mladenov, Chief Architect