Tunneling is a process in which all of the logically distinct UDP and TCP flows of media and signaling packets between an endpoint and the StarLeaf platform, or between two StarLeaf endpoints in a point to point call, are wrapped in a single bi-directional flow pair, using one source and one destination port. Tunneling has the advantage of requiring only a single port to be opened in the customer’s firewall configuration and guarantees that all of the wide range of functions and media types supported by the endpoint will work once connectivity has been established.

Different tunneling protocols are used to connect to StarLeaf for StarLeaf hardware endpoints and software clients to optimize the usability and performance of each. Additionally, all StarLeaf endpoints use UDP tunnels to carry direct media in a two-party call where a routable path exists at the IP level between the endpoints.

Read on to learn more about the different tunneling protocols used by StarLeaf.

Tunneling for StarLeaf hardware

A StarLeaf endpoint sends outbound UDP packets to the StarLeaf platform border controller, and receives replies from it. The outbound packets are sent to one of the UDP ports 24704, 3478, 1194, 500 and 123 (123 is the well-known port for NTP servers, so has a high probability of being allowed through most firewalls).

Some firewalls do not allow outbound UDP traffic to be sent. In this case, the StarLeaf endpoint creates a TCP tunnel to port 443 of the border controller—this is a good fallback mechanism, but sending real-time media packets over TCP can result in a lower-quality user experience.

Tunneling for the StarLeaf app

Tunneling in the StarLeaf app is slightly different due to the nature of the mobile client. The app frequently reconnects to StarLeaf because every time you leave the app it disconnects (in comparison to a desktop phone, for example, that is on and connected all day). To optimize the user experience the StarLeaf app uses a split tunnel mode.

Priority for the app when connecting to StarLeaf is the time it takes to do so. The UDP tunnel takes longer to establish than TCP due to the need for reliable path MTU discovery, which involves multiple additional round trips between the client and the StarLeaf platform. For this reason, the app primarily uses TCP tunneling to port 443 for connecting to StarLeaf and all signaling, e.g. downloading configuration, looking up contacts, sending/receiving messages, and all call signaling.

The app maintains the TCP tunnel for signaling, but when the app goes into a call, a UDP tunnel is the preferred protocol for audio and video real-time media as it provides a better low latency experience, in comparison to media over TCP where latency increases in the presence of packet loss. For this reason, the app will try to open a UDP tunnel to transport the audio and video. This media tunnel persists only for as long as the user remains in a call. This should succeed, but in case it does not, the app can revert to transferring the audio and video over the existing TCP tunnel.

Note that screen sharing media is always sent over the TCP tunnel, because the latency requirements for screen sharing are less stringent whereas the effect of packet loss is notably worse. By using TCP for screen sharing, any packet loss is concealed by the retransmission mechanism built into TCP.

This is what we call split tunnel mode because the app ends up routing different classes of packets over two different types of tunnels.

In the case where the app cannot establish a TCP tunnel (due to firewall restrictions, for example) the app will revert to a single UDP tunnel for all traffic and therefore behave in the same way as the hardware endpoints described above.

Viewing connection type in the StarLeaf Portal

To view connection information in the Portal:

  1. Go to Users > Edit user
  2. Select one of dropdowns on either StarLeaf apps or Hardware endpoint to display the connection information for each

Even if the StarLeaf app is temporarily using a UDP tunnel, information in the StarLeaf Portal may say that the app is using TCP as this is the primary tunnel mode of choice.