Also, I think it might be a good idea for readers to update the article with a few notes and fixes. For example:
- SCTP-based data channels don't require messages to be less than 1200 bytes. The RTP-based data channels do. In other words, SCTP-based data channels will break up your message in chunks for you, so you don't have to when using SCTP-based data channels.
- SCTP-based data channels support binary data, so you don't need that base64 encoding when using SCTP-based data channels.
- SCTP-based data channels always do congestion control, so any "flow control" in JS is really just controlling how much data gets buffered by the browser. It's a good idea not to make that grow too large, but it doesn't effect what is sent on the network, unless you let the buffer go empty.
- It is not correct to say "to optimize transfer speeds, unreliability is key". Doing reliability yourself on top of unreliabile mode in JS will not be any faster. In fact, it will probably be slower. What you may want is unordered data, meaning you can get the file chunks out of order. But that won't speed up getting the whole file; it will just speed up getting a particular chunk. If I were you, I would use reliable, but perhaps unordered mode, which SCTP-based data channels support.
- The bandwidth hack for sending more than 30kpbs with RTP-based data channels is probably a bug, and I wouldn't recommend relying on it.
- WebRTC always uses ICE, so it's not accurate to say "ICE or just STUN", it's more like "ICE with TURN or ICE without TURN". Either way, it's still using ICE.