The included API is a starting point. The purpose of the server is to provide full WebRTC capabilities as simply as possible. This way, developers can shape it however they choose without hours spent learning how it works. Maru was chosen as it’s lightweight, but it can easily be ripped out and replaced.

The server supports full DTLS and we’ve experienced no issues with it. Running on a $5 virtual machine, I have achieved faster benchmarks than Google’s own servers.

As stated, this is just a starting point, but it’s a good starting point with less headaches.

The talk I’m giving in July is regarding using XTurn to debug WebRTC apps. Since its so simple, it’s perfect for finding flaws in such apps. I believe it is being recorded.

Another point you may find interesting; we are working with the Membrane Framework team to implement Membrane Source pads for video and audio pipelines in the server. I am currently working on a “record to file” example. It may prove useful to you.

Hi @wanton7. I am the author of that server. It is a fully capable WebRTC server and is a project that Xirsys intends to expand on. Can I be of service in any way?

I am giving a talk using XTurn in July at CommCon in London, btw.

Regards,
Jahred

So, a TURN server is also a STUN server. TURN extends the STUN specification by adding throughput capabilities. Any TURN server will also perform STUN bindings (but not the reverse).

TURN is used for situations where one peer can’t see the other clearly. All peers will be behind a NAT (the router that sits between your machine and the public internet) and some will be behind several NATs. Some NATs are more complicated than others, which is why TURN is required. Some NATs are too complicated even for TURN, but those are rare.

The TURN server should ideally sit on a sufficient machine. I ran that XTurn server (written in Elixir) on a cheap $5 VM and got better, faster throughput than Google’s own TURN servers. However, that was a handful of connections. If you plan on supporting thousands of simultaneous TURN connections, you’ll want a nice big VM with a chunky bandwidth.

For demos, I would strongly urge you to take a look at Muaz Khan’s experiments, here. There are loads available and they’re all bare-bones, so it’s a good resource to learn from.

Regards,
Jahred