WebRTC 101

What is webRTC?

WebRTC is a technology designed to allow realtime, direct communication between browsers (and browser-like software) without requiring third party plugins. WebRTC is being used to enable applications like video or audio calling directly within the browser. WebRTC usually does not route the connection through a central server– but directly from one user to another, which means it has less latency and is more scalable than other methods of streaming data from a browser.

WebRTC is an umbrella term that covers three JavaScript APIs:

  • MediaStream: AKA ‘getUserMedia’. Allows capturing audio and video from webcams, microphones and screen sharing.
  • RTCPeerConnection: Allows direct peer to peer ‘calling’ (transmission of media streams) from one browser to another. Example uses include voice-over-ip calling or video conferencing.
  • RTCDataChannel: Realtime peer to peer transmission of arbitrary data.

Support for these technologies vary greatly between browsers. Claims that a browser ‘supports webRTC’ can mean that the browser supports any of these APIs.

What is signaling? What is STUN, TURN, and ICE?

Signaling, STUN and TURN are not part of webRTC, but you’ll need to know about them to write real world applications using webRTC.

Signaling, STUN and TURN exist because the internet and media streaming are messy. To connect with another peer, your browser needs to know that peer’s IP address, what transport protocols the other browser supports, and what types of media it can accept.

Signaling is communication outside of webRTC that is used to convey information needed to start and maintain a webRTC connection to other peers. For example:

  • Announcing that you are starting a stream
  • Indicating that you are ending a stream
  • Sharing your ‘external’ (internet reachable) IP address
  • Listing types of audio and video this client can accept

How you send your signaling data is up to you. The webRTC spec and APIs don’t cover this. For example, you can do signaling via AJAX or Web Sockets.

STUN and TURN are protocols for connecting peers in messy real world networks– through firewalls and routers. STUN and TURN are not just used in WebRTC, but many kinds of networked applications. TURN requires a server. Public TURN servers are available or you can host your own.

ICE is a framework for connecting peers. ICE tries to connect the clients directly, and if that doesn’t work, it falls back to using STUN/TURN.

How do I build my first webRTC app?

WebRTC can be intimidating. The best way to get started is to break the process up into more manageable pieces. You only need to learn one part of WebRTC at a time.

  1. Use MediaStream: Build a page that just gets video from a webcam and displays it in a video element.
  2. Use RTCPeerConnection: extend your application by using two RTCPeerConnections on one page. One is for sending the video stream, and one is for displaying it. You can mostly forget about signaling for now: the two clients are in the same browser session so they can talk directly.
  3. Set up simple signaling: use an off-the-shelf signaling library. Get this working for two separate browsers on the same computer.
  4. Set up STUN/TURN: this is easier than you would think! You only have to pass another configuration parameter into RTCPeerConnection. Use google’s public STUN servers to test. You should be able to connect across networks reliably now.
  5. Celebrate! You have built your first WebRTC application.

More WebRTC Info

More Posts by Robert Prehn: