Looking for good programming challenges?

Use the search below to find our solutions for selected questions!

Random video chat website using WebRTC

Seing as how many people are interested in my video-conference-webrtc project, I have decided to develop a random video chat website using WebRTC. The project is called rtcrandom and is hosted on GitHub. A live demo is also available at test.tengmo.chat.


RTCRandom is an online (video)chat website that allows users to socialize with others without the need to register. The service       randomly pairs users in one-on-one chat sessions where they chat anonymously using the names “You” and “Stranger”.

For the project I have used GitHub for my online project hosting service using Git, issue tracking, collaboration and wikis. Node.js and JavaScript are the main programming languages used for development. For continuous integration I am using Jenkins with OpenShift as my hosting service. The wiki is available here.

I not going into great detail explaining the code. I will rather give you a brief overview on how rtcrandom works and leave the pleasure of examining the code to you.

For the back-end Node.js is used with Express as the web application framework. I used winston for logging and EJS as the templating language for the views.

For the front-end simple HTML with JavaScript (jQuery, socket.io) and CSS is used. In order to add WebRTC support for browsers like Safari (which does not support WebRTC yet) I have used the Temasys WebRTC adapter. If you do not wish to use such an adapter see release v0.1-alpha.

Main components
On the back-end the main component is server.js and on the front-end the magic happens in public/js/room.js, which is loaded by the views/room.ejs view.

How does the matching work
When a client first loads the page a bidirectional event-based communication is created between the client’s browser and the back-end using socket.io. I call this the default communication channel. The default communication channel is used by the client to let the server know, that the client wants to find a new chat partner etc. It also allows the server to inform a client about a new chat partner etc.

So once a client wants to find a new (or initial) communication partner he triggers a next event through the default communication channel, letting the server know about its ID and that he wants a new chat partner. The ID is a random hash that is generated once on client-side. The server then puts the client’s request into a queue and checks if the queue has at least two requests (note: no client is put twice in the queue). If at least two requests are in the queue (one from a different client and one from our current client), the two clients are polled from the queue. The server then generates a random room name (a random six digit alphanumeric string) and sends it to the two clients via the default communication channel.

Once each client receives the new room name, they send a message to the server via the default channel that they want to join the room. The client whose message arrives first at the server creates and joins the room and the second client simply joins the new room. The peer that simply joins the new room gets notified by the server that it just joined, so that it can broadcast the message to the default channel saying that it is a new participant that joined the room and wants to receive a WebRTC offer to open up a peer-to-peer WebRTC communication with the other client in the room (the one that created the room). The room creator then receives the new participant message in the default channel and creates an offer for the joining peer. This offer will be send via a private communication channel which both clients open using the room name as namespace. The room creator then sends the offer through this channel, which the other peer receives and responds to with an answer. Further WebRTC related communication messages to build the WebRTC peer-to-peer connection between the two clients are also exchanged through the private channel. Once a peer-to-peer connection is establish the video stream and chat messages are exchanged directly between the two clients (no server required).

Note: when a peer disconnects from one peer (e.g. because it wants to chat with a different person) the disconnect event is not immediately received by the other peer, due to WebRTC delays. This is why the disconnecting peer also sends a disconnect notification message to the other peer via the private channel, so that it can update its view. The notification is send using the private channel because it tends to be faster than waiting for the WebRTC notifications.

The source code is available here. A live demo is available at test.tengmo.chat.