Understanding what a WebRTC signaling server does probably starts with this diagram:
The server at the top is how the two users find each other. Both are somehow connected to that server, which is left out of the scope of WebRTC. It can be two people registered to a social network, a doctor and a patient logging into a scheduled visitation, a person browsing a website and trying to “call” the site’s owner, etc. The options here are endless.
A WebRTC signaling server is a server that manages the connections between devices. It doesn’t deal with the media traffic itself, but rather takes care of… signaling. This includes enabling one user to find another in the network, negotiating the connection itself, resetting the connection if needed, and closing it down.
Part of what needs to be done involves attempting to go through firewalls and NAT devices. This is done using a protocol called ICE, which collects, exchanges, and then attempts to connect a session using ICE candidates. ICE candidates are pairs of potential addresses that can get the devices to connect to each other either 1) directly by using a private or a public IP address obtained via a STUN server or 2) indirectly through TURN servers.