This section illustrates various different point-to-point calling scenarios.

Point-to-point calls within a StarLeaf organization

In this scenario, a StarLeaf endpoint calls another StarLeaf endpoint in the same organization and on the same network. An IP route exists between the local IP addresses of the endpoints.

The figure below shows point-to-point calls within a StarLeaf organization (“Private Direct Media”)

  1. Endpoint A sends a setup request to the call control engine within the StarLeaf Cloud, supplying the extension number or email address of the far end.
  2. The call controller identifies the relevant destination endpoint to be called, and signals it to ring. If the far-end user has multiple endpoints registered in their name (for example, a StarLeaf Personal Telepresence endpoint and a Breeze client) all of the endpoints ring.
  3. While ringing, the endpoints at both ends work out the most efficient way to route media between themselves. In this scenario, a direct IP route exists. When the far end picks up, signaling is sent back to the calling endpoint via the border controller. The call is now connected.
  4. Media is sent directly between the two endpoints (not via the border controller), using the route established in Step 3. The direct route avoids unnecessary usage of the organization’s Internet connection. The signaling traffic represents only a tiny amount of data, by comparison. We call this method “Private Direct Media”.

For more information on Private Direct Media requirements, refer to Requirements for direct media between StarLeaf endpoints.

Point-to-point calls between different locations in a StarLeaf organization

In this scenario, the company has a StarLeaf organization with endpoints distributed between different sites that have separate Internet connections. There is no company WAN, so there is no direct IP route between the private IP addresses of the endpoints.

The figure below shows point-to-point calls within a StarLeaf organization (“Public Direct Media”)

  1. The endpoints establish that no direct route exists between them. They perform an Interactive Connectivity Establishment (ICE)-like probing process to see if they are able to route media direct between their NAT addresses.
    This attempt is likely to be successful if the two NAT gateways do not implement symmetric NAT—this is most likely to be the case if at least one of them is a domestic router (as opposed to two enterprise-class firewalls). Symmetric NAT imposes tight restrictions on which external host address/port combinations are able to route packets into the firewall. Your firewall might give you the flexibility to configure this behavior.
  2. If the endpoints are able to route media into each other’s NAT pinholes, the media path shown by the blue line in the diagram above is used. This gives the shortest, lowest-latency media path possible between the two endpoints and reduces load on the StarLeaf Cloud service. We call this “Public Direct Media”.
  3. If Public Direct Media is not possible, the media is backhauled to the StarLeaf Border controller, as shown in the diagram below.

The figure below shows point-to-point calls in the same organization (media via border controller).

The advantage of the “media via border controller” method is that it uses the already-established tunnel routes between the company’s firewalls and the StarLeaf border controller, so it is certain to work. The disadvantage is that this might not be the most direct route for the traffic.

For more information on Public Direct Media requirements, refer to Requirements for direct media between StarLeaf endpoints.