Peer Calls v4.1

Peer Calls is an open-source distributed video conferencing platform which allows the users to quickly create rooms and invite people to join by sharing a link. It's web-first and supports all major desktop and mobile browsers.

When COVID-19 struck in the beginning of 2020 I started getting a lot of inquiries about Peer Calls, an open source project I've been working on in my free time since 2016. Around this time the latest version was v3, which had a NodeJS backend and it only supported establishing direct peer to peer connections between participant in a room. This design would cause serious performance issues with four or more participants as each would have to encode and send video to every other peer.

I started looking into improving the performance and was considering whether to integrate with an existing selective forwarding unit (SFU) such as Kurento, find a NodeJS binding for libwebrtc, or something else. Finally, I learned about pion/webrtc and discovered that it had an active and welcoming community. I soon decided to rewrite the Peer Calls core in Go, and attempt to implement an SFU using Pion.

The initial rewrite was almost a 1:1 port from NodeJS. It had the same API and the frontend did not have to be modified. Next, I started the first steps towards making Peer Calls an SFU powered by Pion. If I knew then about all the things I'd have to learn, I'd probably have given up a long time ago. Around that time the awesome WebRTC For The Curious book hasn't been started yet, so my only resources were looking at Pion's source code and examples, random blog and forum posts, and the numerous WebRTC RFCs.

After a few months of hard work and bug fixes submitted to Pion, I had a working SFU and Peer Calls v4 was released. I was happy to see the number of GitHub stars increasing almost every day. In version 4.0 we brought full support for iOS, Android, Mac, Linux and Windows devices.

Ever since then I kept working on new features as often as I could, and today I'm proud to announce the first minor release, version 4.1, which brings a redesigned core and lots of new features.

Server to Server Transport

The feature I'm most excited about is the server-to-server transport, which transmits metadata, audio/video, and other data through a single UDP port. This theoretically allows us to host Peer Calls instances in different geographical locations, closer to the users, and then the server nodes, which usually have more bandwidth than consumer devices, can forward the data to the node on which the other user is connected.

This feature is currently experimental and the UDP packets are not encrypted, so a VPN or some other means of encryption should be used.

Previously all users would subscribe to all available tracks in the room. Since v4.1 the clients can decide to subscribe to only a subset of tracks in the room.

The frontend was updated to keep the behavior the same as before: it will subscribe to all available tracks. However, this change allows us to design an interface that would subscribe to only a handful of tracks and could ultimately improve performance in larger rooms.

Upgrade to pion/webrtc/v3

Pion itself brought new fantastic changes in version 3, but upgrading took longer than expected because I initially designed the Peer Calls' SFU with the wrong abstractions. The main change was using the track's SSRC as the track ID. This could cause weird issues, like SSRC conflicts even between peers in the same room. Peer Calls now uses the StreamID and the track kind to identify different tracks.

The second change was that it was no longer needed to keep track of the same PayloadType between different peer to peer connections as Pion handles it automatically for us now. This makes it easier to broadcast and receive tracks to and from different browsers, while previously Pion was expecting tracks from all browser to have the same payload type so we had resort do some crazy hacks to fix this. Instead of the PayloadType, we now use the media's MIME type and codec parameters to describe the type of payload.

Finally, the addition of interceptors made it easy to write RTP and RTCP processors, and Pion added support for automated handling of sender and receiver reports. This means that we should see improved lip-sync in Peer Calls!

Play Command

The main peer-calls CLI command has been refactored and now accepts different sub-commands. The default action is still to start a server. There is a new peer-calls play command which can play local RTP streams into an existing Peer Calls room. I originally used it for testing lip-sync, but it could be used for other things.

Automatic Reconnects

Peers will now automatically try to reconnect after the websocket connection is lost in SFU mode. This means that connectivity interruption should be minimized after a service restart or a deploy.

What's Next?

Performance Benchmarks

Even though I made some smaller benchmarks, I would still like to see how much load can Peer Calls handle, and what could be done to optimize this.

If you are a user of Peer Calls and run into a use-case where it doesn't perform well, please let us know by opening an issue.

Some Prometheus metrics were never fully functioning as expected and this is something that will need to be fixed in one of the next releases.

Auhentication Provider

Peer Calls was always designed with simplicity in mind, and that's why there's no user session management. Some users said that hey would like to be able to control what permissions users have in specific rooms, so we'll add the ability to integrate with a "permissions provider", which should automatically populate the nickname, and tell Peer Calls if the user has the permission to join the room, and broadcast or publish tracks.

Simulcast Support

Ever since the support for Simulcast has landed in Pion around June 2020, this has been at the back of my head. I'd really like to add support for it within Peer Calls.

None of this wouldn't be possible without the awesome pion/webrtc library, so I'd like to express special thanks to Sean DuBois for his help and patience.

After fixing several issues that came up while writing Peer Calls, I was happy to become a member of the Pion organization on GitHub and try to help out whenever I can.

If you're interested in Peer Calls, feel free to leave a comment below - I'd love to hear from you!