Direct connections are renowned for their speed advantages compared to routed connections. ISL Online automatically selects the most effective connection technique, either by establishing a session tunnel directly between the local and remote computer (direct connection) or through a routed connection (standard connection). In this article, we will describe both methods.
Important: To utilize the direct connection feature, it's essential that the remote side also uses the latest versions of ISL Light (4.4.2332.100), ISL Light Client (4.4.2332.30), or ISL AlwaysOn (4.4.2332.54).
Direct Connection
ISL Light > In Session > Status Bar > "Direct Connection"
Once a direct connection is established, it will be indicated in the status bar for user visibility. Upon session establishment, ISL Light conducts ICE (Interactive Connectivity Establishment) candidate checks.
ICE (Interactive Connectivity Establishment) candidates are potential network addresses that a device can use to establish a communication channel with another device. ICE candidates include various types of addresses, and their purpose is to help devices discover the most suitable path for communication, especially when dealing with Network Address Translation (NAT) and firewalls. The original connection to the ISL Conference Proxy (using MUX transport) remains necessary for sending metadata, while the actual data is offloaded to the direct connection if available.
During the ICE process, devices exchange their lists of candidates, and connectivity checks are performed to determine the optimal path for communication. The negotiation and selection of candidates are part of the ICE protocol, allowing devices to adapt to different network environments and establish a reliable communication channel. ISL Light assesses the quality of MUX (Multiplexing) transport versus ICE transport. This evaluation considers factors such as ping time, with quality determined based on the latency in communication. The system selects the connection with the lower ping time to ensure optimal performance.
The main types of ICE candidates are:
Host candidates
These are the local IP addresses of the device itself. Host candidates represent the device's actual network interfaces and are used for direct connection when both devices are on the same local network.
Direct Connection diagram via Host candidates in Local Area Network (LAN)
For the host candidate, the connection initiates (blue line) within the Local Area Network (LAN), originating from the operator's computer. It traverses NAT to reach the ISL Conference Proxy (ICP). Similarly, the client's connection follows a comparable route. From there, the connection proceeds (red line) from the operator's computer, passing through NAT to a STUN server, with the same process occurring from the client's end. Following this route, the direct connection session (green line) is established between the operator and client computers.
Server-reflexive candidates
Server-reflexive candidates are acquired through STUN (Session Traversal Utilities for NATs) servers. STUN servers reflect UDP (User Datagram Protocol) packets back to the device, allowing it to discover its external address and port visible to the internet. This helps in establishing communication with devices outside the local network, overcoming NAT (Network Address Translation) barriers.
Direct Connection diagram via Server-reflexive candidates (STUN Server(s))
For the server-reflexive candidate, the connection starts (blue line) with the operator's computer passing through NAT, then to the ISL Conference Proxy (ICP). Likewise, the client's connection follows a comparable route. From there, the connection proceeds (red line) from the operator's computer, passing through NAT to a STUN server. The same process occurs from the client's end. Following this path, the direct connection (green line) is established between the operator and the client.
Relay candidates
Relayed candidates are obtained through a TURN (Traversal Using Relays around NAT) server. In cases where direct communication is not possible due to restrictive firewalls or symmetric NAT, devices can use a relay server to relay their data through a third-party server. TURN candidates help in establishing communication when other methods fail.
Direct Connection diagram via Relay candidates (TURN Server(s))
For Relay candidates, the connection starts (blue line) with the operator's computer passing through NAT, then to the ISL Conference Proxy (ICP). Likewise, the client's connection follows a comparable route. From there, the connection proceeds (red line) from the operator's computer, passing through NAT to a STUN server. The same process occurs from the client's end.
The key difference from server-reflexive candidates is that the direct connection (green line) is established via a TURN server between the operator and client.
Standard Connection
Without direct connection enabled in ISL Light, the connection pathway follows a standard route from the operator's computer to the network address translation (NAT) point, then to ISL Conference Proxy (ICP). Likewise, the client's connection follows a comparable route. This route relies on ISL Online's network of servers for relaying the data stream between the operator and client computers.
Standard Connection diagram via ICP Server(s)
Note: The direct connection feature can be disabled:
- via ISL Light settings
- via Command Line Arguments
- during a session by clicking on the "Direct Session Indicator" ("Direct Connection + Server") in the bottom left corner of the session window.