coTURN: the open-source multi-tenant TURN/STUN server you were looking for

Last year we interviewed Oleg Moskalenko and presented the rfc5766-turn-server project, which is a free open source and extremely popular implementation of TURN and STURN server. A few months later we even discovered Amazon is using this project to power its Mayday service. Since then, a number of features beyond the original RFC 5766 have been defined at the IETF and a new open-source project was born: the coTURN project.

Today we are catching up  with Oleg again to see what’s new and to learn what coTURN is about.

{“intro-by”, “victor”}

Photo courtesy of flikr user Grant Nicholson

---

 

webrtcHacks: Last time we interviewed you, we discussed the rfc5766-turn-server project and learnt there were some commercial services using it, including WebRTC and non-WebRTC environments. What is this new coTURN project and how is it different from the original and popular rfc5676-turn-server?

Oleg: The TURN and STUN protocols are quickly developing, embracing the new network connectivity requirements and providing newer and more robust capabilities. At one point, we observed that the new requirements may be in conflict with the current “legacy” users demands, and we decided to split the project into the two lines of development with two different support models. The old project, rfc5766-turn-server, will continue benefiting from the stable code and large number of users; it has trusted verified code with minimum changes Only the bug fixes and absolutely necessary changes are added to the old project. That project is going to continue to exist and be supported as long as the legacy old-style RFC5766-compliant solutions are still in demand.

The new project, that got the name “coTURN” – well, a sort of “TURN with co-location of multiple realms” – was started in April and announced in May 2014. The main initial difference was thenew draft specification for multiple-realms with ORIGIN attribute support that was proposed in the new IETF TRAM working group.

webrtcHacks: Some of our readers might not be familiar with the TRAM work we are doing at the IETF, can you briefly comment on this?

Oleg: Sure, the goal of the new TRAM Working Group is to consolidate the various initiatives to update TURN and STUN to make them more suitable for the WebRTC environment. The work includes:

• the addition of DTLS as an additional transport
• authentication mechanisms, and
• extensions to TURN and STUN.

In fact, as you know we are working now on TURNbis and STUNbis drafts. IMHO the most important feature of the forthcoming new standards is the new authentication/authorization mechanism, based upon oAuth. For enterprise and ISP users, the multi-tenant server is a major feature.

Besides this, many minor additions are coming:

• ALPN,
• bandwidth control, and
• dual allocations for both IPv4 and IPv6.

webrtcHacks: And there you defined the ORIGIN attribute you mentioned before…

Oleg: Right, one of the things we have defined is the new ORIGIN attribute, which allows realm selection on per-session basis. The coturn database may now contain users grouped in multiple realms, each with possibly different realm parameters. That allows coturn in complex large setups, when on a single IP address and port we may want to run multiple groups of users. That may be the case for a large Enterprise TURN server, or for an ISP-controlled TURN server.

webrtcHacks: Did the move to multi-tenancy require a major change in architecture vs. the rfc5766 turn-server project?

Oleg: It did not require a major change in the architecture, but it required lots of changes in the data management in the program. Many things that were assumed to be “global” across the system are now realm-specific. That required a substantial code restructuring work that took the major part of the transition process.

webrtcHacks: Have you included any other features beyond this multi-tenancy support?

Oleg: Yes, another big change in coturn is the dual-allocation. With that new feature, the server can allocate two relay endpoints for a single session: one for IPv4, and another for IPv6. If a TURN client has to establish communications with both IPv4 and IPv6 peers, then the client now can handle both communication sets within the same session, saving resources both on client and on server.

Coturn also supports new bandwidth specs that allow some level of bandwidth allocation control on the server. That is helpful when we want to provide some guaranteed level of service for the TURN clients.

webrtcHacks: I’ve been following the project commits and noticed you did some work also on the database support. Can you comment on that?

Oleg: Coturn has a re-written database code, with more robust database communications abstraction. That helps with the new features development and with the new databases adoption. For example, Coturn supports now MongoDB, in addition to Redis, Mysql and Postgres supported by the old project.

webrtcHacks: How about security, any improvements on that space?

Oleg: Yes, the current ongoing coturn development is about the new oAuth-based third-party client authentication and authorization. It is supposed to fix a number of TURN security issues. The coturn server will be retrieving the oAuth keys from the database, and an independent external agent will have to handle the keys database.

webrtcHacks: What kind of performance testing have you done on coturn? How does it perform vs.rfc5766-turn-server?

Oleg: Coturn is subject to the same performance test suite as rfc5766-turn-server. The coturn code and functionality is more complex so theoretically there must be a performance drop. But our tests did not reveal any noticeable performance degradation.

The server can handle thousands simultaneous calls per CPU when the TURN protocol is used or tens of thousands calls when only STUN protocol is used.

webrtcHacks: What are the design decisions you believe led you to these performance numbers?

Oleg: To achieve high performance and scalability, the TURN server is implemented with the following features:

• Use of libevent2 – a high-performance, industrial-strength network IO engine
• Configurable multi-threading model to allow full usage of available CPU resources if the OS allows multi-threading
• Configuration of multiple listening and relay addresses
• More efficient memory model
• The TURN server works as a user space process, without imposing any special requirements on the system

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, we only provide an implementation for the standard UNIX Networking/IO API, 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.

 

webrtcHacks: How do you handle scale and load balancing?

Of course, 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 (which requires 300 response support by the TURN client)
• network load-balancer server

webrtcHacks: Do you have any data on how often a TURN server is needed to provide media relay?

Oleg: Different statistics sources provide different data. Usually all statistics are within 8 to 15 percent of all media calls. Of course there are custom specialized applications when 100% of connections are made through the TURN server, but from what I’ve seen those are not WebRTC applications.

webrtcHacks: Have you come across any scenarios where the developer is forcing all traffic through the TURN server – essentially treating it like a SBC in a traditional VoIP network?

Oleg: I do not have definite information about such scenarios in WebRTC worlds, although there were some discussions about that network pattern by some enterprise users, so I assume that such cases are possible.

webrtcHacks: What are the platforms supported for coturn?

Oleg: The list is long – the supported project target platforms are:

• Linux – including Debian, Ubuntu, Mint, CentOS, Fedora, Redhat, Amazon Linux, Arch Linux, and OpenSUSE;
• BSD – including FreeBSD, NetBSD, OpenBSD, and DragonFlyBSD;
• Solaris;
• Mac OS X and
• Cygwin – for non-production R&D purposes.

This project can be successfully used on other *NIX platforms, too, but that is not officially supported.

Any client platform is supported, including Android, iOS, Linux, OS X, Windows, and Windows Phone.

webrtcHacks: Last year you mentioned you wanted to add some performance monitoring with statistics. Does coturn include anything like that?

Oleg: Currently, we have some performance monitoring data included into the telnet interface to the TURN server, and some performance statistics is available through the Redis statistics database. Aside from statistics, the recent releases of the TURN server have performance-based congestion control mechanism. This mechanism is active for the TCP and TLS connections and allows efficient automatic performance tuning of the TCP/TLS connections.

webrtcHacks: Can you provide any insight into your future roadmap for coturn?

Oleg: Coturn is supposed to follow all the latest TURN and STUN features. The IEFT TRAM group is moving toward adoption new TURN and STUN RFCs, codenamed TURNbis and STUNbis as I mentioned earlier. When the RFCs are eventually finalized, the coturn server will be ready for the new specs support.

In addition to that, we would love to add a separate management server that handles the database, REST API, etc. We are short of resources, so any volunteer help would be very appreciated.

webrtcHacks: where can our readers find more information on coturn?

Oleg: the best place is our project website – https://code.google.com/p/coturn/ We try to link to everything one might need from there.

 

{“interviewer”, “victor“}

{“interviewee”, “Oleg Moskalenko“}

{“editor”, “chad“}