Vectera establishes a connection between participants by making use of the WebRTC API, which is supported by all major browsers. Usually, WebRTC tries to create a direct connection from participant to participant, but in some cases this is not possible.
When a direct connection cannot be established, the Vectera relay server is used as a middle man. This indirect communication between the participants has a significant impact on latency and bandwidth and can be difficult to avoid. This article describes the most common causes and gives an insight in what is happening in the background.
How to avoid relayed traffic
The process to establish a direct connection (STUN) is dependent on certain techniques called "Hole punching" techniques. If these techniques fail to result in a direct connection, a relayed connection is necessary.
Endpoint-independent NAT mapping: If the NAT configuration is not set up with Endpoint-independent mapping, where an internal IP: port tuple will always have the same external IP: port tuple, hole punching can fail.
Firewall UDP restrictions: if a firewall restricts UDP traffic, WebRTC will fall back to transmitting its data to a TURN server as TCP packets.
Firewall port restrictions: Likewise, a firewall may be blocking traffic on certain ports resulting in a hole punching failure. The Vectera STUN server uses the default 3478 and/or 5349 ports for incoming connection requests, and uses a very wide 10000-60000 range for port mapping
This list is non-exhaustive but contains the most common causes. Fixing these issues should result in being able to create direct connections, in most cases. If you’re not certain how to fix these issues, contact your IT support with this information.
Background information
Local vs public IP address
In the modern web, not enough IP addresses are available to give each device its own unique address. To resolve this, a method called Network Address Translation is used: it gives the entire local network a single public address and it routes all incoming traffic to the relevant local device.
Session Traversal Utilities for NAT (STUN)
As modern networks don't assign a uniquely identifying address to each device, there is an obstacle to overcome when establishing a direct connection: NAT implies that the participant does not know the address that uniquely identifies its own machine. STUN is a method in which a Vectera server on the public internet mediates between the two peers by asking the networks for the adresses of both participants, and passing this information on to the other particiapant. This allows both machines to set up a route that directly connects both participants, while taking into account the NAT setups of both networks.
Traversal Using Relays around NAT (TURN)
The problem originates when even with STUN a direct connection is impossible. This can be due to firewall restrictions or incompatible network topology. The only way to resolve this is by having a server on the public internet that is able to directly connect to all possible network configurations. This server establishes a direct connection to both participants individually and acts as a relay through which all data passes. As the network traffic passes through a third party, using such a setup results in less available bandwidth and higher latency.