Blogs on Pion

Fixing WebRTC data-channels head-of-line blocking with RFC-8260

Sun, 17 May 2026 00:00:00 +0000

What is head-of-line blocking and why it’s an issue with WebRTC datachannels

SCTP (the protocol used by WebRTC data channels) looks like it should be perfect for multiplexed application data. It is message-based, it supports multiple streams inside one association, and WebRTC data channels are built on top of it for non-media data.

To understand sender-side head-of-line blocking, we first need to understand how SCTP sends messages. Messages are scheduled based on their send order. SCTP fragments messages according to the path MTU (Maximum Transmission Unit), which is usually around 1200 bytes for WebRTC. A 256 KB message would therefore be split into roughly 218 smaller fragments (chunks).

RACK makes Pion SCTP 71% faster with 27% less latency

Sun, 21 Dec 2025 00:00:00 +0000

What is SCTP?

SCTP stands for Stream Control Transmission Protocol. At a basic level, SCTP is designed to be reliable, handle de-duplication of packets, and support packets that may be delivered in order or out of order. Beyond transporting messages, SCTP can also set up a connection between users. On a deeper level, SCTP includes native support for multiplexing: multiple applications can take advantage of a single transport connection. SCTP also supports multi-homing, which enables automatic failover from a primary connection to a secondary one.

WebRTC Survives When You Walk Out

Fri, 17 Oct 2025 00:00:00 +0000

Networking for a video call sounds simple. You send your video to the server and server sends video back. But that mental model breaks down in the real world. A connection that starts on stable home Wi-Fi may suddenly need to continue over cellular as someone walks out the door. The real challenge isn’t just connecting two points! It’s staying connected as the network beneath you changes.

With automatic renomination, Pion will now handle that completely seamlessly, allowing your media to flow without skipping a beat. It works by periodically detecting when new connection candidates are available and automatically switching to the highest quality candidate, taking advantage of a feature in WebRTC called renomination.

Making a game with Pion

Tue, 09 Sep 2025 00:00:00 +0000

(The following was adapted from a talk I gave at DWeb Weekend 2025 at the Internet Archive in San Francisco on August 17, 2025)

Simplifying WebRTC Datachannels for Games

First of all, to get some stuff out of the way, instead of using the “super complicated” WebRTC datachannels, why don’t we use something simpler?

Why Not Use Websockets?

Too slow: Most games use UDP with a reliability layer on top.
Suitable for turn-based games: Fine for games that are turn-based/slow-paced, like Runescape.
For more details, see:
- UDP vs TCP
- Client-Server Connection

The Case for Web Transport

Replacement for Websockets, uses QUIC instead of TCP.
However, it has been in development for a long time, and I want to get started on making games now.
Current issues:
- Caniuse WebTransport
- Official demos on GitHub do not work on Firefox on Windows.
- GitHub Issue
- Firefox Bugzilla
Potential: Will probably solve most problems once finished and would be the best choice for making a multiplayer game on the web.

Datachannels: A Hidden Gem of WebRTC

Feature: Lets us send unreliable packets over the web using SCTP.
Advantage: We don’t need WebTransport; we can use this today.
They were created in part for exactly this use case
- See the reasoning for unreliable datachannels in the official specification itself
- Not to mention that one of the original implementers of WebRTC wanted to enable this usecase

Benefits and Drawbacks of WebRTC

Benefits

Host flexibility: Do not need to host servers - players can make their own.
- No more need for port forwarding or Hamachi!
Minimal server requirements: Only need one server for signaling.
Community-supported specification: There are many options for making your own WebRTC-based app.

Drawbacks

Complex setup: Setting up WebRTC is challenging.
Server dependence: You need to host or use two different servers (Signaling + STUN/TURN).
- Can use Google’s STUN, but combining signaling and STUN into one server would be nice.

WebRTC Implementations

libwebrtc - (a fork of) the original WebRTC implementation.
libdatachannel - C/C++.
Pion WebRTC - Go.
webrtc-rs - Rust (using Tokio Runtime).
str0m - Rust (sans-io).
sipsorcery - C#
GameNetworkingSockets
- Uses ICE and STUN/TURN for Peer to Peer.
- Created by Valve and made for Steam, which means if you’ve ever played a game like Counter Strike or Deadlock, you’ve already seen this library in action!

Existing Game Networking Libraries Using WebRTC

Geckos.io
- A client-server abstraction for WebRTC Datachannels written in Node.js.
- Past experience: Really nice but a bit inefficient. See GitHub Issue.
Netlib - Peer-to-peer WebRTC datachannel library for TypeScript.
Matchbox - WebRTC datachannel library for Rust, compiles to both native and WASM.
PeerJS - Great for browser-only apps/games, not specifically for game networking.
Netplayjs - Untested but seems to work well.
Godot Engine’s WebRTC Native - Official Godot bindings to libdatachannel for Godot’s multiplayer API.

Real-World Uses

WebXash3D: Reimplementation of Half-Life 1 + Counter-Strike 1.6 using WebRTC.
Hypersomnia - Open source 2D shooter made with C++ and libdatachannel
- Has cross platform capabilities between both
  - The native Steam port
  - And in the browser (On CrazyGames and the official website)
- Github Link

Why Go for Development?

Efficient: It just gets the job done.
Pion: Has a pure-Go implementation of WebRTC.
Minimal dependencies: No need for external dependencies like OpenSSL.

Why Not Rust?

Preference: I like Rust, but Go has a more active scene/easier help for WebRTC.
Speed of development: It’s faster to code in Go compared to Rust.

Why Ebitengine for Game Development?

Website Link
Versatile: 2D game engine that works across various platforms.
- The creator, Hajime Hoshi, has ported the engine (and the Go language!) to the Nintendo Switch and other game consoles
Battle Tested: Has been used for actual games like
- From Madness with Love
  - Steam Link
- Coral & The Abyss
  - Steam Link
  - Nintendo eShop Link
- Rakuen
  - Steam Link
  - Nintendo eShop Link
- And more on the Ebitengine Showcase Page
Potential Crossplay: You could make a cross platform multiplayer game in pure Go that works between the Nintendo Switch, PC, and the browser!

Official Pion Example

We now have an official example using Ebitengine in the Pion example-webrtc-applications repository
This includes an bundled in signaling server so you can host your own lobby, and connect with another player.
Github Link to Game
PR where it was merged in: Example WebRTC Applications
Limitations
- Right now, this can only support two players on the same computer
  - Could probably work between two different computers, but we would need to figure out how to setup CORS properly for the signaling server
  - The machinery is there to support more than two players in a lobby, but as of writing this article it is currently hardcoded to just two

Other Games That Use WebRTC

Possibilities with WebRTC

Hosting a Minecraft-style game without dedicated servers or port forwarding.
Players host everything themselves: no need for VPN/Hamachi.

Community Acknowledgements

A big thanks to:
And many more who made this journey possible. I stand on the shoulders of giants.

FEC with Pion

Mon, 23 Jun 2025 00:00:00 +0000

We are excited to have FEC encoding support available in the pion/webrtc v4.1.2 + pion/interceptor v0.1.38. In this blog post, we’ll explain what FEC is and how to implement it with Pion.

If you already know FEC, feel free to skip to FlexFEC in Pion.

Quick background: What is FEC?

Forward Error Correction (FEC) is a proactive loss-recovery mechanism:

The sender transmits extra mathematically derived parity packets (e.g. xor of the media packets) along with each block of media packets. If the receiver later discovers that one or even more packets are lost, it can use the parity packets to recover the lost packets, using the XOR result of the received packets and the parity (repair) packet, all without waiting for the lost packets to be retransmitted.

Pion Opus

Sun, 02 Oct 2022 00:00:00 +0000

I am so excited to announce that pion/opus is now available. It is a Pure Go implementation of the Opus Codec. pion/opus is far from done though. It is far enough along for others to start playing with and contributing too though. We still have a lot more work to do. If you are interested now is a great time to get involved!

Now that the code is shared I wanted to share my goals, what I learned and hopes for the future.

ION, grown up and moving out.

Tue, 19 Jul 2022 00:00:00 +0000

Going forward the ION project will now be hosted at ionorg/ion. ION itself is not changing in any other way. We are just making these changes to more clearly reflect the actual leadership and organization of the project. Changes like this aren’t free though. Users may have to change imports, tooling and other software. We apologize for that, but hope these benefits are worth it.

Recognize the actual leadership of ION

The leadership and contributors of ION and Pion are often conflated. Often I will have users ask me questions or even thank me for ION. This confusion is demotivating for the people actually doing the hard work. I worry that long term it will hurt the project.

Pion is a nonprofit project

Mon, 27 Dec 2021 00:00:00 +0000

Pion saw its first commit Wed Mar 7 2018. I didn’t have grand aspirations for the project. It felt important at the time to make WebRTC more accessible. Proprietary alternatives were being proposed and they didn’t have technical advantages, they were just easier to use. I enjoyed solving issues one at a time and helping users use Pion.

Interest in WebRTC then exploded in 2020. Lots of new demand for WebRTC software popped up over night. New developers started learning it, companies were founded around it and lots of VC money started entering the space.

Why WebRTC?

Sun, 05 Dec 2021 00:00:00 +0000

This is a question I get in lots of different forms. Why should I use WebRTC instead of my preferred video protocol? Why does WebRTC need to be in my browser? Why does WebRTC have to be so complicated? Why do you continue to work on WebRTC projects?

These are my answers to the Why’s of WebRTC. Lots of nuance exists, and these answers are heavily influenced by the work I do. I have been working with WebRTC since 2013. In that time I worked on two implementations Pion and KVS WebRTC. I also co-authored a book WebRTC for the Curious. I have used WebRTC at startups and corporate projects.