Ensuring that external clients can communicate with a TURN Server
Generally, external clients connect directly to the IBM Sametime® TURN Server after the load balancer has provided the appropriate address to the client. Sometimes, the external client cannot connect directly; for example, when it is hosted behind a firewall or a network address translator. If you know that your external clients cannot connect directly to a TURN Server, you can configure a redirect address that allows the client to repeatedly connect to the TURN Server through the load balancer.
Configuring the TURN Server cluster for direct client connections
When external clients can connect directly to the TURN Servers in the cluster, you should configure two IP addresses for each TURN Server, as shown in Table 1. Both of the IP addresses are hosted on the TURN Server itself.
TURN1 | TURN2 |
---|---|
turn.loopback.hostname.ipv4=10.0.0.1 |
turn.loopback.hostname.ipv4=10.0.0.3 |
turn.local.hostname.ipv4=10.0.0.2 |
turn.local.hostname.ipv4=10.0.0.4 |
When an external client connects to the load balancer and
requests the address of a TURN Server, the load balancer responds
by returning the turn.loopback.hostname.ipv4
address
of one of the TURN Servers in the cluster. The client then connects
to the designated TURN Server using the loopback address. The TURN
Server responds to the client by returning its own turn.local.hostname.ipv4
address;
for the remainder of the session, the client connects directly to
the same TURN Server using the local host address.
For example, suppose that you deploy a cluster of two TURN Servers (called TURN1 and TURN2) with a load balancer as shown in the following graphic. Clients are configured to connect to the load balancer using the IP address 9.1.2.3. The load balancer is configured to balance traffic by providing clients with the loopback address of one of the TURN Servers in the cluster. In this example, the client sends a request to the load balancer, which responds by directing the client to IP address 10.0.0.1 (the loopback address for TURN1). The client then sends a request to 10.0.0.1, and TURN1 responds by providing its local host address (10.0.0.2) so that the client can connect directly. During the remainder of the session, the client sends all requests directly to TURN1 on 10.0.0.2.
The following list describes the numbered connections in the graphic to explain the process of connecting the external client directly to the TURN Server:
- Client sends request to load balancer on 9.1.2.3
- Load balancer responds by sending loopback address of TURN1 (10.0.0.1)
- Client send request to TURN1 on 10.0.0.1 (loopback address)
- TURN1 responds by sending its local address (10.0.0.3)
- Client sends subsequent requests directly to TURN1 on 10.0.0.3
Configuring the TURN Server cluster for redirected client connections
Sometimes, the external client is located behind a firewall or NAT and cannot connect directly to the TURN Servers in the cluster. In this situation, each TURN Server needs a redirect address in addition to the loopback and local addresses.
When external clients cannot connect directly to the TURN Servers in the cluster, you should configure three IP addresses for each TURN Server, as shown in Table 2. The local and loopback addresses are hosted on the TURN Server, but the redirect address is hosted on the load balancer as a secondary address.
TURN1 | TURN2 |
---|---|
turn.loopback.hostname.ipv4=10.0.0.1 |
turn.loopback.hostname.ipv4=10.0.0.3 |
turn.local.hostname.ipv4=10.0.0.2 |
turn.local.hostname.ipv4=10.0.0.4 |
turn.redirect.hostname.ipv4=9.1.2.4 |
turn.redirect.hostname.ipv4=9.1.2.5 |
When an external client connects to the load balancer and
requests the address of a TURN Server, the load balancer responds
by returning the turn.loopback.hostname.ipv4
address
of one of the TURN Servers in the cluster. The client then connects
to the designated TURN Server using the loopback address. Because
the turn.redirect.hostname.ipv4
address was configured
for the TURN Server, it responds to the client by providing that address
instead of its own local host address. For the remainder of the session,
the client sends every request to the redirect address hosted on the
load balancer (instead of directly to the TURN Server), and the load
balancer redirects each request to the same TURN Server to maintain
session affinity.
For example, suppose that you deploy a cluster of two TURN Servers (called TURN1 and TURN2) with a load balancer as shown in the following graphic. Clients are configured to connect to the load balancer using the IP address 9.1.2.3. The load balancer is configured to balance traffic by providing clients with the loopback address of one of the TURN Servers in the cluster. In this example, the client sends a request to the load balancer, which responds by directing the client to IP address 10.0.0.1 (the loopback address for TURN1). The client then sends a request to 10.0.0.1, and TURN1 responds by providing its redirect address (9.1.2.4) instead of its local host address. The redirect address is actually hosted on the load balancer. For the remainder of the session, the client sends requests to that redirect address and the load balancer routes the request to TURN1. The client must connect to the load balancer repeatedly during the session because it cannot connect directly to the TURN Server; however, all requests from a particular client are routed to the same TURN Server during each session.
The following list describes the numbered connections in the graphic to explain the process of redirecting the external client from the load balancer to the TURN Server:
- Client sends request to load balancer on 9.1.2.3
- Load balancer responds by sending loopback address of TURN1 (10.0.0.1)
- Client send request to TURN1 on 10.0.0.1 (loopback address)
- TURN1 responds by sending its redirect address (9.1.2.4=load balancer's secondary address)
- Client sends subsequent request to load balancer 9.1.2.4
- Load balancer routes request to TURN1 on 10.0.0.1 (loopback address)