A StarLeaf endpoint must be registered to the StarLeaf Cloud to work.

All signaling to and from the endpoint is controlled by the StarLeaf Cloud and routed via a single host on the public Internet. This host has a DNS name like mycompany.call.sl, which resolves to the public IP address of a border controller within the StarLeaf Cloud. Every endpoint in the customer organization uses the same border controller.

The endpoint sends ‘probe’ packets to the border controller, which sends packets back in reply. A regular flow of packets, which is able to encapsulate any type of payload required, ensures that the customer’s firewall NAT pinhole is kept open. This is StarLeaf’s firewall traversal mechanism and is called a tunnel.

Because all endpoint signaling is controlled and routed via the StarLeaf Cloud, it is not possible to call a StarLeaf endpoint by its own IP address. StarLeaf endpoints cannot call third-party endpoints that use private IP addresses, but can call public IP addresses.

On point-to-point (two-way) calls within an organization, media (video, audio and content) takes the most direct route possible:

  • If the endpoints can route traffic to each other’s private IP addresses, the media will be sent that way
  • If the endpoints are on different LANs but can route traffic via each other’s public (NAT) addresses, the media will be sent that way
  • If no direct route can be found, the media will be backhauled to the organization’s StarLeaf border controller

On multipoint calls, or point-to-point calls where the far end is not a StarLeaf endpoint or is in a different StarLeaf organization, the media is backhauled to the border controller.

The following diagram shows the principles of registration.

Provisioning

The reseller creates the customer organization on the StarLeaf Portal. The location of the data center is determined by the geographical location of the organization. The reseller or customer administrator creates StarLeaf users and meeting rooms, assigning soft and hard endpoints as required. This is done on the StarLeaf Portal. The Portal generates registration credentials which take the form of a 12-digit QuickConnect code (for a hardware endpoint) or a single-sign-on login (for a soft client user). The Portal Tutorial for Resellers gives full details about provisioning.

Registration

The endpoint is connected to the customer’s LAN and acquires IP configuration details using DHCP (alternatively, these details can be statically assigned). The installer enters the registration credentials and the endpoint supplies them to config.starleaf.com using an outbound HTTPS (port 443) connection. The configuration server tells the endpoint which border controller to register with. In this document, the border controller is mycompany.call.sl.

Tunneling

The endpoint sends outbound UDP packets to its border controller, and receives replies from it. The outbound packets will be 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). This bi-directional flow of packets is called a tunnel. The tunnel can carry multiple data streams (of signaling and media) between the endpoint and border controller, but as far as the network is concerned, these streams are all just UDP payload. Some firewalls will 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 fail-over mechanism, but sending real-time media packets over TCP can result in a lower-quality user experience. If this connection type also fails, the StarLeaf endpoint will display an error message indicating that it cannot connect. In this case, there are two troubleshooting steps:

  1. Ensure that the conditions in this article: Firewall configuration for StarLeaf endpoints are met.
  2. Ask an affected StarLeaf Breeze user to run problem_report.exe, available from https://dl.starleaf.com/problem_report.exe . This will upload debugging information to StarLeaf’s development server and allow the StarLeaf technical support team to identify the cause of the failed connection.

The StarLeaf Cloud and the endpoint are now able to communicate with each other, exchanging all the types of registration, directory, signaling and media traffic that are required for a successful StarLeaf user experience.