Open-source TURN Server Showdown: coTurn vs. STUNner

In this post, we’ll dive into the world of WebRTC NAT traversal by comparing two popular open-source TURN server solutions: coTurn and **STUNner**. We’ll explore the key features, community support, and ideal use cases of each, helping you determine which option best suits your deployment needs. Whether you’re managing a traditional WebRTC setup or a cloud-native application within Kubernetes, this guide will provide insights into choosing the right server to optimize connectivity and performance for your WebRTC application.

Disclaimer

Before we dive in, I want to be transparent: I am the CEO of **L7mp Technologies Ltd., the company behind STUNner. While I aim to provide an objective comparison, please consider my perspective with a grain of salt. My goal here is to share insights into both coTurn and STUNner**, highlighting each project’s strengths, use cases, and limitations to help you make an informed choice based on your own needs and deployment environment.

1. Why do you need a TURN server?

In today’s digital world, real-time communication has become essential, whether it’s video calls with friends, virtual meetings at work, live streaming, or online gaming. Web Real-Time Communication, or WebRTC, has emerged as a powerful technology to make these peer-to-peer (P2P) connections possible directly through a web browser, without the need for additional plugins or software.

However, establishing a direct connection between devices isn’t always simple. Many users are behind Network Address Translators (NATs), which can prevent devices from connecting directly to each other. This is where NAT traversal becomes essential, as it enables WebRTC to establish connections despite NAT restrictions.

TURN (Traversal Using Relays around NAT) and STUN (Session Traversal Utilities for NAT) servers play a crucial role in NAT traversal for WebRTC. STUN servers help devices determine their public IP addresses, which is useful for establishing connections when NATs are not overly restrictive. However, for scenarios where direct connections are blocked by stricter NAT types or firewalls, TURN servers step in to relay media traffic between clients.

In this blog post, we’ll explore two popular open-source projects, coTurn and STUNner, that provide STUN and TURN services to assist WebRTC in traversing NATs. While both projects aim to enhance WebRTC connectivity, they differ in their design, deployment environments, and ideal use cases. Whether you’re building a traditional WebRTC app or deploying in a modern, cloud-native environment, understanding the strengths and limitations of coTurn and STUNner will help you make an informed choice and hopefully avoid future headaches.

2. Overview of coTurn and STUNner

coTurn

coTurn is the most widely used open-source STUN/TURN server. Designed to function as a standalone server, coTurn enables WebRTC applications to establish P2P connections by providing relay services when direct connections are not feasible. It’s versatile, secure, and optimized for high-performance, making it ideal for traditional WebRTC deployments across a variety of environments.

Key Features of coTurn:

• Dual STUN/TURN Support: coTurn operates as both a TURN and STUN server, enabling it to support different NAT traversal requirements.
• Broad Compatibility: coTurn is compatible with on-premises, cloud-based, or hybrid environments, making it highly flexible.
• Protocol Support: It supports multiple transport protocols, including UDP, TCP, TLS, and DTLS, enhancing its interoperability across different networks.
• Security Options: It offers robust security features, such as TLS/DTLS encryption, for secure media transmission between clients.
• Scalability: coTurn can handle a high volume of connections and is suitable for applications with large user bases.

STUNner

STUNner is a modern, cloud-native STUN/TURN server built specifically for Kubernetes environments. While it leverages the same core functionalities as coTurn, STUNner is designed for cloud-native deployments and is optimized for use within Kubernetes clusters. Its design focuses on automated scaling, service discovery, and integration with Kubernetes tooling (e.g. Prometheus, Cert Manager, GitOps, Service Mesh), making it an ideal choice for dynamic, containerized WebRTC applications.

Key Features of STUNner:

• Kubernetes-native Design: STUNner is built specifically to run within Kubernetes environments, leveraging Kubernetes’ orchestration capabilities to streamline deployment and management.
• Seamless Service Mesh Integration: STUNner integrates well with service mesh frameworks like Istio or Linkerd, enabling it to fit smoothly into cloud-native architectures.
• Dynamic Scalability: Being cloud-native, STUNner supports Kubernetes-based scaling and load balancing, allowing it to adapt to the needs of highly dynamic environments.
• Automation and Orchestration: STUNner can be deployed and managed with Kubernetes-native tools, like Helm, to simplify scaling and configuration management in large-scale, multi-tenant applications.
• Enhanced Security: By utilizing Kubernetes’ security policies and service mesh features, STUNner provides additional layers of security, such as access control and encrypted communications.

Community and Project Support

When choosing technology for production WebRTC deployments, the community and support structure behind a project can be just as crucial as its technical capabilities. Both coTurn and STUNner have thriving user bases and provide valuable solutions for NAT traversal. However, the differing support structures and community dynamics between these projects can impact long-term reliability, security, and response times for issue resolution.

coTurn: Community-Driven but Limited Support Resources

coTurn has been a backbone of WebRTC for years, maintained largely by a dedicated community of contributors from various companies and organizations who rely on it. However, unlike many open-source projects with corporate backing, coTurn operates without a formal support team or a single company that takes ownership of its development. This “as-is” approach results in a slower pace for bug fixes and limited resources to address security vulnerabilities, particularly as coTurn is written in C, which can be more challenging to maintain and debug.

The lack of centralized support can create a backlog of unresolved issues. As of the latest count, there are nearly 350 open issues on coTurn’s GitHub, with many questions or bug reports remaining unanswered. This backlog has even led some in the community to question the project’s activity level and sustainability. Additionally, without active monitoring and quick responses, security vulnerabilities can persist in coTurn’s releases longer than ideal. For example, a recent image scan using Trivy on the latest coTurn Docker image (v4.6.2) found 116 security vulnerabilities, including 1 critical and 10 high-severity issues. These vulnerabilities might remain unpatched, which poses potential risks for users who depend on the latest Docker images for deployment, especially that coTurn usually needs to be deployed on the public internet.

Here is the command to reproduce this result:

$ docker run aquasec/trivy image coturn/coturn:4.6.2
…
coturn/coturn:4.6.2 (debian 12.7)
=================================
Total: 116 (UNKNOWN: 4, LOW: 80, MEDIUM: 21, HIGH: 10, CRITICAL: 1)

STUNner: Company-Backed with Fast Issue Resolution

On the other hand, STUNner benefits from consistent support and active maintenance from **L7mp Technologies Ltd., the company behind the project. With a dedicated team responsible for its upkeep, STUNner addresses issues swiftly, particularly when it comes to security vulnerabilities. In contrast to coTurn, an image scan of the latest stunner:1.0.0 release returned zero security vulnerabilities¹**.

Because STUNner has a company standing behind it, issues that affect the project’s core functionality or security are prioritized and resolved promptly. For users deploying WebRTC in production, this can be a critical advantage, as it provides peace of mind knowing there’s a team actively addressing potential vulnerabilities and other project needs.

I also want to add that STUNner builds on the Pion Go libraries for handling STUN and TURN sessions, which is a powerful open-source WebRTC library written in Go. Pion has become increasingly popular in recent years, thanks to its robust functionality and ease of use within WebRTC applications. With a growing, active community, Pion’s development is supported by contributions from many companies that depend on it for their own WebRTC and network traversal solutions. Also, the L7mp team members are actively contributing to the relevant Pion libraries (especially pion/turn) to solve issues and further develop the projects.

A Balanced Perspective

It’s essential to recognize the significant contributions of the coTurn community. coTurn remains a foundational tool in the WebRTC ecosystem, and the dedication of its maintainers and contributors has helped it serve as the default TURN/STUN server for countless WebRTC applications. However, relying solely on community support can be challenging for projects that demand regular updates and robust security.

With its formal support structure, STUNner fills a need for organizations that prioritize security, issue resolution, and long-term reliability. Yet, both coTurn and STUNner serve as excellent choices depending on user needs and their approach to managing support and security.

When to Choose coTurn vs. STUNner

Selecting the right TURN/STUN server can depend heavily on your application’s deployment environment and its unique requirements. Here’s a comparison of scenarios where coTurn or STUNner might be the better choice.

coTurn: Traditional WebRTC Applications with Comprehensive Protocol Support

coTurn is best suited for traditional WebRTC applications that require robust NAT traversal without the need for cloud-native or containerized infrastructure. Its extensive support for STUN/TURN RFCs² makes it ideal for applications that need deep protocol support and can benefit from its standalone flexibility. Examples include:

• On-premises WebRTC deployments: Where deploying within a Kubernetes cluster is unnecessary.
• High-compatibility requirements: For applications that demand detailed support for every facet of the STUN/TURN RFCs.
• Legacy environments: In cases where Kubernetes or containerization isn’t part of the deployment model.

In these scenarios, coTurn’s mature feature set and wide-ranging compatibility make it a dependable choice.

STUNner: Cloud-native WebRTC Applications within Kubernetes

STUNner is the clear choice for cloud-native WebRTC applications designed to run within Kubernetes environments. Built to leverage Kubernetes’ powerful orchestration, scaling, and automation capabilities, STUNner is ideal for modern applications that require:

• Cloud and On-prem Flexibility: STUNner leverages Kubernetes’ portability, allowing it to be deployed seamlessly in any cloud environment or on-premises infrastructure. This flexibility ensures that STUNner can support hybrid or multi-cloud architectures, making it adaptable to diverse deployment needs.
• Automated management: Leveraging Kubernetes-native tools for simplified deployment and maintenance, not just for the WebRTC media server, but for all other application components.
• Dynamic, large-scale deployments: Where applications need to scale up or down based on demand in a cost-effective manner.

For Kubernetes-based setups, STUNner offers seamless integration and a robust management framework, making it the go-to choice for dynamic, containerized environments.

Conclusion

Both coTurn and STUNner are powerful, reliable solutions for WebRTC NAT traversal, but each is optimized for different deployment needs. coTurn is excellent for traditional WebRTC use cases with detailed protocol requirements, while STUNner shines in cloud-native, Kubernetes-based environments where automation, scaling, and streamlined management are essential.

One final note: While STUNner is optimized for Kubernetes, it can also serve as a public STUN/TURN server with a quick setup of a (micro) Kubernetes cluster. In my next post, I’ll walk you through setting up a public STUN/TURN server using STUNner, making it accessible for applications outside of Kubernetes as well.

¹ Note: this is actually due to the fact that STUNner is written in Go, therefore we are able to build our Docker artifacts from a scratch image.

² For a comprehensive list of RFCs supported by coTurn, please check here. Since STUNner uses Pion libraries for the protocol implementations, please check RFC support here: pion/stun, pion/turn.