Chapter 3. Creating a Basic WebRTC Application
The first step of any WebRTC application is to create an RTCPeerConnection
. Creating a successful RTCPeerConnection
will require an understanding of the inner workings of how a browser creates peer connections. Firstly, in this chapter, we will lay the groundwork to understand the internals of WebRTC. Then we will utilize this knowledge to create a basic WebRTC video chat application.
In this chapter, we will cover the following topics:
Understanding UDP transport and real-time transfer
Signaling and negotiating with other users locally
Finding other users on the Web and NAT traversal
Creating an RTCPeerConnection
Understanding UDP transport and real-time transfer
Real-time transfer of data requires a fast connection speed between both the users. A typical connection needs to take a frame of both—audio and video—and send it to another user between 40 and 60 times per second in order to be considered good quality. Given this constraint, audio and video applications are allowed to miss certain frames of data in order to keep up the speed of the connection. This means that sending the most recent frame of data is more important than making sure that every frame gets to the other side.
A similar effect can already be seen with any video-playing application today. Video games and streaming media players can tolerate losing a few frames of video due to the special properties of the human brain. Our minds try to fill in the missing gaps as we visualize and process a video or game that we are watching. If our goal is to play 30 frames in one second and we miss frame 28, most of the time, the user will not...
The next few sections will cover the WebRTC API currently implemented in the browser. These functions and objects allow developers to communicate with the WebRTC layer and make peer connections to other users. It consists of a few main pieces of technology:
The RTCPeerConnection
object
Signaling and negotiation
Session Description Protocol (SDP)
Interactive Connectivity Establishment (ICE)
The RTCPeerConnection object
The RTCPeerConnection
object is the main entry point to the WebRTC API. It is what allows us to initialize a connection, connect to peers, and attach media stream information. It handles the creation of a UDP connection with another user. It is time to get familiar with this name because you will be seeing it a lot throughout the rest of the book.
The job of the RTCPeerConnection
object is to maintain the session and state of a peer connection in the browser. It also handles the setup and creation of a peer connection. It encapsulates all of these things and exposes...
Building a basic WebRTC application
Now that we have a good understanding of how the pieces of WebRTC are used, we are going to build our first WebRTC-enabled application. By the end of this chapter, you will have a working WebRTC web page where you can see the technology in action. We are going to pull all the information we just covered in to an easy-to-develop example. We will cover:
Creating a RTCPeerConnection
Creating the SDP offer
and response
Finding ICE candidates for peers
Creating a successful WebRTC connection
Creating a RTCPeerConnection
The application we are going to create will, unfortunately, not be an entirely useful one, unless you happen to like looking at yourself in a mirror. What we aim to do in this chapter is connect a browser window to itself, streaming video data from the user's camera. The end goal is to get two video streams on the page, one coming from the camera directly and the other coming from a WebRTC connection that the browser has made locally.
Although this...
Running your first WebRTC application
Now, run your web page to test it out. When you run the page it should ask you to share your camera with the browser. Once you accept, it will start the WebRTC connection process. The browser should almost instantly go through the steps that we have discussed so far, and create a connection. You should then see two videos of yourself, one from your camera and the other being streamed over a WebRTC connection.
For reference, here is a full listing of the code from this example. The following is the code from our index.html
file:
Q1. UDP is well suited for WebRTC peer connections because of the non-guarantees it makes when delivering data packets. True or false?
Q2. Signaling and negotiation is part of the WebRTC standard and is completely taken care of by the browser. True or false?
Q3. The Session Description Protocol (SDP) is best described as:
A configuration file for WebRTC
A way to figure out what video codecs are supported
A business card for your computer
A confusing technical document that no one understands
Q4. Interactive Connectivity Establishment (ICE) assists in finding a clean path between two clients in a typical network setup. True or false?
Q5. Which is not true about TURN?
It requires more bandwidth and processing power than a normal connection
TURN should be a last resort after trying other methods of connection
A TURN server will have to process every packet sent between clients
TURN methods are provided by the browser
Congratulations on making it this far. If you have successfully completed this chapter, you are well on your way to making larger WebRTC applications. The goal of the this chapter was not only to create a WebRTC application but also to understand what happens at each step of the process.
After this chapter, it should already be clear that WebRTC is a complex piece of technology. We covered a great deal of information on the inner workings of WebRTC. Although it is not required to know every bit about how WebRTC is implemented in browsers today, having an understanding of how the major parts work together will help you understand the examples to come.
In this chapter, we covered the inner workings of how peer connections are created in the browser. We covered several of the technologies that enable this, including UDP, SDP, and ICE. You should now have a surface-level understanding of how two browsers can find each other and communicate over the Internet.
It would be a good idea to review...