The Basics of WebRTC, Explaining the Jargon
June 6th, 2025
I’ve been prototyping a project at work involving WebRTC. I found the vocabulary to be a distraction that prevented me from quickly understanding the basics. This brief post is how I would have liked to been introduced to WebRTC and it’s corresponding jargon.
We’ll start with the plain english example of how Joe and Mike would set up a video call with each other using WebRTC, which is a common use case of the technology. This example is the basis of this post. On desktop it will be interactively referenced and pinned to the top of the page.
You seem to be viewing this on small screen, its recommended it view on a desktop for the interactive experience.
Joe: My name is Joe, I'd like to start a video call with you, Mike
Mike: OK. My name is Mike and here are some ways you can connect with me directly, Joe.
Joe: Excellent, here is how you can connect with me directly, Mike
Mike: OK.
Now that Joe and Mike have exchanged their information, they'll be able to see and hear each other on a video call.
The dialog between Joe and Mike prior to the video call itself is called a negotiation. Each peer must configure their own peer connection to be able stream video and audio directly with each other.
My name is Joe, I'd like to start a video call
Joe creates an offer that he saves in his peer connection configuration.
with you, Mike
He sends this offer to Mike.
OK
Mike accepts Joe's offer and saves it in his peer connection configuration.
My name is Mike and here are some ways you can connect with me directly
Mike creates an answer to the offer he received from Joe. He saves it in his peer connection details. He also figures out a few ways that Joe might connect with him directly. These are Mike's ice candidates.
Joe
Mike sends his answer and his ice candidates to Joe.
Excellent
Joe saves Mikes answer and ice candidates in his own peer connection configuration.
here is how you can connect with me directly
Joe generates his ice candidates that explain how Mike might connect with him directly.
Mike
Joe sends his ice candidates to Mike.
OK
Mike saves Joe's ice candidates to his own peer connection configuration.
At this point both Joe and Mike have each others ice candidates, which they should have saved to their respective peer connection configurations. This allows peer to peer streaming of video, audio, or arbitrary data directly to each other to begin.
Questions you likely have
How is this negotiation happening?
If the negotiation is required to set up direct lines of connections, how are Joe and Mike communicating prior to those direct lines existing?
Most documentation states that negotiation can happen “however you’d like”. I’ll provide some examples to put it plainly.
- Joe and Mike could meet up at the park and exchange information on sticky notes
- Call each other on the phone with a pen and paper ready
- They could communicate via email
…or maybe as the developer of the video chat app, you set up a server for them to communicate in realtime with each other.
The information sharing that occurs outside of the direct WebRTC peer to peer connection is called signalling. Sometimes people will refer to the negotiation process itself as signalling too. It’s common practice to set up a signalling server in which peers can signal to each other. Picture a simple websocket server, for example.
Know though that setting up a server is NOT required in the base case. My
first “hello world” demo was simply me calling myself in another browser. For
this demo, I copy and pasted messages to each browser using prompt() and
alert(). Feeling the mechanics of the negotiation was important to me.
Setting up automatic signaling was, once again, another distraction.
In some other “hello world” demos you’ll see folks use Broadcast Channels as their simple signalling mechanism. Anything goes, really, but in production for your typical call-type apps you’re most likely going to see a websocket signalling server.
Whats the point of WebRTC if I still need a server?
If you have to provide Joe and Mike realtime communication for signaling, why use WebRTC at all? Because of the benefits of direct, peer to peer communication.
- Low latency. If Joe and Mike in are in the next town over why bother passing through your datacenter in Virginia? With a peer to peer communication they theoretically take the shortest route to reach each other.
- Low (no) bandwidth. Video and audio data is large. Not footing the bill for that bandwidth means cost savings.
- Its a developed standard. WebRTC is built into all modern browsers now. This means by using it you get universal compatability for free (without having to understand all the different edge cases yourself).
- …and more
Going beyond the basics
With this baseline knowledge, I’ve found the rest of the documentation (and even the jargon) online to be excellent. Everything I’ve run into since forming this understanding has been fairly clear.
If you’re a WebRTC pro and have corrections or suggestions to any of the above, please reach out and I’ll be sure to update the post to be accurate as possible.