WebRTC works brilliantly when connecting browsers within the same local network. But as soon as you start reaching outside your network – into a corporate firewall, for example – you're going to need a little more, well, firepower. 

Firewall configurations won't let WebRTC in without using the STUN (Session Traversal Utilities for NAT) or TURN (Traversal Using Relays around NAT) protocol. This is why you'll need a server. 


What is STUN Server?

Sometimes, you can use a protocol called STUN (Session Traversal Utilities for NAT) that allows clients to discover their public IP address and the type of NAT they are behind. This information is used to establish the media connection. In most cases, a STUN server is only used during the connection setup and once that session has been established, media will flow directly between the peer and the Video Gateway (WebRTC).


What is TURN Server?

However, even if we setup properly a STUN server, there are very restrictive corporate networks (e.g: UDP traffic forbidden, only 443 TCP allowed…), which will require clients to use a TURN (Traversal Using Relays around NAT) server to relay traffic if direct (peer to Video Gateway) connection fails. In these cases, you can install our TURN server (in another instance) to solve these issues.

The TURN server is really easy to add for all your RTC developments, including it as another ICE server within the Video Gateway (WebRTC).


Read more at 

https://blog.vline.com/post/63765098884/webrtc-if-its-p2p-why-do-i-need-a-server


STUN or TURN? Which one to prefer; and why?

https://www.webrtc-experiment.com/docs/STUN-or-TURN.html