Offloading Bandwidth to Clients with the WebRTC Protocol
My Background
I am a Full-stack developer and mentor that has coded a variety of applications over recent years.
Past clients have ranged from publically companies to small eCommerce shops. My passion is development and design that drives amazing UX through uniquely branded experiences.
Though I have a diverse development background besides some reading here and there this was my first dive into WebRTC.
Why I wanted to learn about peer to peer video streaming
After talking to a new company I decided it would be a fun idea to study up on the technologies and core building blocks of their service. I remember hearing peer to peer and CDN flung around the company's website, then realizing something very interesting was going on. They were offloading a majority of video streaming bandwidth to users on the website, then using multiple CDN's for failover. After digging into their developer tools I realized the whole peer to peer connectivity was powered through WebRTC.
How I approached learning peer to peer video streaming
I started learning about WebRTC through some blog posts and Mozilla's different documentation on the protocol. The next step was to set up some practical examples using a higher-level library to better understand the basics of this protocol. I ended up using a library called PeerJS and was able to create a basic peer to peer messaging system with my laptop and desktop that was connected to a VPN.
After playing with the basics I decided to move forward with the development tools provided by the company I was looking into (Streamroot). Through some trial and error, I was able to get a video streaming to my laptop from another pc and their failover CDNs.
Challenges I faced
The biggest challenge in this process was understanding WebRTC's inner workings under the hood. After reading about how the Interactive Connectivity Establishment (ICE) protocol enabled WebRTC's client to client communication regardless of the NATs that exist in between them I was pretty excited to learn more.
One of the more difficult sets of topics I encountered was STUN and TURN servers.
STUN and TURN servers can allow WebRTC to dynamically find and generate the shortest path for media to travel between peers while also resolving some inherent NAT difficulties.
This is important because at a high level, there are 3 types of routes for a connection when using WebRTC:
- Direct peer to peer connection
- Through the use of STUN (to find a public IP address)
- Through the use of TURN (to relay all media through it)
What is a STUN Server?
Often, you can use a protocol called STUN (Session Traversal Utilities for NAT) that allows users to identify their own public IP address and the type of NAT they are behind. This information is used to create and establish a valid media stream. For the most part, STUN servers are only used during the media stream establishment phase.
How do STUN servers work?
STUN servers check connection information like IP address and port then send this back to the originating peer. In the majority of cases, this allows peers to find their own public IP and port even if they are behind NAT. Using this information allows a direct peer to peer connection to be established between the peers for media transmission and communication. Though this often covers more than 90% of cases by the numbers it really does depend on your user's network environment as STUN can’t deal with Symmetric NAT.
The difference between Symmetric and other NAT setups is “only an external host that receives a packet from an internal host can send a packet back.” This would mean the peer would only be allowed to communicate with the STUN server, even with the other peer's public connection information. This is where a TURN server comes into play.
What's a TURN Server?
There are still sometimes very restrictive corporate networks where only certain ports or communications are allowed. This requires clients to use a TURN (Traversal Using Relays around NAT) server to relay media traffic through if a connection cannot be established any other way. TURN servers just remove the entire peer to peer aspect and stream information from peer to an intermediary TURN server that will then relay that information to the intended peer.
All of this was foundational to understanding the combined peer to peer and CDN setup I was studying. It can often make sense to fall back on the CDN for video streaming because of unstable peers or in place of a TURN server since CDN bandwidth should be much cheaper.
Key takeaways
The general benefit WebRTC provides is the ability for peers to discover, connect and easily communicate with each other through a web browser using javascript. It's commonly used for video or chat web applications where the core goal is providing peer to peer communication but can also be used for large-content focused websites like social platforms.
The most interesting takeaway from this deep dive was that it makes a lot of sense to sometimes offload resource intensive activities to the client. What's even more amazing is it's quite possible to expand upon the theory and offload certain compute and storage operations to your users as well through message queues and distributed processing.
Tips and advice
If you are curious about the specific types of solutions I was looking into you can check out Peer5 or Streamroot. These services can be integrated into a variety of web applications from social platforms to corporate video conferencing. In some cases, these services have saved up to 98% of CDN bandwidth through peer to peer streaming.
When it comes to learning about ICE and STUN/TURN servers I would recommend reading the amazing blog posts online like HTML5 Rocks and settling for using a service provider that specializes in hosting STUN/TURN servers to make this part easy.
Final thoughts and next steps
With the growth of IoT, VOIP, Augmented reality and Video calls the ways to integrate WebRTC are increasing by the day. According to a Future Market Insights report from 2015, the market value of WebRTC products is expected to reach $23 billion by 2025. If you are ever curious to learn more feel free to leave a comment or reach out.
Best,
Terrell Gentry
