For Internet telephony (audio/video telephony) via messenger/browser, certain technical requirements are necessary. Otherwise, calls can only be made to each other in certain constellations, such as only in the same WLAN. In connection with Internet telephony, terms such as “WebRTC”, “STUN “ and “TURN “ are used again and again, which are explained here and the basic functionality is explained …
The “Web Real-Time Communication” (WebRTC) (external) protocol is used to exchange sound and video information, which is an open standard for direct communication between computers. Current browsers also support this protocol, so that video conferences are thus possible without any problems - at least within a local network (LAN/WLAN).
If the devices involved are in different networks, a problem arises: The programs/apps need to know their own IP address and the IP address of the remote peer. Unfortunately, this is often not the case if they sit behind a NAT router, e.g. a Fritzbox. Here the devices only know their network-internal IP address, e.g. 192.168.1.52, but not the official IP address to the outside, which only the router knows.
This problem can be solved with a STUN server (Session Traversal Utilities for NAT). The computers involved report to the STUN server; in doing so, it learns their public IP addresses and can pass them on to the interlocutors. The devices can then use this information to communicate directly with each other.
The operation of a STUN server is relatively problem-free, since only very small amounts of data are generated. Therefore there are also public STUN servers.
Unfortunately, the STUN server is no longer enough these days. A router, like the Fritz!Box, does not only NAT, but also provides a firewall. Connections from outside, from the Internet, to the computers within the local network are thus not possible without releasing ports on the router and forwarding them to the target computer. This would be quite a complex procedure. Only connections from inside the respective network to publicly accessible computers are possible.
This is where the TURN server comes into play (Traversal Using Relays around NAT), it allows the clients to exchange data without a direct connection (relay server). All data traffic then passes through this server:
As a rule, you will not find public TURN servers, since right high data volumes are incurred. For a decent video quality 500 kbit/s are specified. At 3,600 seconds in one hour, that makes 500×3,600 = 1,800,000 kbit (which is almost 1,800 mbit), so already a considerable data volume.
WebRTC and TOR
Simultaneous use of TOR (The Onion Routing) and WebRTC is actually mutually exclusive. This is because when TOR is used, the IP addresses are not known to the endpoints involved, and using WebRTC would defeat the purpose of TOR.
Taken from source: debacher.de (external) and slightly adapted/added - Thanks Uwe!
More information and technical guide for WebRTC in HTML clients: https://www.baeldung.com/webrtc (external; english)