WebRTC environment: signaling, STUN and TURN servers

The WebRTC technology allows browsers or applications transmit audio and video streams between each other directly, without a media server in between in most cases.
But there should be some additional servers around to make this magic happen.

Signaling server.
Let's imagine, we have 2 peers that want to establish a direct connection and transmit streams between each other.

But they don't know anything about each other yet. So we need some third party service that will help them share the service information and start direct streams transmission. That's a job for a signaling server.

Peers interact with a signaling server to share the handshakes and start a direct peer-to-peer transmission.

NOTE: The traffic and calculation load of the signaling server is relatively low, but it's a core of your WebRTC connection system. We recommend you to deploy your own signaling server for production usage.
Check out this article for signaling server deploying information. 

STUN server
The scheme above works perfectly in local area network where each peer has its own IP address and there are no firewalls and routers between them.
But when it goes to the internet, peers can be hidden behind NAT and do not have any information about the external addresses of each other.

That's the point when we need a STUN server. It allows to detect peers public network addresses and establish a peer-to-peer connection behind a NAT.

NOTE: The traffic and calculation load of the STUN server is relatively low, so you can use a public one or deploy your own.

TURN server
This scheme works fine in most cases. But there is another problem that can prevent direct peer-to-peer transmission: a firewall. It can be placed at any point of the network and cut the direct WebRTC traffic.

A way to solve this problem is to use a TURN server. It has a public address, so both peers can interact with TURN server even behind firewalls. So when no direct peer-to-peer connection available, TURN server transmits audio/video streams of both peers just like a common media server. 

Check this article for TURN server deployment and usage information

NOTE: As TURN server transmits the media streams between peers it consumes a lot of traffic and requires a lot of calculation power, especially in a case of multiple peers processing. We strongly recommend you to have a dedicated server for this task and make sure that the traffic bandwidth is big enough to handle this task. 

  • Signaling server is used to let peers share service information to start the peer-to-peer streams transmission.
  • STUN server is used to let peers know each others external address to start the peer-to-peer streams transmission behind the NAT.
  • TURN server is used to let peers transmit streams to each other behind a firewall. There is no peer-to-peer streams transmission  in this case. All media traffic goes through a TURN server.