The rise of WebRTC and the enhanced ability of browsers to handle real-time point-to-point communications make building real-time applications easier than ever. This article will explore SimpleWebRTC and its application in the implementation of WebRTC technology, and introduce other alternatives that can achieve the same goal.
If you need background knowledge on WebRTC and peer-to-peer communication, it is recommended to read "Dawn of WebRTC" and "Introduction to getUserMedia API".
Due to the complexity of building custom WebRTC applications, this article will not provide step-by-step build tutorials. Instead, we will look at the types of libraries and servers needed to build reliable applications. I will provide a complete sample application link that you can refer to when building your own application.
We will focus mainly on the SimpleWebRTC platform. Later, we will briefly cover other commercial and open source alternatives that can help you achieve the same goals.
Key Points
What is WebRTC?
WebRTC (Web Real-Time Communication) is an open source project that allows point-to-point real-time communication between web browsers, transmitting real-time video, audio and data streams over the network. Google Chrome, Mozilla Firefox, Safari, Opera and other Chromium-based browsers have implemented this technology natively. This is good news because users can access the technology without installing third-party plugins or applications.
Older browser versions and traditional browsers such as Internet Explorer do not have this technology. Users need to use the latest browser. You can view the full list of supported browsers:
In January 2021, the World Wide Web Alliance (W3C) transformed the WebRTC 1.0 specification from a candidate recommendation state to a recommended state. This is an extraordinary achievement considering that the technology was first released 10 years ago.
WebRTC specification covers how browsers access local media devices and how they use a set of real-time protocols to transmit media and common application data to the browser. It does this through a set of JavaScript APIs that have been covered in the previous article. The specification also ensures that all communications are encrypted and that unwanted third parties cannot eavesdrop on streams.
It should be noted that WebRTC does not cover everything, such as signaling, the process of starting a connection between browsers. To avoid potential new technical limitations, this part of the content is omitted from the specification. The second reason is that WebRTC is mainly client technology, and it is best to use server technology to deal with problems such as sessions.
How browser signaling works
WebRTC is defined as point-to-point communication between web browsers. The reality is that most browsers run on computers located behind NAT (Network Address Translation) devices (optional firewall). NAT devices (usually routers or modems) allow computers with private IP addresses to connect to the Internet through a single public IP address.
NAT devices protect personal computers from direct attacks by malicious users on the Internet through IP addresses. Unfortunately, it also prevents devices with private IP addresses from connecting to another private IP device over the internet.
To overcome this challenge, the Internet Engineering Task Force (IETF) proposed the ICE (Interactive Connection Establishment) protocol, allowing private IP computers to discover and connect to other private computers on public networks.
This involves using a public signaling server, to which both clients can easily connect. The peer computer connects to this server and uses it to exchange the IP addresses and ports required by the data source and receiver. With this information, they can establish a direct connection to each other and start transmitting video, audio, and data.
This is an animation demonstration:
Image description: WebRTC signaling
To set up WebRTC signaling, the ICE framework requires you to provide the following two types of servers.
STUN (Session Traversal Utility for NAT) server functions as I described above. It simply provides a meeting space for computers to exchange contact information. Once the information exchange is completed, a connection is established between the peer computers, and the STUN server leaves the rest of the conversation.
This is a sample script running on the client, allowing the browser to initiate a connection through the STUN server. This script allows multiple STUN server URLs to be provided when one of the servers fails:
function createPeerConnection() {
myPeerConnection = new RTCPeerConnection({
iceServers: [
{
urls: "stun:stun.stunprotocol.org",
},
],
});
}Connections established through STUN servers are the most ideal and cost-effective type of WebRTC communication. Users will hardly incur any running costs. Unfortunately, because each peer uses a different type of NAT device, some users' connections may not be established. In this case, the ICE protocol requires you to provide a fallback, a different type of signaling server called a TURN server.
TURN (Traveling with Relay NAT) Server is an extension of STUN server. What makes it different from its predecessor is that it handles the entire communication session.
Basically, after establishing a connection between peers, it receives a stream from one peer and forwards it to another peer and vice versa. This type of communication is more expensive, and the host must pay the processing and bandwidth load required to run the TURN server.
The following is a graphical description involving the entire signaling process involving first the STUN server and then the TURN server as a fallback:
Image description: Shows a complete architectural diagram of the entire WebRTC process.
While it is possible to set up your own video chat solution using pure JavaScript code and a free public STUN server, not everyone can connect to each other on your platform. If you want to provide reliable services to all users, you must use a TURN server.
As mentioned earlier, setting up a WebRTC platform can be complicated. Fortunately, we have an all-in-one business platform that makes building WebRTC video chat applications a breeze. Now let's see how SimpleWebRTC can relieve our burden.
What is SimpleWebRTC?
SimpleWebRTC is a platform that provides developers with a simple and cost-effective service to build and deploy custom real-time applications using React. Specifically, they provide the following:
The following are example screenshots of some custom video chat projects they helped clients develop and launch.
Picture description: Talky
Picture description: Web Tutoring App
The main WebRTC services provided by the SimpleWebRTC platform include:
In terms of pricing, they offer the following plans:
The advantage of small group plans is that end-to-end encryption can be used, while large group plans cannot. In a small group plan, 60-80% of the sessions are peer-to-peer connections, and media streams never touch the server. There is no charge for bandwidth consumption for such sessions.
For large group plans, traffic is routed through a server called SFU (Selective Forwarding Unit), and all traffic is metered.
It should be noted that most commercial alternatives (which we will briefly describe later) use billed by minute. At first glance, it seems quite affordable. However, you do charge for peer-to-peer connections, and SimpleWebRTC is available for free.
(The following content will be simplified due to the length of the article, and the core information and code examples will be retained. Please refer to the original document for the complete original text.)
SimpleWebRTC client library relies on the React and Redux ecosystems. You need basic skills:
Get the registration page of simplewebrtc.com and register a new account. You get 2GB of bandwidth, and if you sign up for their newsletter you get an extra 3GB of bandwidth. This quota should be sufficient to develop and test your video chat application.
After registering, you need to confirm your email address. After completing this step, you should be on the dashboard page where you will receive your API key.
Use this API key, you can start building your own custom WebRTC application. In the next section, we will run the complete sample application built by the SimpleWebRTC team.
(Code sample is streamlined)
(Simplified deployment steps)
(A brief introduction to alternatives)
Conclusion
Anyway, it is easier to build a live video chat solution with WebRTC using a commercial platform. Adopting an open source route is feasible, but you need to host your own TURN server to ensure a reliable connection for all users. In either case, the build process can be very time consuming given the relative complexity of the sample application we've seen.
The key question to ask yourself is whether building your own custom real-time solution is worth your time. Unless you plan to use WebRTC as your core business, you may need to first consult a company with experience in handling this technology.
(FAQ part is streamlined)
The above is the detailed content of Building WebRTC Video Chat Applications. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
