My First Post: WebRTC DataChannels Walkthrough Part 0

11 May 2013

WebRTC DataChannels Walkthrough Part 0:

Recently , I found myself playing around with WebRTC and its DataChannels concept. I’ve been using the chrome canary builds in conjunction with PeerJS to experiment a bit with the technology. In this post I want to just give a brief introduction to WebRTC and start what will be a three part series detailing some of the internals of how WebRTC is working from a consumer side, be that Javascript WebRTC api, or talking to a server that’s attempting to host a WebRTC app.

What is WebRTC ?

WebRTC is an api that is cross-browser compatible aimed at making p2p communications, be that voip,video streaming , or plain data transfer easier and seamless. This means no plugins, flash hacks , or proprietary video codecs.Essentially , the people at Google and Mozilla had a chat and said lets do this without licensing and alienating everyone from using the much needed unified set of tools to do p2p smoothly, the result is WebRTC and seen in the following

[Demo] (http://www.youtube.com/watch?feature=player_embedded&v=E8C8ouiXHHk) &[Talk] (http://www.youtube.com/watch?v=E8C8ouiXHHk)

How’s it work ?

WebRTC is a combination of Javascript, and C++ native libs to handle SIP and RTP type communication. It handles jitter, synchronization, connectivity loss, most of the difficulties associated with voip and p2p applications.

From a web developers standpoint its a set of simple javascript apis that make generating p2p applications accessible for a broad class of developers. These apis then talk to ICE/STUN servers on the backend or google app engine :(. The servers then coordinate the transportation logic between the two peers and the data is then shuffled between the peers with heartbeats and status type information handled by the ICE/STUN servers, i.e. mediastream changes or a peer connection is dropped etc..

Some Terms:

WebRTC’s network uses several technologies that are used in Voip apps like Skype, so some I’ve included some high level breakdown of the techniques and protocols used . I’ve also included some documentation I’ve found useful in understanding what they do.

NAT -> Network Address Translation

Act of mapping one or many ips to another. Typically a private network may have many internal ips and one public ip.

STUN-> Session Traversal Utilities for NAT

Allows an application to determine its public facing ip and port address , if it is behind a NAT. [2008 Talk ICE Stephen Strowes] (http://sdstrowes.co.uk/talks/20081031-ice-turn-stun-tutorial.pdf)

TURN -> Traversal Using Relays around NAT

Turn is a protocol that allows for data to be received behind a NAT. It supports marshaling a connection to a single peer. [2008 Talk ICE Stephen Strowes] (http://sdstrowes.co.uk/talks/20081031-ice-turn-stun-tutorial.pdf)

ICE -> Interactive Connectivity Establishment

ICE is a technique to allow for peer to peer communication behind a NAT. ICE uses STUN and TURN to generate candidates ( potential ip addresses) for receiving and sending data. [JDRosen ICE tutorial]http://www.jdrosen.net/papers/ice-basic-tutorial.pdf

SDP -> Session Description Protocol - is a protocol used to describe

multimedia sessions to enable clients join a session or gather information about a session [SDP Wiki] (https://en.wikipedia.org/wiki/Session_Description_Protocol)

Preview of Next Post: A Deeper Look at Web RTC Part 1:

I point to the PeerJS Hello Example ,because its simple enough to go over, I’m taking the approach of explaining what it does underneath the hood, at each step from creation of the RTCPeerConnection to sending data accross the data channels. .

comments powered by Disqus