How to Build a WebRTC Architecture

palava is based on current web standards and uses the emerging WebRTC for its core video functionality. This article will help to explain how everything works together.


WebRTC is quite new, but it has the potential to change the way we think about the internet. From the beginning, the World Wide Web was based on client server communication. A client (e.g. your computer or mobile phone) contacts a server and uses its web pages and services.

With WebRTC, the client is now not only able to communicate with an always-running server but also with other clients. This paradigm is called peer-to-peer (P2P) and when interacting with other internet users directly (chatting, calling, file sharing, collaborative working), P2P communication is exactly what you want. Since the data is exchanged directly between you and the other participant via an encrypted channel, it never passes the server. This is good for the server operator because there is no need for expensive hardware. Even more importantly, this concept allows a high level of privacy and security for the user. We will not be able to see your video data (or any links you exchange)!

WebRTC is currently implemented in Googles Chrome and in Firefox 22 (release is planned for June 25, 2013 - but it is already available as Firefox Beta). The other browsers will, hopefully, follow soon.

General Architecture and Workflow

Even though none of the video data will ever pass a server, we still need some server software as an intermediary. Its role is to coordinate the peers.

Our central server acts as a simple messaging server. All the clients that join the same chat room can send messages to other peers in that room. We implemented the server part using Ruby-EventMachine and redis. The client parts are written in CoffeeScript using WebRTC and will be available as open source in the near future.

Let us have a look at the workflow of a palava session:

  1. A new user joins a room and gets a list of the existing clients.
  2. The other clients get notified of the new communication partner by the server and add it to their own internal client list. They create a PeerConnection object, later used as a handle for the direct communication, for the new user and add their local stream. The actual P2P connection is not yet established, it still needs to be negotiated.
  3. The new user tries to establish a peer connection to the other clients. He, in turn, creates a PeerConnection object for every client, adds his local stream returned by the getUserMedia function (usually originating from a webcam and a microphone) and sends the resulting SDP object (a session descriptor defining the support of media types and capabilities, see SDP protocol) to the corresponding client using the message server.
  4. Each contacted peer updates his PeerConnection object with the remote SDP object and responds by sending an answer with his own SDP object.
  5. The new user updates his PeerConnection objects with the received SDP. The connections are now established and everything else (e.g. NAT traversal via STUN or optionally TURN) is handled internally by the browsers WebRTC implementation
  6. Using the PeerConnection objects, we ask for the remote stream handles (the video and audio of our peer!) and once we connect the stream to an HTML5 video element, the users are able to see and hear each other!


As you can see, there is much to be excited about WebRTC. And the best: it is an open standard and not controlled by a single corporation! We love this and we are happy to be able to offer palava to you as a free service!

If you like palava, please help us: Use it, send us some feedback ( and tell all your friends about it!

Creative Commons Lizenzvertrag Marius Melzer (