CODEWITHSUNDEEP
webrtcturn
Melvin Roest
Melvin Roest

Reputation: 1492

WebRTC: how does a TURN server differ from rolling your own custom server that passes communication through?

In understanding WebRTC, I found one thing difficult to understand about TURN servers. Let me quickly recap what I do understand.

A signaling server: is a custom (non-protocol specified) implementation of passing SDP packets to negotiate a WebRTC connection. The most fun/wacky implementation is where you copy/paste SDP packets in as plain text as explained by Chris Ball (sidenote: who said "implementation" means that you have to program something? :-D ).

A STUN server: it tells you your reachable IP + port. Bye bye NAT! Oh, only in 80% of the cases.

The other 20%, my understanding of TURN servers is: a server reachable for both (or more) P2P connecting parties that relays data from those parties through the TURN server (Traversal Using Relays Around Nat) and sends it to the other party. It is described in RFC 5766.

My situation (and the question that results from it)

  1. I have a signalling server (yay!)
  2. I have a STUN server (hurray!)
  3. I have a NodeJS server running with Socket.io for when P2P fails via the signalling and STUN server. It simply gets incoming traffic and broadcasts it to whomever needs to listen in.

I know that my server is a custom-built thing that achieves the same thing as a TURN server would.

My question: how is such a custom-built server different when compared to a TURN server?

Note: in my case it's NodeJS + Socket.io, but it could be any custom-built server (for fun, I also created a Ruby/Rails implementation with WebSockets without HTTP long polling as a fallback).

Upvotes: 0

Views: 1268

Answers (2)

Ashim
Ashim

Reputation: 473

Well maybe because we don't want an overhead of building a relay server from scratch when there are some good and free implementations like coturn and restund. You'll need to spend quite a lot of time achieving same level of performance and scalability.

Also, with a TURN server in place, you don't need a separate STUN server.

Upvotes: 1

Polaris
Polaris

Reputation: 712

Usually socket.io and Node is used for signaling (and sending custom messages) only. A simple CoTurn instance can run on a 5$ vps.

Besided the use as a turn server it also offers stun functionality, but in my experience it's always a good idea to also use the public google STUN (Except in China, it's not reachable).

The question is: Have you checked the network and system load with your implementation and compared it to a classical TURN setup?

Upvotes: 1

Related Questions