Veeting Rooms tries to establish the most efficient peer-to-peer connections between meeting participants browsers whenever possible. This reduces latency and other network problems for your audio and video conversations.
Most routers and firewalls have these settings configured out of the box and no changes on your side should be required. However in certain circumstances you might need to adapt your network and firewall configuration for Veeting Rooms to work seamlessly in your particular environment.
No port forwarding is required for Veeting Rooms. There is no need to explicitly open any incoming ports to make Veeting Rooms work.
This is how an audio and video session is established between browsers:
Outgoing TCP connections are used to negotiate the audio and video data flows.
The STUN protocol is used for negotiation of the data flows (RFC 5389).
Allow unfiltered*, outgoing data flow to the ports 80, 443, 3478-3479 and 32768-65535 to the following IP addresses: 126.96.36.199, 188.8.131.52 and 184.108.40.206
*) The STUN/TURN protocols is different to the HTTP protocol that usually uses the ports 80 and 443. Thats why technologies such as DPI might prevent STUN protocol traffic to these ports.
Outgoing UDP connections are used for the actual audio- and video conversations as well as for peer-to-peer data channels between the participating browsers of a Veeting.
Outgoing UDP traffic should be allowed and activated on all ports. The WebRTC protocol does not define static ports. The involved systems choose a free local port for the communication. (See https://en.wikipedia.org/wiki/Ephemeral_port).
Should it not be possible to activate UDP for all outgoing connections then at it must at least be allowed to the IP addresses mentioned in the "Outgoing TCP" chapter above.
No incoming ports need to be permanently opened.
Meeting participants communicate whenever possible through a technology called "UDP hole punching" (See: https://en.wikipedia.org/wiki/UDP_hole_punching). This is a common technique in VoIP applications.
This technology does not work if two meeting participants sit behind symmetric NAT, or if "Restricted cone NAT" is used.