mirror of
https://github.com/coturn/coturn.git
synced 2026-10-05 19:14:38 +02:00
coturn TURN server project
- C 91.8%
- CMake 3.9%
- Shell 1.7%
- C++ 1.3%
- Makefile 0.8%
- Other 0.4%
d8107aff80## Problem Every macOS job in CI currently fails: `turnserver` segfaults on the first TLS client in `examples/run_tests.sh` (e.g. run 37231739523 on #2093, which only touches `dbd_sqlite.c`). Cause: Homebrew's `openssl` formula now resolves to `openssl@4` (4.0.3), but the libevent bottle's `libevent_openssl` still links `openssl@3`. coturn builds against OpenSSL 4 and passes its `SSL*` to libevent running on OpenSSL 3 via `bufferevent_openssl_socket_new`, which crashes in `SSL_set_bio`. macOS two-level namespaces keep both copies loaded. ## Changes - `.github/workflows/macos.yml`: install `openssl@3` and export `OPENSSL_ROOT_DIR` / `PKG_CONFIG_PATH` for both the autotools and CMake jobs. - `cmake/CheckLibeventOpenSSL.cmake` (new), used from `src/apps/common/CMakeLists.txt`: on macOS, fail configure when `libevent_openssl` links a different OpenSSL major than the one found. - `configure`: same check for the autotools build (Darwin only). - `TURN_ALLOW_OPENSSL_MISMATCH` (CMake option / env var) overrides the check. ## Testing On macOS (both `openssl@3` 3.6.5 and `openssl@4` 4.0.3 installed): - CMake configure with the default OpenSSL (`openssl@4`) fails with the new error. With `-DOPENSSL_ROOT_DIR=$(brew --prefix openssl@3)` it passes, and `-DTURN_ALLOW_OPENSSL_MISMATCH=ON` also passes. - `./configure` with `openssl@4` first on `PKG_CONFIG_PATH` aborts; with `openssl@3` first it passes, and the override also passes. - With the `openssl@3` build: `ctest` 21/21, and `run_tests.sh` (TCP/TLS/UDP/DTLS), `run_tests_conf`, `dtls_default`, `ipv6_relay`, `mobility_quota`, `mobility_resume_flood`, `stateless_binding`, `stateless_nonce` all pass with no FAIL or segfault. On Linux (Docker): CMake configure, build and `ctest` (20/20) pass; the check is a no-op there. I did not complete the Linux `run_tests*.sh` pass. The PR's own macOS CI jobs are the real end-to-end check. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com> |
||
|---|---|---|
| .github | ||
| .vscode | ||
| cmake | ||
| docker | ||
| docs | ||
| examples | ||
| filc | ||
| fuzzing | ||
| man/man1 | ||
| patches/openssl-1.1.1 | ||
| rpm | ||
| scripts | ||
| src | ||
| tests | ||
| turndb | ||
| .clang-format | ||
| .clang-tidy | ||
| .dockerignore | ||
| .gitignore | ||
| AUTHORS.md | ||
| authors.sh | ||
| ChangeLog | ||
| CLAUDE.md | ||
| CMakeLists.txt | ||
| configure | ||
| CONTRIBUTING.md | ||
| INSTALL | ||
| iwyu-ubuntu.imp | ||
| LICENSE | ||
| make-man.sh | ||
| Makefile.in | ||
| postinstall.txt | ||
| README.md | ||
| README.turnadmin | ||
| README.turnserver | ||
| README.turnutils | ||
| release.sh | ||
| STATUS.md | ||
| vcpkg.json | ||
Docker Hub | GitHub Container Registry | Quay.io
Coturn TURN server
coturn is a free open source implementation of TURN and STUN Server. The TURN Server is a VoIP media traffic NAT traversal server and gateway.
Installing / Getting started
Linux distros may have a version of coturn which you can install by
apt install coturn
turnserver --log-file stdout
Or run coturn using docker container:
docker run -d -p 3478:3478 -p 3478:3478/udp -p 5349:5349 -p 5349:5349/udp -p 49152-65535:49152-65535/udp coturn/coturn
See more details about using docker container Docker Readme
Developing
Dependencies
coturn requires following dependencies to be installed first
- libevent2
- libmicrohttpd (Prometheus metrics interface)
Optional
- openssl 3.0 or newer (to support TLS and DTLS, authorized STUN and TURN); older OpenSSL versions are not supported
- MariaDB/MySQL (user database)
- Hiredis (user database, monitoring)
- SQLite (user database)
- PostgreSQL (user database)
Building
git clone git@github.com:coturn/coturn.git
cd coturn
./configure
make
Features
STUN specs:
- RFC 3489 - "classic" STUN (DEPRECATED, opt-in via
--rfc3489-compatibility; scheduled for removal in the next major release — see docs/rfc3489-deprecation.md) - RFC 5389 - base "new" STUN specs (obsoleted by RFC 8489)
- RFC 8489 - STUN, obsoleting RFC 5389. Its message-processing
rules are implemented: attributes following
MESSAGE-INTEGRITYare ignored, repeated attributes are first-wins, andERROR-CODEreason phrases are declared without their padding. Its authentication additions are not implemented -MESSAGE-INTEGRITY-SHA256,PASSWORD-ALGORITHMS,PASSWORD-ALGORITHM,USERHASHand the nonce cookie are all absent, so an RFC 8489 client falls back to that spec's MD5 key derivation with SHA-1MESSAGE-INTEGRITY, which RFC 8489 permits. - RFC 5769 - test vectors for STUN protocol testing
- RFC 5780 - NAT behavior discovery support
- RFC 7350 - DTLS as transport for STUN & TURN
- RFC 7443 - ALPN support for STUN & TURN
- RFC 7635 - oAuth third-party TURN/STUN authorization
TURN specs:
- RFC 5766 - base TURN specs (obsoleted by RFC 8656)
- RFC 8656 - TURN, obsoleting RFC 5766 and folding in RFC 6156.
Implemented, including dual allocation (
ADDITIONAL-ADDRESS-FAMILY,ADDRESS-ERROR-CODE, the 440/443/508 error codes) and the 0x4000-0x4FFF channel-number range. ICMP relaying (Section 11.5, theICMPattribute) is not implemented: an unreachable peer produces silence rather than a Data indication. - RFC 6062 - TCP relaying TURN extension
- RFC 6156 - IPv6 extension for TURN (folded into RFC 8656)
- RFC 7443 - ALPN support for STUN & TURN
- RFC 7635 - oAuth third-party TURN/STUN authorization
- RFC 8016 - Mobility with Traversal Using Relays around NAT (TURN)
- RFC 7350 - DTLS as transport for STUN & TURN
- TURN REST API (http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00)
- Origin field in TURN (Multi-tenant TURN Server) (https://tools.ietf.org/html/draft-ietf-tram-stun-origin-06)
- TURN Bandwidth draft specs (http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-01)
ICE and related specs:
- RFC 5245 - ICE
- RFC 5768 – ICE–SIP
- RFC 6336 – ICE–IANA Registry
- RFC 6544 – ICE–TCP
- RFC 5928 - TURN Resolution Mechanism
The implementation fully supports the following client-to-TURN-server protocols:
- UDP (per RFC 8656)
- TCP (per RFC 8656 and RFC 6062)
- TLS (per RFC 8656 and RFC 6062): including TLS1.3; ECDHE is supported.
- DTLS1.0 and DTLS1.2 (per RFC 7350): the DTLS listeners are not started unless
--dtlsis given. - SCTP (experimental implementation).
Relay protocols:
User databases (for user repository, with passwords or keys, if authentication is required):
- SQLite
- MariaDB/MySQL
- PostgreSQL
- Redis
- MongoDB
Management interfaces:
- telnet cli
- HTTPS interface
Monitoring:
- Redis can be used for status and statistics storage and notification
- prometheus interface (unavailable on apt package)
Message integrity digest algorithms:
- HMAC-SHA1, with MD5-hashed keys (as required by STUN and TURN standards)
TURN authentication mechanisms:
- 'classic' long-term credentials mechanism;
- TURN REST API (a modification of the long-term mechanism, for time-limited secret-based authentication, for WebRTC applications: http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00);
- experimental third-party oAuth-based client authorization option;
Performance and Load Balancing:
When used as a part of an ICE solution, for VoIP connectivity, this TURN server can handle thousands simultaneous calls per CPU (when TURN protocol is used) or tens of thousands calls when only STUN protocol is used. For virtually unlimited scalability a load balancing scheme can be used. The load balancing can be implemented with the following tools (either one or a combination of them):
- DNS SRV based load balancing;
- built-in 300 ALTERNATE-SERVER mechanism (requires 300 response support by the TURN client);
- network load-balancer server.
Traffic bandwidth limitation and congestion avoidance algorithms implemented.
Target platforms:
- Linux (Debian, Ubuntu, Mint, CentOS, Fedora, Redhat, Amazon Linux, Arch Linux, OpenSUSE)
- BSD (FreeBSD, NetBSD, OpenBSD, DragonFlyBSD)
- Solaris 11
- Mac OS X
- Cygwin (for non-production R&D purposes)
- Windows (native with, e.g., MSVC toolchain)
This project can be successfully used on other *NIX platforms, too, but that is not officially supported.
The implementation is supposed to be simple, easy to install and configure. The project focuses on performance, scalability and simplicity. The aim is to provide an enterprise-grade TURN solution.
To achieve high performance and scalability, the TURN server is implemented with the following features:
- On linux platform, where available, UDP high throughput is achieved through recvmmsg/sendmmsg/GSO combination
- High-performance industrial-strength Network IO engine libevent2 in other cases
- Multiple listening and relay addresses can be configured
- Efficient per-thread memory allocation model is used
- The TURN project code can be used in a custom proprietary networking environment. In the TURN server code, an abstract networking API is used. Only couple files in the project have to be re-written to plug-in the TURN server into a proprietary environment. With this project, only implementation for standard UNIX Networking/IO API is provided, but the user can implement any other environment. The TURN server code was originally developed for a high-performance proprietary corporate environment, then adopted for UNIX Networking API
- The TURN server works as a user space process, without imposing any special requirements on the system
Links
- Project homepage: https://coturn.github.io/
- Repository: https://github.com/coturn/coturn/
- Issue tracker: https://github.com/coturn/coturn/issues
- Google group: https://groups.google.com/forum/#!forum/turn-server-project-rfc5766-turn-server