Home

Awesome

<p align="center"> <img alt="STUNner", src="docs/img/stunner.svg" width="50%" height="50%"></br> <a href="https://discord.gg/DyPgEsbwzc" alt="Discord"> <img alt="Discord" src="https://img.shields.io/discord/945255818494902282" /></a> <a href="https://go.dev/doc/go1.17" alt="Go"> <img src="https://img.shields.io/github/go-mod/go-version/l7mp/stunner" /></a> <a href="https://pkg.go.dev/github.com/l7mp/stunner"> <img src="https://pkg.go.dev/badge/github.com/l7mp/stunner.svg" alt="Go Reference"></a> <a href="https://hub.docker.com/repository/docker/l7mp/stunnerd/tags?page=1&ordering=last_updated" alt="Docker version"> <img src="https://img.shields.io/docker/v/l7mp/stunnerd" /></a> <a href="https://github.com/l7mp/stunner/stargazers" alt="Github stars"> <img src="https://img.shields.io/github/stars/l7mp/stunner?style=social" /></a> <a href="https://github.com/l7mp/stunner/network/members" alt="Github Forks"> <img src="https://img.shields.io/github/forks/l7mp/stunner?style=social" /></a> <a href="https://github.com/l7mp/stunner/blob/main/LICENSE" alt="MIT"> <img src="https://img.shields.io/github/license/l7mp/stunner" /></a> <a href="https://github.com/l7mp/stunner/pulls?q=is%3Apr+is%3Aclosed" alt="PRs closed"> <img src="https://img.shields.io/github/issues-pr-closed/l7mp/stunner" /></a> <a href="https://github.com/l7mp/stunner/pulls?q=is%3Aopen+is%3Apr" alt="PRs open"> <img src="https://img.shields.io/github/issues-pr/l7mp/stunner" /></a> <a href="https://github.com/l7mp/stunner/issues?q=is%3Aissue+is%3Aclosed" alt="Issues closed"> <img src="https://img.shields.io/github/issues-closed/l7mp/stunner" /></a> <a href="https://github.com/l7mp/stunner/issues?q=is%3Aopen+is%3Aissue" alt="Issues open"> <img src="https://img.shields.io/github/issues/l7mp/stunner" /></a> <a href="https://hub.docker.com/repository/docker/l7mp/stunnerd" alt="Docker pulls"> <img src="https://img.shields.io/docker/pulls/l7mp/stunnerd" /></a> <a href="https://stunner.readthedocs.io/en/latest/" alt="Read the Docs"> <img src="https://readthedocs.org/projects/stunner/badge/?version=latest" /></a> <a href="https://github.com/l7mp/stunner/actions/workflows/test.yml" alt="Tests"> <img src="https://github.com/l7mp/stunner/actions/workflows/test.yml/badge.svg" /></a> <a href="https://coveralls.io/github/l7mp/stunner" alt="coverage"> <img src="https://img.shields.io/coveralls/github/l7mp/stunner" /></a> </p>

Note: This page documents the latest development version of STUNner. See the documentation for the stable version here.

STUNner: A Kubernetes media gateway for WebRTC

Ever wondered how to deploy your WebRTC infrastructure into the cloud? Frightened away by the complexities of Kubernetes container networking, and the surprising ways in which it may interact with your UDP/RTP media? Read through the endless stream of Stack Overflow questions asking how to scale WebRTC services with Kubernetes, just to get (mostly) insufficient answers? Want to safely connect your users behind a NAT, without relying on expensive third-party TURN services?

Worry no more! STUNner allows you to deploy any WebRTC service into Kubernetes, smoothly integrating it into the cloud-native ecosystem. STUNner exposes a standards-compliant STUN/TURN gateway for clients to access your virtualized WebRTC infrastructure running in Kubernetes, maintaining full browser compatibility and requiring minimal or no modification to your existing WebRTC codebase. STUNner supports the Kubernetes Gateway API so you can configure it in the familiar YAML-engineering style via Kubernetes manifests.

Table of Contents

  1. Description
  2. Features
  3. Getting started
  4. Usage
  5. Documentation
  6. Milestones

Description

Currently WebRTC lacks a virtualization story: there is no easy way to deploy a WebRTC media service into Kubernetes to benefit from the resiliency, scalability, and high availability features we have come to expect from modern network services. Worse yet, the entire industry relies on a handful of public STUN servers and hosted TURN services to connect clients behind a NAT/firewall, which may create a useless dependency on externally operated services, introduce a performance bottleneck, raise security concerns, and come with a non-trivial price tag.

The main goal of STUNner is to allow anyone to deploy their own WebRTC infrastructure into Kubernetes, without relying on any external service other than the cloud-provider's standard hosted Kubernetes offering. STUNner can act as a standalone STUN/TURN server that WebRTC clients and media servers can use as a scalable NAT traversal facility (headless model), or it can act as a gateway for ingesting WebRTC media traffic into the Kubernetes cluster by exposing a public-facing STUN/TURN server that WebRTC clients can connect to (media-plane model). This makes it possible to deploy WebRTC application servers and media servers into ordinary Kubernetes pods, taking advantage of the full cloud native feature set to manage, scale, monitor and troubleshoot the WebRTC infrastructure like any other Kubernetes workload.

STUNner media-plane deployment architecture

Don't worry about the performance implications of processing all your media through a TURN server: STUNner is written in Go so it is extremely fast, it is co-located with your media server pool so you don't pay the round-trip time to a far-away public STUN/TURN server, and STUNner can be easily scaled up if needed just like any other "normal" Kubernetes service.

Features

Kubernetes has been designed and optimized for the typical HTTP/TCP Web workload, which makes streaming workloads, and especially UDP/RTP based WebRTC media, feel like a foreign citizen. STUNner aims to change this state-of-the-art, by exposing a single public STUN/TURN server port for ingesting all media traffic into a Kubernetes cluster in a controlled and standards-compliant way.

The main uses of STUNner are hosting a scalable STUN server pool in Kubernetes, as a public Kubernetes-based TURN service, or as a fully-fledged gateway service for ingesting and load-balancing clients' media connections across a pool of WebRTC media servers hosted in ordinary Kubernetes pods.

Getting Started

With a minimal understanding of WebRTC and Kubernetes, deploying STUNner should take less than 5 minutes, in five simple steps.

Note that the default installation does not contain an application server and a media server: STUNner is not a WebRTC service in itself, it is merely an enabler for you to deploy your own WebRTC infrastructure into Kubernetes.

The simplest way to deploy STUNner is through Helm. STUNner configuration parameters are available for customization as Helm Values.

helm repo add stunner https://l7mp.io/stunner
helm repo update
helm install stunner-gateway-operator stunner/stunner-gateway-operator --create-namespace \
    --namespace=stunner-system

Find out more about the charts in the STUNner-helm repository.

Usage

STUNner comes with a wide selection of tutorials and demos that teach you how to deploy all kinds of WebRTC services into Kubernetes. The first couple of tutorials present the basic concepts, especially the use of the Kubernetes Gateway API to configure STUNner and the turncat utility to test it. Each subsequent demo showcases a specific WebRTC application, from desktop streaming and video-conferencing to cloud-gaming, and goes from a clean Kubernetes cluster to a working and usable publicly available WebRTC service in 5-10 minutes using a purely declarative configuration.

Documentation

The documentation of the stable release can be found here. The documentation for the latest development release can be found here.

Milestones

Help

STUNner development is coordinated in Discord, feel free to join.

License

Copyright 2021-2023 by its authors. Some rights reserved. See AUTHORS.

MIT License - see LICENSE for full text.

Acknowledgments

Initial code adopted from pion/stun and pion/turn.