HPR Deployment Considerations and Options – Parsec

This page goes into detail on the various considerations for deployment, and the options that you can use for the HPR Server.

Deployment considerations

Multiple HPR Servers

Parsec allows for multiple HPR servers to be added to a single Teams account. Multiple HPR servers can be specified for the entire account or per group through adding the LAN IP or DNS addresses and ports separated by a comma (format HOST:PORT,HOST:PORT) in the Teams admin portal. If you want specific people or hosts to go through certain HPR servers only, you can specify HPR servers in an App Rule, then assign the App Rule to the person or host.

If multiple HPR servers are available, hosts will automatically select the one with the lowest latency. If no HPR server is contactable, hosts will fall back to the public STUN server unless app_force_relay is set. If you never want hosts to fall back to the public STUN server, you can prevent that behavior by setting app_force_relay in the hosts' config files.

For high availability- it is recommended to have more than one HPR server specified for each computer as there may be times when one HPR server needs to go offline (e.g. update windows). Having a second HPR server available to handle connections would prevent disruptions to users in these instances.

When adding a second HPR server, you'll need to plan your deployment to avoid NAT conflicts. If each HPR server gets a unique public IP, it doesn't matter if you use the same ports for each one. However, if both HPR servers are behind a single public IP, you will need to use a different public port to avoid conflicts.

DNS support

It is possible to use DNS records to configure HPR candidates for Parsec hosts. The DNS value can be configured in multiple locations, such as the following:

Admin panel (High Performance Relay server host address)

Windows Registry

Parsec configuration file

Multiple HPR candidates

Parsec hosts wills end a UDP ping to each relay candidate and select the lowest latency candidate. This is helpful if there are multiple HPR servers configured in different geographic locations, enabling the hosts to pick the closest relay.

Fallback to public STUN

If Parsec host is not configured with an app_force_relay setting in the configuration file, the host will fall back to using Parsec's public STUN server for connection negotiation if the local relay server(s) are unreachable. This helps in scenarios where machines are moved between locations that have relays and locations that do not have relays. For example, a host that was on a corporate network, but was subsequently moved to a home network.

Clients local to HPR servers

In most cases, the relay server is within the DMZ of the host computer location (typically the corporate office) and each host is configured to use HPR to negotiate an inbound client session. However, there may be cases where someone at their office computer needs to connect to their workstation at home – the opposite direction. To continue leveraging HPR for reliability purposes, the client needs to tell the host where the static NAT is.

When the relay server is local to the client, its address can be specified through the Client High Performance Relay Server Address setting in the Teams App Rules page:

HPR settings - client.png

The relay server address can also be specified in the client's configuration file via app_client_stun_address:

app_client_stun_address = IP@PORT,IP@PORT

Setting both the Host and Client High Performance Relay Server Addresses as equal should not cause connection issues as long as connections are not being forced through the relay. In cases where you are setting the Client High Performance Relay Server Address or app_client_stun_address settings, it is recommended to make sure that app_force_relay is not set in the configuration file.

Advanced connectivity scenarios

A user and a host each have an App Rule assigned with different HPR servers specified within the admin portal. When the user attempts to connect to the host, the HPR server specified for host will be used. The host machine will always use the config of the App Rule over the App Rule assigned to the user - in this case, the host isn't even aware that the user making the connection is assigned an App Rule with a different HPR server specified.

Force client connections through relay server

Parsec's default connection negotiation behavior can result in a successful P2P connection without using the relay if the host peer has outbound UDP connectivity to the internet and the client peer's router/firewall supports UPnP or UDP hole punching. If you'd like to disable this behavior and force all P2P traffic over the relay, you can add the following line to your host peer's config file or registry and restart Parsec:

app_force_relay = 1

If you'd like to force all traffic from the internet (WAN) to use the relay, but still allow the host to accept "direct" LAN connections, you can add the following line to your host peer's config file or registry and restart Parsec:

app_force_relay = 2

Please note that this should only be set in the host's config file and not on the client machine.