Establishing a peer to peer WebRTC connection
| Signaling | is the channel used to exchange initial info by the two parties wanting to establish a peer 2 peer WebRTC connection. |
| Connecting | Once each WebRTC endpoint learns where the other party can be found at (IP:port ICE candidates) the peer 2 peer connection can be established |
| Discovery | Each WebRTC endpoint will ask the STUN/TURN server for it’s own public IP and port where it can be reached. |
Signaling
- Signaling is the channel used to exchange initial info by the two parties wanting to establish a peer 2 peer WebRTC connection
- Signaling is NOT part of WebRTC spec
- Signaling server can run on ANY port
- Information exchanged:
a) Each party’s IP and port where they can be reached (ICE candidates)
b) Media capabilities - In restrictive networks, running signaling over port 80 or 443, ensures high connection rates for WebRTC
Discovery (STUN/TURN)
- Once a signaling connection is established between the two WebRTC endpoints and the signaling server, information can be exchanged
- A very important piece of information is the public IP and port at which each endpoint can be reached
- STUN (Session Traversal Utilities for NAT ) is used to get public IP/port if the computer is behind router/NAT
- TURN (Traversal Using Relays around NAT ) is used if the computer is behind symmetric NAT, to relay the data from the other endpoint since the other endpoint can not open a direct connection through the symmetric NAT to the device.
- Each WebRTC endpoint will ask the STUN/TURN server for it’s own public IP and port where it can be reached. Once a response is received the WebRTC endpoint will send the pair to the other party through the signaling channel. These IP/port pairs are called ICE candidates
Establishing a connection
- Once each WebRTC endpoint learns where the other party can be found at (IP:port ICE candidates) the peer 2 peer connection can be established
- Each client will send the data through UDP to the other endpoint:
- if it’s sending directly to the other party (to a host or srflx candidate) it will send to any port in the 0-65535 range
- if it’s sending to a TURN server (to a relay candidate) it will send to a port between 49152-65535
- There’s no way to control these ports, they will be allocated during the discovery phase and are part of the ICE candidates.
P2P Connections
Direct P2P connection
Connection through relay
STUN/TURN Communication Failure
- The default STUN/TURN ports are blocked
- All UDP ports are blocked
- The STUN/TURN protocols are blocked
Port Blocking
STUN and TURN have their own (different) default ports
- The default port for sending (or listening to) STUN/TURN requests is 3478.
- The default port for sending (or listening to) STUN/TURN over TLS is 5349.
- Google’s generic STUN servers use other ports like 19305 and 19307.
- Any of the ports mentioned above could be blocked for either of the two peers trying to connect to each other. In such a case the STUN/TURN servers cannot be reached resulting in no srflx or relay candidates.
- To avoid this such issues, one could use common ports for them STUN/TURN servers (443/80)
UDP Blocking
- By default STUN/TURN messages travel over UDP which means a (corporate) firewall which barely allows for DNS queries using port 53 to function over UDP will not permit STUN/TURN messages to pass through.
- Luckily STUN/TURN servers can also be communicated with using TCP by specifying the transport parameter in the URL like so:
- turn:myTurnServer.com?transport=tcp
- The above basically tells the WebRTC client “for this TURN/STUN server, connect over TCP instead of UDP”. You can also specify udp (the default value) or tls.
STUN/TURN blocking
The worst case scenario one could encounter is when the STUN/TURN protocol messages are blocked altogether. For example, it is found that Tunnel Bear VPN blocks STUN/TURN packets because they can expose your real IP even if you’re connecting through a VPN.
- In the above case there is not much can be done except correctly identify the issue and instruct the user to disable such apps during WebRTC calls.
Miscellaneous
- The port number used for signaling is not necessarily the same as the port number used to communicate with the STUN or TURN servers and is not the port number used to send data between WebRTC peers, once the connection is established.
- To ensure signaling will always work make sure it takes place over common ports like 443/80
- The ultimate fallback method that can be used for very restrictive networks (e.g. UDP blocked and symmetric NAT) is to configure a TURN server to be accessible over TLS on port 443 or TCP over port 80
- Communication with STUN/TURN servers can be blocked using port blocking, UDP blocking and STUN/TURN protocol blocking
- The STUN & TURN protocols can more easily be blocked than WebSocket communications which are just upgraded HTTP calls