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

Question

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).

标签： webrtcturn

Answer 1

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.