What does HackerNews think of coturn?

coturn TURN server project

Language: C

#8 in Server
Sure thing.

The video and voice chat is powered by WebRTC. The getUserMedia API allows a browser to access the webcam and microphone of the device. I used my own simple-peer (https://github.com/feross/simple-peer) library to make WebRTC a bit easier to work with.

The server is Node.js. I'm using Next.js for the first time on this project. I usually use a custom Express server for my projects. I'm a fan of several of Next.js's decisions -- it feels really nice to use, if a bit limiting sometimes.

I use the 'ws' package (https://github.com/websockets/ws) to implement a WebSocket server which is used to help the peers get connected over WebRTC. Once peers are connected, all video and video is transferred directly in a peer-to-peer fashion.

Except sometimes the connection can't be established, so to improve reliability of WebRTC you need to set up a TURN relay server for those situations. I used coturn (https://github.com/coturn/coturn) for that.

Lastly, I used Chakra UI (https://chakra-ui.com/) as my React component library.

Really happy with how the easy the app has been to build.

The most difficult part was getting it to work on Safari for iOS. I spent about 50% of the effort working around various bugs in the Safari media stack. https://twitter.com/feross/status/1263544033135038464

Hope this was informative!

I have not made it open source atm, but it is something I am considering.

Tech stack: Elixir/Phoenix (liveview mostly) WebRTC code is based off: https://codelabs.developers.google.com/codelabs/webrtc-web/#...

I setup a turnserver using https://github.com/coturn/coturn

What do you need help with? Maybe I can help you now.

The biggest hurdle for us was learning the ins and outs of the spec.

The performance for video and audio is good. I'd say it is at least as good as Skype for the most part. This is somewhat dependent on which compression you use. H.264 is usually better for mobile devices since they often have hardware accelerated encoding.

If you are doing a hybrid app for mobile: Mobile support is spotty both on Android and iOS[1,2]. Android versions before 5.x use an old webview that has no support for WebRTC. This means you have to use the (abandoned) Crosswalk Project or do something with the native library. For iOS the situation is worse. Only the latest Safari 11 has support for WebRTC.

If building native app for mobile: You should not have any problem with compatibility. Building WebRTC on iOS is a bit tricky the first time so make sure to check out [5].

If you are developing for the browser you should use adapter.js [3].

Building a signal server isn't that hard. But there are a lot of moving components with offer/answer and ICE candidates that needs to work before you get a connection so my tip to start off with some demo code and modify it until you have something more suited to your needs. We don't use tokbox or twilio and have built signalling server and infrastructure ourselves.

You will most probably need a TURN-server to handle stubborn NAT:ed networks[4]. Maybe not so much for development but it will be needed when you go to prod.

Also feel free to email (in profile) me if you have any other questions.

[1] http://caniuse.com/#search=WebRTC

[2] http://iswebrtcreadyyet.com/

[3] https://github.com/webrtc/adapter

[4] https://github.com/coturn/coturn

[5] https://medium.com/@atsakiridis/building-a-fat-webrtc-framew...

You don't need STUN or TURN so long as you can be certain that your devices can talk to each other directly (without NAT punching or tunnelling). They exist because it's generally impossible to create peer-to-peer connections over the internet, unfortunately. Luckily, it's not difficult to set them up - [coturn](https://github.com/coturn/coturn) is a decent implementation. The major downside is that you're going to be paying for the bandwidth of anyone who can't make a direct connection.

The signalling server, though, just copies information about each peer to the other. Technically, you could transfer it any way you like - by carrier pigeon or through js-libp2p.