TurnCafe a new side project

Some weeks ago, I started a new side project around Coturn to progress and understand better how to deploy it and how to monitor it. Here is the story around that project.

TurnCafe: the objective

When I started TurnCafe, the objective was clear! I wanted to have my own Coturn instance somewhere in the cloud to be able to understand better how it works, how to configure it and finally what can be done to monitor it.

I decided to investigate on that track because I saw some companies who had deployed their own Coturn instances and who encountered issues to use them correctly. Or these same companies had no way to know that their Coturn were down except when users were complaining to not being able to make calls or by checking manually every day if the process is still up…

For me, it was difficult to try to help without having experimenting myself. So, I decided to invest some time to work on two things: At first a service that is able to monitor and extract traffic from Coturn and then a web dashboard that delivers these data to an admin.

This was the idea behind TurnCafe!

IT skills to the rescue

Starting this project was not easy for me as I have never managed a Linux instance on Amazon nor had installed a Coturn server.

Hopefully, there is a lot of articles available on Internet that explain how to do that. Here are some good links:

• How to create and configure your own STUN/TURN server with coturn in Ubuntu 18.04

• How to Install Coturn

• Setup Your Own Coturn Server Using AWS EC2 Instance

• How to configure a TURN server

• Setting up a TURN server with Node: Production-ready

These articles describe how to install Coturn and how to configure it. This second part is more interesting because it was a bit more complicated on Amazon as I had to configure the relay-ip field in my etc/turnserver.conf.

In fact, without configuring the relay-ip field, I was thinking that my setup was complete and workable because when testing, the ICE part, I was able to get a reflexive srflx candidate and a relayed relay candidate. But When I tested a video call, I never succeeded to get my own video back from the TURN server without changing the relay-ip parameter.

A full video test is mandatory to validate that your Coturn server is correctly configured. Having reflexive and relayed candidates generated is not enough.

Once installed and configured, I wanted to access Coturn using a name and not an IP address so I added a DNS entry to my existing domain name that point to the Amazon instance.

And finally, I wanted to be able to quickly deploy it so I learned and used Ansible for that. It was not simple but having it now is not a luxury.

Pay the bill

At the beginning of the project, my fear was to pay too much for hosting a Coturn server and using it on my own.

After 3 months of usage, I never overcome the free threshold value regarding the bandwidth consumed. So I only paid for running the instance which is around €15 per month.

But be careful, do not let the video run during hours… In order to avoid bad mistake, all my video tests automatically stop after 20 seconds.

Minimum viable instance

For my own usage, I decided to use a very light machine, a t2.micro. With this machine, I have 1 virtual CPU, 1GiB of memory, 8 GB of storage and low to moderate network performance.

For sure, this is not the minimal requirement for a Coturn instance in production. After searching a while, a Coturn server should have at least two vCPUs, 4GB Memory and 20GB HDD or SSD. But the most important is the networking performance. So, on Amazon, a t3-medium or a c5-xlarge can be used.

TurnCafe minimal viable product

It was easy to find the features to develop around Coturn. Basically, I need to have:

• A Visual Dashboard: TurnCafe should help me to visualize the current state of the services by using a dashboard. For that, I not only want to have a clear status of Coturn (up and running), but i need to check live from that dashboard that everything works as expected.

• A call logs: TurnCafe should display also the last calls made through Coturn as well as the traffic that passes through. Additionally, some metrics such as the number of calls per day and the associated traffic used.

• Alerts: TurnCafe should alert me in case of any major troubles to avoid having to spend my time in front of the dashboard.

And finally, I would like manage Coturn such as stopping and starting it again or updating its configuration.

Current stage

At this time of writing, I have most of the services in place except the alerting part. I’m able to log-in and to have a clear status of the Amazon instance (basic mem & cpu & disk usage) and all services that run: Coturn, MongoDb and Redis.

I’m able to check the ICE part as well as the media part by having real calls through Coturn: I added graphs that display live the Jitter and the rtt.

Additionally, I list the last calls made and the traffic used.

I’m focussing now on the alerting part as well as adding some additional metrics around calls made during the current day or on a past period. I would like to add the MOS score for the call as well as a graph representing the packets lost during the call.

I will share more on the software architecture in the next article as well as sharing some screenshots from the dashboard.

Prometheus ?

For sure, using Coturn 4.5.2, I could use the Prometheus exporter and build a Grafana Dashboard in some hours or days.

But as I said, I need more that just having some data in a board. I want to test live the service and interact with Coturn to change its behavior.

That’s why I decided to invest on TurnCafe. The last thing is that I want in a near future to monitor and control my own WebRTC signaling server from TURNCafe to have a complete view of my services.