Peer-to-peer for the win!
Designing Pluot, a peer-to-peer video conferencing product.
Quick question: when you travel, do you prefer nonstop flights, or flying through a hub airport somewhere? How about when you have a bunch of things to do around town on a Saturday morning: do you come home after every errand, or do you go directly from one location to the next?
Me, too! I like going directly from place to place, whenever possible. And it turns out that moving data around the Internet is just a little bit like driving or flying. Sending data directly from one computer to another is faster than sending stuff through centralized “hub” computers in the cloud.
People like me, who love network engineering, call this peer-to-peer networking (P2P).
Most of the time, when you do a video call using a program like Hangouts or Skype, your data is not routed peer to peer. All your video and audio go through Google’s or Microsoft’s servers. Back a few years ago, when our computers had a lot less processing power, and bandwidth was pretty limited, that was helpful. But these days it’s actually not so great.
I’ve been obsessed with digital video for a long time. For the last couple of years I’ve been experimenting with — and now am building products on top of — a new standard called WebRTC. WebRTC provides a rock solid, reliable way to send streams of data (like video and audio) directly between any two computers on the Internet.
My company, Pluot, recently launched a hardware video conferencing device that leverages peer-to-peer networking and WebRTC to deliver really great quality video over normal Internet connections. We’re the only hardware video conferencing product that does peer-to-peer, and we’re pretty proud of that!
We designed Pluot to be easy to buy, easy to set up, and easy to use. So Pluot video calls have to “just work” no matter what kind of network you have in your office. And anyone, anywhere has to be able to join a Pluot call. So we need to support not just our Pluot hardware, but web browsers on laptops, and people on mobile phones.
Here’s how a Pluot video call works
Step 1: When you want to join a Pluot call, you click on a Pluot meeting link, which looks something like this …
https://pluot.co/a?m_=LFPAFTVMQXHC.
(If you click on that link using the Chrome web browser, you can join that meeting. I don’t know who else will be there. Maybe someone who’s reading this post at the same time you are!)
More info: Below some of these diagrams are technical details, in case you’re interested.
Step 2: We maintain some servers in the cloud that we use for signaling, for setting up and managing each call. Your Pluot, or your web browser, says to our signaling servers: “Hey, I want to join this call, please tell anyone else in this call a little bit about me, and how to find me on the Internet.” Keep in mind that you’re talking to our signaling server just to set up the call.
Step 3: The other participants also are talking to Pluot’s signaling server, to set up the call on their end. Like you, they’re telling the signaling server a little bit about themselves, like where you can find them:
- Detail: The information you’re exchanging to set up a call is mostly in the form of SDP records
Step 4: Pluot’s signaling servers have passed on relevant info from call participants. Now, your Pluot or web browser can connect directly to each of the other Pluots or web browsers on the call. You send your video and audio, separately, to each peer.
- Detail: You still keep a background connection with the Pluot signaling server. It lets you know, for example, when a new colleague wants to join the meeting. But the amount of data through the signaling server is small. The key data, which is your actual video and audio, is content you’re exchanging directly with each other participant.
- Detail: A technique called UDP hole punching is used to negotiate the direct connection.
Voila! Because you are directly connected to each person you are talking to, each video and audio stream is as high-quality, and as low-latency, as possible. As an added benefit, you know for sure that your video and audio are secure — nobody else can see or hear them. The data is encrypted and nobody except the sender and receiver of each stream have the encryption keys.
GROUPS CALLS WITH P2P
Let’s compare this peer-to-peer video call with a more traditional call that is routed through a server. This server is in, for example, Oregon. (There are a lot of data centers in Oregon.)
Sending an Internet packet from San Francisco to Los Angeles usually takes about 20 milliseconds. (That’s 1/50th of a second. Fast enough that you won’t notice the delay.) Sending a packet from San Francisco to Paris, though, typically takes 150 milliseconds or more. (About 1/7th of a second. That delay is noticeable, but it’s not too bad.)
However, if you have to send all your audio and video through the server in Oregon, you introduce more delay. Every packet has to travel two network legs. (Plus the server introduces some delay, but we’ll ignore that for the moment.)
But wait, it gets much worse! Let’s add someone in London to the call. Now data going from Paris to London is very, very slow (because it has to go to Oregon and back).
There’s nowhere in the world that we can put our server and have this call be a good experience for everyone.
In contrast, the peer-to-peer call works pretty well for everyone. Each link is as fast as possible.
P2P: Pros & Cons
Pure P2P only scales to a certain point. Pluot calls can have a maximum of six participants. Beyond six participants, we’ve found that most computers, and many people’s network connections, start to get bogged down.
But the advantages of pure peer-to-peer are significant, which is why the Pluot architecture is built on P2P. Because each participant connects directly to every other participant, each video stream is as high- quality, and as low-latency, as possible. This is noticeable to end users. And it is particularly apparent on international calls.
Falling back to relaying where necessary
At this point, a savvy IT person might be saying, “wait a second, your Pluot might be behind a firewall that doesn’t allow just any old traffic in and out!” That’s true. On some networks, P2P connection attempts will fail. Firewalls at large enterprises are sometimes configured to block most or all UDP traffic. We see this happen for fewer than 1% of all Pluot calls, but we want Pluot calls to “always work.” So it’s critical to handle this situation.
We have two fallbacks in place for network on which peer-to-peer connections aren’t possible. First, we try to send UDP traffic through our servers, rather than peer-to-peer. That often works. But if it doesn’t, we switch over to using TCP tunneling to send the video and audio. Again, through our servers. And that almost always works. In fact, we’ve never seen a failure in real world testing.
Of course, routing video and audio through our servers is what we just tried to show, using all those diagrams above, is what we don’t want to do. But — and this is important — we only route traffic through our servers when we have to, and we can do that on a per-connection basis. We don’t have to do it for everyone on a call unless everyone is behind different firewalls that are all configured to block direct UDP traffic.
Adjusting video quality in real time
While a call is ongoing, we can adjust the video quality to match the bandwidth that’s available for each peer-to-peer connection.
For good video and audio quality, a Pluot participant needs to have 200 kb/s of bandwidth available both upstream and downstream for each peer that it is communicating with. So, for a four-way call, each location needs to have at least 600 kb/s of “upstream” bandwidth available to send video/audio, and 600 kb/s of “downstream” available to receive video/audio.
The peer-to-peer architecture makes it possible to adjust the video quality for each link independently. In the example above, the participants in London and Paris would see very high quality video for each other, and somewhat lower quality from their colleagues in the United States. In contrast, everyone would see lower quality video with an old-style “cloud” video architecture.
Protocols
If you’re interested in learning more about the protocols that we use to set up calls and send audio and video, here are links to the standards that we’ve mentioned in this overview.
We’d love to hear what you think about Pluot.
- Pluot Free: You can try the free web version of Pluot anytime, in Chrome. Just go to https://pluot.co/new to create a new, permanent, unique Pluot meeting link. Then copy and paste that link and send it to anyone in the world! They simply click on the link in Chrome to join.
- Pluot Big Screen Video Conferencing: We also designed hardware, to plug into your TV. It upgrades your team from Hangouts or Skype. With big screen meetings, your team can get more done together. Free hardware, free shipping & returns. No contract required.
