What’s new in STUNner v1.1.0
The l7mp.io team is proud to present STUNner v1.1.0, the second GA release of the STUNner Kubernetes media gateway for WebRTC. This release marks the culmination of a half-year development and stabilization work to bring your favorite WebRTC ingress gateway suite to a carrier-grade level. Below are some highlights from this latest release.
Deprecations
Originally, deploying STUNner required a separate installation of the stunner/stunner-gateway-operator Helm chart to deploy the control plane, plus the stunner/stunner chart that would deploy the dataplane that actually implements the TURN gateways. With the introduction of the managed dataplane mode that allows the STUNner gateway operator to deploy the TURN server pods on demand, the legacy dataplane mode has become obsolete and it has gone mostly unmaintained in the last couple of releases. With the v1.1 release support for the legacy mode has been removed. In addition, the stunner/stunner Helm chart will now install the gateway operator instead of a standalone dataplane.
Commercial release
The open-source STUNner release line has served our growing user base solidly throughout the last couple of years, making WebRTC available as a native Kubernetes service in a wide range of applications, from cloud-gaming to live streaming and conferencing. That being said, there are still a couple of issues that prevent large-scale enterprises to migrate from legacy TURN server frameworks to STUNner. Chiefly among these is performance (what else?): while Go, the programming language we used to develop STUNner, has provided solid performance for small to medium-scale deployments, the runtime overhead of the memory-managed Go runtime has proved to be a bottleneck in some extremely large use cases. In addition, operating STUNner as a public STUN or TURN service still does not go as smoothly as it should.
The new commercial release brings STUNner to a carrier-grade level. Our industry-leading Linux/eBPF based TURN acceleration framework reduces STUNner’s CPU footprint more than hundred-fold. This makes it possible to serve beyond 100 Gbps TURN/UDP traffic with a single Linux server. User quota support helps mitigate DDoS attacks, and the STUN server mode, the “Daemonset” dataplane deployment option, and the relay address discovery feature simplify the deployment of STUNner as a public STUN and TURN service.
The latter features are be available from the basic member tier, while the full enterprise tier also includes TURN offload on top of all member-tier features. All this with STUNner’s unique scalability, security and observability that our users have come to expect throughout the years. Check the pricing and subscribe to the premium STUNner releases today!
ICE tester
Cloud providers’ Kubernetes offerings differ widely in terms of WebRTC readiness; especially UDP LoadBalancer support and the trillions of AWS/EKS subtleties have proved major recurring pain points. Unsurprisingly, lots of users have asked for a reliable way to test and troubleshot a fresh STUNner installation.
The current best practice is to deploy a simple STUNner tutorial and check whether everything works as expected; we recommend the UDP echo service or the “simple-tunnel” tutorials for initial testing. While this is fine for verifying the cases when STUNner actually works, it does not provide useful clues to debug broken installations.
This release contains the first experimental release of the stunnerctl icetest tool. Issuing stunnerctl icetest will deploy a full WHIP server into your Kubernetes cluster, configure STUNner to expose it on a temporary gateway and fire up a WHIP client to connect to the server. If something breaks, the ICE tester tool will print a useful diagnostic message to help fix the problem. Otherwise it will preform a simple load test and report the ICE candidates along with some performance indicators (packet rate, loss, RTT) for both symmetric and asymmetric ICE over UDP as well as TCP.
Here is a sample of a TURN/UDP test:
stunnerctl icetest - force-cleanup - packet-rate 100 - timeout 2m udp
Initializing… completed
Checking installation… completed
Checking Gateway… completed
Obtaining ICE server configuration… completed
Running asymmetric ICE test over TURN-UDP… completed
Statistics: rate=95.00pps, loss=0/1900pkts=0.00%, RTT:mean=20.47ms/median=20.33ms/P95=22.19ms/P99=22.99ms
LocalICECandidates:
* udp4 relay 10.244.0.62:54112 related 0.0.0.0:60966 (resolved: 10.244.0.62:54112)
RemoteICECandidates:
* udp4 host 10.244.0.175:53063 (resolved: 10.244.0.175:53063)
Running symmetric ICE test over TURN-UDP… completed
Statistics: rate=95.00pps, loss=0/1900pkts=0.00%, RTT:mean=25.92ms/median=20.68ms/P95=65.45ms/P99=127.69ms
LocalICECandidates:
* udp4 relay 10.244.0.62:38284 related 0.0.0.0:34800 (resolved: 10.244.0.62:38284)
RemoteICECandidates:
* udp4 relay 10.244.0.62:54782 related 0.0.0.0:52361 (resolved: 10.244.0.62:54782)Observe how the asymmetric ICE mode the test connects over a pair of a local TURN relay candidate and a remote host candidate, while the symmetric ICE mode test uses two TURN relay candidates. The test will also dump a couple of simple performance indicators (packet rate/loss and round-trip-time) that can be used to get a quick idea of the media quality one can expect from a real WebRTC media server deployment.
Note that the ICE test tool is currently experimental: it works most of the time but lacks extensive testing. Please report any issues and help us make this tool a rock-solid helper utility in the upcoming releases.
Miscellaneous improvements
As usual, this release comes with a number of fixes, additions and improvements all over the place. Chiefly among these are new STUNner tutorials (most importantly, a new Elixir example), metric export ported to Open Telemetry, various stunnerctl extensions, and several improvements in the STUNner authentication service.
Enjoy STUNner, join us at Discord, and don’t forget to support us!
