Does anyone have any experience with WebRTC STUN & TURN server called XTurn?

webrtc
#1

Our company is thinking of adding voice chat to our browser app in the future with WebRTC. I noticed that company called Xirsys released and open sourced Elixir based STUN & TURN server last year. Anyone has any experience with it?

More info


0 Likes

#2

It has unnecessary deps like :maru (more deps -> more auditing required), so that’s a red flag for me, personally. Both stun and turn protocols are not particularly complicated, so most companies I’d think could support an in-house implementation, but just in case, there are also https://github.com/processone/stun and https://github.com/esl/mongooseice which I’ve used and which worked well. But I’ve only ever needed and used them for supporting STUN since my webrtc server was on public network, and I didn’t need to relay any packets via TURN servers.

0 Likes

#3

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

1 Like

#4

:wave:

Not everyone needs an http api endpoint backed into a turn server. Might be a good idea to provide it as a separate. optional package.

0 Likes

#5

Our company is starting to create new version of our web app from scratch and we might be moving to Elixir from C#. In one part of our app we would like to have voice chat between our users in these maybe max 10 user sessions. One requirement is that it needs to be self-hosted.

Yesterday I showed my boss https://jitsi.org multi-platform open-source video conferencing and now he like to see if we could implement our voice chat with it and not create our own.

It’s probably not close as scalable or fault tolerant compared to something running in BEAM. We also need to see see if we can customize it enough for our needs. If that fails we will be creating our own solution. Maybe we could use XTurn or derive our solution from it if that happens.

Really like to see that talk but can’t be there in person, is it going to be recorded?

0 Likes

#6

You might consider https://github.com/meetecho/janus-gateway as well. Implementing webrtc server in erlang is quite hard right now (I know only of one successful closed-source attempt) due to inability to multiplex srtp/stun/turn on dtls connections.

For example, when I tried making a basic webrtc server about a year ago in elixir, I had to deal with stun binding requests being sent before dtls hello which crashed erlang’s dtls process … So I just went with janus and it worked out of the box.

0 Likes

#7

That API is for authorization right? If it is we need something like that. So that our server can create tokens for our client to access those SNAP and TURN servers to protect them from unauthorized access. I also came across SNAP/TURN server that seemed popular called coturn and it also has API like that.

0 Likes

#8

If it’s a standalone server, sure, api is needed, but if it’s used as a library, it’s not. I’d rather have my own http api server, which depends on a turn server library.

0 Likes

#9

True, also if that API was pluggable everyone could easily create their own API that fits their needs.

0 Likes

#10

Thanks I’ll look into it!

0 Likes

#11

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.

3 Likes

#12

The purpose of the server is to provide full WebRTC capabilities as simply as possible.

The server supports full DTLS and we’ve experienced no issues with it.

But that’s just for signalling and turn, right? Or do you plan to implement all webrtc protocols required for a webrtc client/server?

0 Likes

#13

It’s just for TURN. The server is STUN / TURN only, but will have RTP / RTCP and various audio / video decoding / encoding capabilities.

We find signalling tends to be a very personal matter. We have our own signalling services, but more people roll their own than opt for something pre-existing. Since signalling is typically just WebSockets, it’s not something that needs to be explained overly much.

1 Like