Building WebRTC Video Chat Applications

Building WebRTC Video Chat Applications – SitePointSkip to main contentFree JavaScript Book!Write powerful, clean and maintainable JavaScript.RRP $11.95 With the advent of WebRTC and the increasing capacity of browsers to handle peer-to-peer communications in real time, it’s easier than ever to build real-time applications. In this article, we’ll take a look at SimpleWebRTC and how we can use the platform in implementing WebRTC technology. We’ll also look at other alternatives that could help us achieve the same goal.
If you need a bit of background regarding WebRTC and peer-to-peer communication, I recommend reading “The Dawn of WebRTC” and “An Introduction to the getUserMedia API”.
Due to the complex nature of building custom WebRTC applications, this won’t be a step-by-step tutorial on building one. Instead, we’ll look at the libraries and the types of servers required to build your own reliable app. I’ll provide links of complete sample apps you can refer to while building yours.
Our focus will mainly be on SimpleWebRTC as a platform. Later on, we’ll briefly look at other commercial and open-source alternatives that may help you accomplish the same.
What WebRTC Is
WebRTC (Web Real Time Communication) is an open-source project that allows peer-to-peer, real-time communication between web browsers to stream live video, audio and data streams over a network. Modern desktop and mobile browsers such as Google Chrome, Mozilla Firefox, Safari, Opera and other Chromium-based browsers have already implemented this technology natively. This is good news, as users don’t have to install a third-party plugin or an app to access the technology.
Older browser versions and legacy browsers such as Internet Explorer don’t have this technology. Users will need to use up-to-date browsers. You can check the full list of supported browsers:

In January 2021, the WebRTC 1.0 specification was transitioned from Candidate Recommendation to Recommendation status by the World Wide Web Consortium. This is a remarkable achievement considering the technology was first released into the public 10 years ago.
The WebRTC specification covers how browsers can access local media devices and how they can transmit media and generic application data to a browser using a set of real-time protocols. It does this through a set of JavaScript APIs which have already been covered by the articles linked to earlier. The specification also ensures that all communication is encrypted and that unwanted third parties can’t eavesdrop into the streams.
It’s important to note that WebRTC doesn’t cover everything such as signaling, the process of initiating a connection between browsers. This part of the specification was left out in order to prevent limitations with potentially new technology. A second reason was that WebRTC is primarily client-side technology, and issues such as sessions are best handled using server technology.
How Signaling Works for Web Browsers
The very definition of WebRTC is peer-to-peer communication between web browsers. The reality is, most browsers run in computers that operate behind a NAT (network address translation) device, and optionally a firewall. The NAT device, usually a router or modem, allows computers with private IP addresses to connect to the Internet via a single public IP address.
NAT devices protect personal computers from being directly exploited by malicious users over the Internet via the IP address. Unfortunately, it also blocks devices with private IP addresses from connecting to another private IP device over the Internet.
To overcome this challenge, the ICE (Interactive Connectivity Establishment) protocol was proposed by the Internet Engineering Task Force to allow private IP computers to discover and connect to other private computers over the public network.
This involves the use of a public signaling server that both clients can easily connect to. The peer computers connect to this server and use it to exchange IP addresses and ports required for the data sources and sinks. With this information, they can establish direct connection with each other and start streaming video, audio and data.
Here’s an animated demonstration:

Photo credit: WebRTC Signaling
To set up WebRTC signaling, the ICE framework requires you to provide two types of servers, detailed below.
1. STUN Server
The STUN (Session Traversal Utilities for NAT) server does exactly what I’ve just described above. It simply provides a meeting space for computers to exchange contact information. Once the information is exchanged, a connection is established between the peer computers and then the STUN server is left out of the rest of the conversation.
Here’s an example script that runs on the client, which allows the browser to initiate connection through a STUN server. The script allows for multiple STUN server URLs to be provided in case one fails:
function createPeerConnection() {
myPeerConnection = new RTCPeerConnection({
iceServers: [
urls: “”,

Connections established via STUN servers are the most ideal and cost-effective type of WebRTC communication. There’s hardly any running cost incurred by the users. Unfortunately, the connection may fail to establish for some users due to the type of NAT device each peer is using. In such a situation, the ICE protocol requires you to provide a fallback, which is a different type of signaling server known as a TURN server.
2. TURN Server
A TURN (Traversal Using Relay NAT) server is an extension of the STUN server. Where it differs from its predecessor is that it handles the entire communication session.
Basically, after establishing a connection between the peers, it receives streams from one peer and relays it to the other, and vice versa. This type of communication is more expensive and the host has to pay for the processing and bandwidth load required to operate a TURN server.
Below is a graphical depiction of the entire signaling process involving first the STUN server and then the TURN server as fallback:

Photo credit: A complete architectural diagram showing the whole WebRTC process.
Building a Custom Video Chat Application
While it’s possible to set up your own video chat solution using plain JavaScript code and free public STUN servers, not everyone will be able to connect with each other on your platform. Using TURN servers is mandatory if you want to provide a reliable service to all your users.
As mentioned earlier, setting up WebRTC platforms can be complex. Fortunately for us, we have all-in-one commercial platforms that make building a WebRTC video chat application a breeze. Let’s now look at how SimpleWebRTC can lift our burdens.
What SimpleWebRTC Is
SimpleWebRTC is a platform that provides an easy and cost-effective service for developers to build and deploy custom real-time applications using React. Specifically, they provide the following:
SimpleWebRTC SDK: a front-end library
Hosting: STUN/TURN and SFU (Selective Forward Unit) servers
Technical support
Custom app development and WebRTC consulting services
Single-tenant and on-premise infrastructure
Talky: a free video chat app built entirely with SimpleWebRTC
Below are sample screenshots of some of the custom video chat projects they’ve helped their clients develop and launch.

Photo credit: Talky

Photo credit: Web tutoring app
The main WebRTC services provided by SimpleWebRTC platform include:
secure streaming of video, voice and screen-sharing
end-to-end encryption
support for up to 30 concurrent users
unlimited rooms
In terms of pricing, they offer the following plans:
Small Group: up to 6 participants, starting from $5 per month
Large Group: up to 30 participants, starting from $3 per month
The Small Group plan has the benefit of having end-to-end encryption available over the Large Group plan. With the Small Group plan, 60–80% of the sessions are peer-to-peer connections where media streams never touch the servers. Bandwidth consumption for such types of sessions isn’t charged.
With Large Group plans, traffic is routed through a server called an SFU (Selective Forwarding Unit), where all streams are metered.
It’s important to note that most commercial alternatives, which we’ll briefly look at later, have per minute pricing. At first glance, it does appear quite affordable. However, you do get charged for peer-to-peer connections, which is free for SimpleWebRTC.
The SimpleWebRTC client library is reliant on React and the Redux ecosystem. You’ll need to possess fundamental skills in the following areas:
Future versions of the SimpleWebRTC SDK will include support of other frameworks such as React Native, Angular, Flutter, and Vue.js. There are also plans for releasing a “no-code” video chat solution that will allow users to automatically deploy a custom branded version of Talky.
Setting up an Account
Head over to’s signup page and register a new account. You’ll be provided with 2GB of bandwidth plus another 3GB if you sign up for their newsletter. This allowance should be sufficient for developing and testing your video chat application.

After signing up, you’ll need to confirm your email address. Completing this step should lead you to your dashboard page, where you’ll receive your API key.

With this API key, you can start building your own custom WebRTC app. In the next section, we’ll run a complete sample application that the team at SimpleWebRTC have built.
Building and Running Sample App
Before we run the sample app, let’s briefly look at how we can start from scratch. First, you’ll need to set up a React project that uses webpack for development. The create-react-app generator can help you with this.
Next, you’ll need to install at least the following Redux dependencies:
npm install redux redux-thunk react-redux

Finally, install the client library provided by SimpleWebRTC:
npm install @andyet/simplewebrtc

After installing the package, you’ll need to updating your index.js file as follows:
import { Provider } from “react-redux”;
import React from “react”;
import ReactDOM from “react-dom”;
import * as SWRTC from “@andyet/simplewebrtc”;


const CONFIG_URL = `${API_KEY}`;

const store = SWRTC.createStore();







{(props) = > {



As you can see in the code above, the SimpleWebRTC library handles the media connections, room creation, and keeps track of connection states with the help of Redux. We won’t progress with this example, unfortunately, since this would make up for quite a long tutorial.
Instead, we’ll look at a complete sample project you can download from GitHub, where you can see how it’s all put together. After downloading, you’ll need to provide your API key in public/index.html, as highlighted below:
DOCTYPE html >

Below are step-by-step instructions on setting up the sample app:

cd simplewebrtc-talky-sample-app
npm install

npm start

The browser should open automatically on localhost:8000. There are basically three steps on setting up a video chat meeting:
specify a room name
permit camera and microphone process
join the call
Once you’ve completed the above steps, you should be met with a screen similar to that shown below.

To test the application locally, you can use another device on the same local network to connect to the app. All you have to do is provide the IP address and port of the host machine. You may also have to configure your firewall on the host machine to allow external network devices to connect to the application’s port.
In order to deploy simplewebrtc-talky-sample-app, you’ll need to run the command npm run build. This will generate a dist folder. Copy the contents of this folder and upload via FTP to your web hosting platform. You can also use a service such as Netlify to host the application for you. However, the deployment process is different. You need to do the following:
Fork or upload the simplewebrtc-talky-sample-app to your own GitHub account. Make sure you’ve committed index.html with your API key.
Go to your Netlify dashboard, click New Site from Git, select GitHub, authorize Netlify to access your GitHub account, and then locate and select your simplewebrtc-talky-sample-app repository.
In the build settings page, ensure the build command is npm run build and the publish directory is dist. Click the Deploy site button.
In a few minutes, Netlify will pull in the source code, install the dependencies, run the build command, and deploy it to a unique subdomain on its platform. From here, you can share this URL with anyone in the world you’d like to have a video chat with.
Alternatives to SimpleWebRTC
As promised, we’ll end with some alternatives to SimpleWebRTC.
Daily is an alternative commercial platform that provides a real-time video API for developers. It comes with the easiest setup process if you want to host your own webRTC application quickly. All you need to do is register an account and acquire a unique subdomain on their platform.
You’ll also need to perform a quick video test on your browser to confirm that the API video call technology is working on your end. Next, you’ll be redirected to your dashboard where you need to create a room. Let’s call it hello for now. The dashboard provides a number of configurable settings for your room such as privacy, screen sharing and recording permissions.
Once you have your room set up, you can create an HTML file and copy the following code:
DOCTYPE html >

Vite App

callFrame = window.DailyIframe.createFrame();
callFrame.join({ url: “” });

On the callFrame.join({ url: “” }) line, you need to replace you with your subdomain, and hello with your room name. You can open the page locally in your browser and you should be able to make a video call. However, you’ll need to host this page on a public server to allow others to connect with you.
The above setup is quick and fast if you need to communicate with your remote team. However, if you need to build a custom video chat app with your own brand, or with custom front-end features, you’ll need to use the daily-js front-end library:
npm install @daily-co/daily-js

Your application will need a bundler like webpack or Rollup to work with this library. Vite and Parcel users are out of luck, unfortunately. There’s a complete sample React app on their GitHub repo that you can check out. There are instructions on how to configure the application and how to deploy it to Netlify.
Despite the library doing a lot of heavy lifting, you’ll notice the sample provided is complex, as there are numerous edge cases you need to keep track of and features you need to provide in order to give your users a reliable video chat experience.
Other Alternatives
There are many other alternatives to SimpleWebRTC and Daily that I’ll list next. The commercial ones include:
Twilio, Vonage and Frozen Mountain provide developers with front-end libraries and the back-end servers required to build and run a real-time video chat solution. Xirsys only provides the back-end servers — that is, the STUN and TURN servers. You’ll need to use an open-source library such as PeerJS for the client library to connect with it.
There are many open-source WebRTC libraries available online. However, most are not actively maintained except the following:
With the guidance of this tutorial on Google Codelabs, you can use plain JavaScript and a few Node.js libraries to build a simple video chat app. However, there are many edge cases not covered by the guide that you’ll have to figure out on your own.
To conclude, building a real-time video chat solution with WebRTC is easier when using a commercial platform. Going the open-source route is doable, but you’ll need to host your own TURN servers to ensure a reliable connection for all your users. In any case, the building process can be time consuming, given the relative complexity of the sample apps we’ve looked at.
They key question to ask yourself is whether or not it’s worth your time building your own custom real-time solution. Unless you plan on making WebRTC your core business, you’ll probably need to first consult with a company that has experience dealing with the technology.

How To Run A UX Audit For A Major EdTech Platform (Case Study)

The business world today is obsessed with user experience (UX) design. And for good reason: Every dollar invested in UX brings $100 in return. So, having some free time in quarantine, I decided to check whether one of the most evolving industries right now, education technology (EdTech), uses this potential of UX. My plan was…

An Introduction to Custom Cursors in Web Design: Tips, Ideas + Tutorials

One of the biggest trends in web design these days is custom cursors. At first glance, a custom website cursor may look like just another stylistic element. But there’s much more to this design concept. When viewing a website from a desktop device, the cursor is the main component that bridges the gap between the…

Looka: An AI-Powered Platform to Design Your Own Logo

Using artificial intelligence, Looka is an online design tool that can help you create anything from a logo to a full branding suite. It’s designed to use keywords and a little machine-learning magic to help jumpstart your creative process when you are ready to launch a business or brand now, but don’t have the materials…

Best Shopping Cart Plugins for WordPress and WooCommerce

Are you looking for a shopping cart plugin for your website? You need cart and checkout functionality for your website in order to sell products and receive payments. A well-designed shopping cart improves the customers’ buying experience, reduces abandoned carts, and will contribute immensely to your bottom line.  Some indispensable features that any shopping cart…

HTML5 Template: A Basic Boilerplate for Any Project

HTML5 Template: A Basic Boilerplate for Any Project – SitePointSkip to main contentHTML5 Games: Novice to Ninja🎮 Design and build cool games that work in any modern browserAs you learn HTML5 and add new techniques to your toolbox, you’re likely going to want to build yourself an HTML boilerplate to start off all future projects. This is definitely worth doing, and there are many starting points online to help you build your own HTML5 template.
In this article, we’ll look at how to get started with building your own HTML5 boilerplate. We’ll walk through the essential elements of an HTML template, ending with a basic template that you can take with you and build upon.
If you’d rather just grab the code now and read this article later, here’s our finished HTML5 template.
The Anatomy of an HTML5 Template
An HTML template typically includes the following parts:
The document type declaration (or doctype)
The Element
The character encoding
The viewport meta element
, description, and author
Open Graph meta elements for social cards
Favicons and touch icons
Links to stylesheets and scripts
Other than the document type declaration and element, the elements listed above will mostly be found inside the section of the HTML template.
The HTML5 Doctype
Your HTML5 template needs to start with a document type declaration, or doctype. A doctype is simply a way to tell the browser — or any other parser — what type of document it’s looking at. In the case of HTML files, it means the specific version and flavor of HTML. The doctype should always be the first item at the top of any HTML file. Many years ago, the doctype declaration was an ugly and hard-to-remember mess, often specified as “XHTML Strict” or “HTML Transitional”.
With the advent of HTML5, those indecipherable eyesores are gone and now all you need is this:
doctype html >

Simple, and to the point. The doctype can be written in uppercase, lowercase, or mixed case. You’ll notice that the “5” is conspicuously missing from the declaration. Although the current iteration of web markup is known as “HTML5”, it really is just an evolution of previous HTML standards — and future specifications will simply be a development of what we have today. There’s never going to be an “HTML6”, so it’s common to refer to the current state of web markup as simply “HTML”.
Because browsers are required to support older content on the Web, there’s no reliance on the doctype to tell browsers which features should be supported in a given document. In other words, the doctype alone isn’t going to make your pages compliant with modern HTML features. It’s really up to the browser to determine feature support on a case-by-case basis, regardless of the doctype used. In fact, you can use one of the older doctypes with new HTML5 elements on a page and the page will render the same as it would if you used the new doctype.
The Element
Following the doctype in any HTML document is the element:

This hasn’t undergone any significant change since the advent of HTML5. In the code snippet above, we’ve included the lang attribute with a value of en, which specifies that the document is in English. This isn’t required for a page to validate, but you’ll get a warning from most validators if you don’t include it.
The element is divided into two parts, the and sections. The section contains important information about the document that isn’t displayed to the end user — such as the character encoding, and links to CSS files and possibly JavaScript. The section contains everything that’s displayed in the browser — text, images, and so on.
HTML Document Character Encoding
The first line inside the section of an HTML document is the one that defines the character encoding for the document. This is an optional feature and won’t cause any warnings in validators, but it’s recommended for most HTML pages:

In nearly all cases, utf-8 is the value you’ll be using in your documents. A full explanation of character encoding is beyond the scope of this article, and it probably won’t be that interesting to you, either. Nonetheless, if you want to delve a little deeper, you can read about character encoding in the HTML specification.
Note: to ensure that certain older browsers read the character encoding correctly, the entire character encoding declaration must be included somewhere within the first 512 characters of your document. It should also appear before any content-based elements (like the element that appears later in our example).
There’s much more we could write about this subject, but for now, we’re content to accept this simplified declaration and move on to the next part of our document.

The viewport meta element is a feature you’ll see in just about every HTML5 template. It’s important for responsive web design and mobile-first design:

This element includes two attributes that work together as a name/value set. In this case, the name is set to viwport and the value is width=device-width, initial-scale=1. This is used by mobile devices only. You’ll notice the value has two parts to it, described here:
width=device-width: the pixel width of the viewport that you want the website to be rendered at.
initial-scale: this should be a positive number between 0.0 and 10.0. A value of “1” indicates that there’s a 1:1 ratio between the device width and the viewport size.
You can read up a little more on these meta element features on MDN, but for now just know that, in most cases, this meta element with these settings is best for mobile-first, responsive websites.
The , description, and author
The next section of the HTML template contains the following three lines:
A Basic HTML5 Template

These elements have been part of HTML for a long time, so there’s nothing too new here. The is what’s displayed in the browser’s title bar (such as when you hover over a browser tab). This element is the only mandatory element inside the .
The other two are optional elements defining a description for SEO purposes along with an author. All elements inside are optional with the exception of . In fact, you can put as many valid elements in the as you like.

As mentioned, all meta elements are optional but many have benefits for SEO and social media marketing. The next section in our HTML5 boilerplate includes some of those meta element options:

These elements take advantage of something called the Open Graph protocol, and there are many others you can use. These are the ones you’re likely to use most often. You can view a full list of available Open Graph meta options on the Open Graph website.
The ones we’re including here will enhance the appearance of the web page when it’s linked in a social media post. For example, the five elements included here will appear in social cards embedding the following data:
a title for the content
the type of content being delivered
the canonical URL for the content
a description of the content
an image to associate with the content
When you see a post shared on social media, you’ll often see these bits of data automatically added to the social media post. For example, below is what would appear in a tweet if you included a link to GitHub’s home page:

Image source: GitHub
Favicons and Touch Icons
The next section in the HTML5 template includes elements that indicate resources to include as a favicon and apple touch icon:

The favicon.ico file is for legacy browsers and doesn’t have to be included in the code. As long as your favicon.ico file is included in the root of your project, the browser will automatically find it. The favicon.svg file is for modern browsers that support SVG icons. The last element references the icon that’s used on Apple devices when the page is added to the user’s home screen.
There are other options you can include here, including a web app manifest file that references other icons. For a full discussion, we recommend Andrey Sitnik’s post on the subject. But the ones included here will suffice for a simple starter template.
Including a Stylesheet and Scripts
The last two significant portions of our HTML template are the reference to a stylesheet and script. Both are optional, of course:

The stylesheet is included using the element with an appropriate rel attribute. A stylesheet can be included anywhere in a document, but you’ll customarily see it inside the . And unlike older versions of HTML, there’s no need to include a type attribute (which was never needed in the first place).
Likewise with script elements, you’ll see them almost anywhere in a document, but they’re usually at the bottom (just before the closing tag) as a best practice.

Placing the element at the bottom of the page is for the purposes of the page-load speed. When a browser encounters a script, it will pause downloading and rendering the rest of the page while it parses the script. This results in the page appearing to load much more slowly when large scripts are included at the top of the page before any content. Thus, most scripts should be placed at the very bottom of the page, so that they’ll only be parsed after the rest of the page has loaded. But note that in some cases, the script may need to be placed in the head of your document, because you want it to take effect before the browser starts rendering the page.
Similar to stylesheet references, the type attribute on scripts is not (and never was) needed. Since JavaScript is, for all practical purposes, the only real scripting language used on the Web, and since all browsers will assume that you’re using JavaScript even when you don’t explicitly declare that fact, you can safely leave off type=”text/javascript, which often appears in legacy code.
A Note About Older Browsers and New Elements
When HTML5 was introduced, it included a number of new elements, such as and . You might think that support for unrecognized elements would be a major problem for older browsers — but it’s not! The majority of browsers don’t actually care what tags you use. If you had an HTML document with a element (or even a element) in it, and your CSS attached some styles to that element, nearly every browser would proceed as if this were totally normal, applying your styling without complaint.
Of course, such a hypothetical document would fail to validate and may have accessibility problems, but it would render correctly in almost all browsers — the exception being old versions of Internet Explorer (IE). Prior to version 9, IE prevented unrecognized elements from receiving styling. These mystery elements were seen by the rendering engine as “unknown elements”, so you were unable to change the way they looked or behaved. This includes not only our imagined elements, but also any elements that had yet to be defined at the time those browser versions were developed, including new HTML5 elements.
Fortunately, older browsers that don’t support styling of new elements are virtually nonexistent today, so you can safely use any new HTML element without worry in almost any project.
That being said, if you really need to support ancient browsers, you can still use the trusty HTML5 Shiv, a simple piece of JavaScript originally developed by John Resig. Inspired by the work of Sjoerd Visscher, it made the new HTML5 elements styleable in older versions of IE. Really, though, this shouldn’t be needed today. As indicated by, HTML5 elements are supported across all in-use browsers.
The Complete HTML5 Boilerplate
Here’s our final HTML5 Template — a basic boilerplate that you can use for any project:
doctype html >

A Basic HTML5 Template

You can drop this simple, ready-to-use HTML5 template into any project today! Building on this, you can add whatever content you want between the and tags.
Next Steps
A great way to take your web layouts to the next level is with The Principles of Beautiful Web Design, 4th Edition. This book will teach you the principles of design and show you how to implement them for the Web. It was completely rewritten in September 2020 and includes cutting-edge techniques you haven’t read about anywhere else.
To hone your CSS knowledge, our curriculum of modern CSS projects will help you master the latest, advanced editions to CSS3.
Beyond that point, you can take your website or web app development to the next level with interactivity and programmatic, reactive UIs. Check out SitePoint’s extensive resources on JavaScript and React, for example. And find out how to start new projects faster with our guide to the best scaffolding web tools and libraries. Alternatively, if you’d like to build web experiences without learning to code, read our primer on the no-code movement. The latest no-code tools have changed the game. For the first time, they’re powerful enough to provide a serious alternative to coding in many situations.