Requirements

Server certificates and host names

If you set up the management server with encryption, you must also set up all API Gateway instances that connect to the management server with encryption. To enable this, the IIS on the host that you install the API Gateway on must be set up with a server certificate.

The server hostname you specify during installation of the API Gateway is used to connect the API Gateway to the identity provider service (IDP) and management server in the XProtect VMS, and should match a DNS name in the management server certificate.

XProtect users

The API Gateway installer must be able to log in to the XProtect VMS during the installation. The Windows user account that you used for installing the XProtect VMS has been added in the XProtect VMS to the Administrators role. You can use the same Windows account when you install the API Gateway.

To authenticate and access the API Gateway, you can use either an XProtect Basic user account or an XProtect Windows (AD) account.

Not all software environments supports Kerberos or NTLM authentication, but you can always use an XProtect Basic user account.

• You can create XProtect Basic users and XProtect Windows users during installation of the XProtect VMS.

• After installation, you can use the XProtect Management Client to create XProtect Basic or Windows users.

For more information about XProtect Basic users, go to XProtect VMS administrator manual/Create basic user2 https://doc.milestonesys.com/latest/en-US/standard_features/sf_mc/sf_mcnodes/sf_6security/mc_createbasicusers.htm.

For more information about assigning users to roles, go to XProtect VMS administrator manual/Assign/remove users and groups to/from roles3 https://doc.milestonesys.com/latest/en-US/standard_features/sf_mc/sf_mcnodes/sf_6security/mc_assignremoveusersandgroupstofromroles.htm.

WebRTC

WebRTC connection through a symmetric NAT firewall

WebRTC cannot create a connection through a symmetric NAT firewall without using a TURN (Traversal Using Relays around NAT) server.

Check with your system administrator if you are behind a symmetric NAT firewall, or run the test described here: Am I behind a Symmetric NAT?4 https://webrtchacks.com/symmetric-nat/.

To set up a TURN server, please refer to STUN and TURN server addresses.

WebRTC connection on a local network uses mDNS

To prevent private IP addresses from leaking from a local network when running WebRTC applications, modern browsers by default send mDNS (multicast DNS) addresses as ICE Candidates to the signaling server.

API Gateway support for mDNS

The signaling server running in the API Gateway supports resolving mDNS addresses when running on a Windows version with native support for mDNS.

Native support for mDNS was introduced in Windows version 1809 (October 2018) or later, and is available in any recently updated Windows Server 2019 or Windows 10 installations, and all Windows Server 2022 and Windows 11 installations.

WebRTC connections across routers in a local network

mDNS relies on multicast which by default will not pass through routers. This means that in enterprise environments, mDNS will fail in many cases:

• mDNS over wired Ethernet works on the same local network segment, but in more complex network solution (most enterprise environments), mDNS will fail.

• mDNS over WiFi will only work on simple network configurations (as for wired networks). In configurations with WiFi extender or Mesh networks, mDNS will likely fail.

The signaling server running in the API Gateway supports a workaround for connections across routers on a local network. The signaling server will attempt to get the client's local IP network address from X-Forwarded-For and Remote_Addr headers in the HTTP request and use that to add an ICE Candidate with higher priority than the ICE Candidate with the mDNS address. This will not work in all cases; on some networks, X-Forwarded-For is removed and Remote_Addr will not contain the local IP address of client.