For typical users:
It is not normally necessary to make any adjustments to your firewall software or home network.
By default TCP ports 80 and 443 are open. Some firewall rules only allow for TCP traffic over port 443, make sure that all traffic can pass over this port.
Some firewalls may see TCP port 3478 being used for screen sharing. Please allow this port if you experience an error that screen sharing was blocked.
For Corporate IT Networks:
The mechanisms for WebRTC need to provide the web browser with a few key capabilities:
- Learn as best it can, the topology between itself, and the peer it wants to communicate with
- Establish connectivity on the best path through a given topology
- Have a fallback mechanism if all else fails
WebRTC standards require the use of three IEFT NAT traversal standards to address these issues:
- Interactive Connectivity Establishment (ICE) – RFC 5245
- Session Traversal Utilities for NAT (STUN) – RFC 5389
- Traversal Using Relay NAT (TURN) – RFC 5766"
Every WebRTC session requires the use of these tools when communicating with peers. Once the WebRTC sessions is properly signaled, and accepted, the process of NAT/Firewall discovery and traversal begins. When it is finished, a communication path is established and media can flow. Thanks to these tools, a good chunk of the problematic topology possibilities can be dealt with, and WebRTC can just work.
However, still not all cases are covered. If you have spent much time relying on WebRTC, you may have encountered times when no talk path was able to be established. The scenarios described in this post are the more common home broadband router cases, and they tend to be relatively easy for STUN, ICE, and TURN to overcome. Restrictive NATs and Firewalls found in enterprises, or hotel or courtesy WiFi hotspots can still cause issues.
If you require specific IP addresses to open channels for, please contact Customer Support. Please note that all IP Addresses are subject to change and use of the DNS entries above is recommended.