WebRTC and Selective Forwarding Unit
xAssist can be configured to use WebRTC as the communication protocol to enable real-time communication over peer-to-peer connections. WebRTC is a rather complex domain and uses the Real-time Transport Protocol to transmit audio and video. Please ensure that your network infrastructure does not block WebRTC communications and allows outbound traffic with return traffic in response.
For the best user experience, we recommend using the latest Google Chrome or Microsoft Edge (Chromium-based) browser. Please ensure that the web browser can access the computer's webcam, microphone, and speakers, otherwise, xAssist will not work properly.
Group policies
In Microsoft Active Directory environments, group policies can deny access to the computer's webcam and microphone. Please ensure that you have access to your webcam.
- Google.Policies.Chrome::VideoCaptureAllowed
- Google.Policies.Chrome::AudioCaptureAllowed
Required bandwidth
xAssist continuously adapts to the available bandwidth. If the available bandwidth is low, the streaming quality is automatically reduced. This applies primarily to video quality, but even if the video feed is interrupted, the audio should still be able to be transmitted.
Overall, xAssist depends on a variety of different factors to determine how much bandwidth is required to use xAssist. In general, the following bandwidth requirements apply:
Latency
Latency is also an important factor when using xAssist.
Note: Low latency is better than high latency.
General information
UDP is preferred over TCP
UDP is preferred over TCP because it reduces the packet transfer latency caused by the differences between the two protocols.
Proxies and package inspection
No browser supports UDP over proxies, which means the data must bypass the proxy if you want to use UDP. Packet inspection comes at the cost of higher latency. Often the latency when using packet inspection is so high that it prevents video calls from being established.
WebRTC terms
STUN server
A STUN server does a very simple job, it tells the client what its real public IP address and port is behind a Network Address Translation (NAT) service. By using a STUN server, we can infer whether the client is accepting peer-to-peer connections from other clients on the Internet.
TURN server
A TURN server provides a fallback solution for clients that cannot establish a peer-to-peer connection, acting as a media server proxy between the two peers.
Signaling
Signaling is used to initiate the video and audio streams between clients. In xAssist, signaling is done via the Frontline Command Center for normal calls and via the Selective Forwarding Unit for conference calls.
Interactive Connectivity Establishment (ICE)
WebRTC uses ICE to try to find the best way for the clients (web and smart glasses) to communicate with each other in a call: Peer-to-peer, peer-to-peer with Network Address Translation (NAT) between the clients (using a STUN server), or relayed using a TURN server.
For normal calls (not conferences), the first option for the clients (Smart Glass and Expert via Web UI) is a direct peer-to-peer connection. This option is called HOST.
The next option is to establish a peer-to-peer connection with Network Address Translation (NAT) between the clients. This option is called REFLEXIVE. This means that the STUN server will try to find a public IP and port for the clients that will allow peer-to-peer communication between their different local networks.
The last option is to use a TURN server that would relay the video and audio streams. This option is called RELAYED.
If the HOST or REFLEXIVE option is available, then the video and audio streams are peer-to-peer (with end-to-end encryption in place) and there should have been very limited communication with the STUN/TURN server to gather the various candidates for the three options.
If neither of the first two options are available (due to symmetric NAT, firewall, or other issues), the clients will use RELAYED communication via the TURN server (still with end-to-end encryption in place).
Selective Forwarding Unit (SFU)
In the case of a conference call, each client communicates with the SFU instead of the other clients. The SFU then sends the streams to all the other clients on the call. As with a normal 1-to-1 call, the communication option to the SFU will be HOST, REFLEXIVE, or RELAYED, and the video and audio streams between each client and the SFU will be end-to-end encrypted. This means that the SFU will decrypt the incoming streams and send new encrypted streams to the clients. Therefore, the encryption between the clients is not end-to-end, but hop-by-hop.
Firewall configuration for xAssist clients
For the rules mentioned, your NAT should allow the Clients (Smart Glasses and Experts via Web UI) to have outgoing traffic with returning traffic in response if your NAT is configured to do endpoint-independent mapping and preferably address-dependent filtering or endpoint-independent filtering.
If not all the rules mentioned in the following sections can be implemented (e.g. due to IT policies), WebRTC will automatically choose the best possible option as described in the Interactive Connectivity Establishment (ICE) section.
| Host/IP | Type | Protocol | Port | TCP/UDP |
|-----------------------------------|--------------------|-------------|------|---------|
| frontlineworker.com/[your domain] | Application Server | HTTPS/WSS | 443 | TCP |
Host-to-host communication
Inbound and outbound UDP traffic must be allowed. The port ranges can be configured via Group Policy for the web browser.
| Purpose | Destination IP | Protocol | Port(s) |
|------------------------|--------------------|----------|---------------|
| WebRTC Peer Connection | remote peer's IP | UDP | 1025 to 65535 |
Frontline STUN and TURN server
TeamViewer provides a global network of distributed STUN/TURN servers, including a load balancing mechanism that automatically assigns xAssist users to the optimal STUN/TURN server for their region.
|Region| IP Range |Purpose| Destination IP |Protocol| Port(s) |
|------|------------------|-------|-----------------------------------------|--------|------------------|
|GLOBAL| * | TURN | turn.svc.frontlineworker.com | TCP |8080 |
|GLOBAL| * | STUN | turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|EU | 20.54.230.192/29 | TURN | eu-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|EU | 20.54.230.192/29 | STUN | eu-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|US | 20.84.226.80/29 | TURN | us-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|US | 20.84.226.80/29 | STUN | us-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|SA | 20.201.68.120/29 | TURN | sa-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|SA | 20.201.68.120/29 | STUN | sa-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|JP | 20.210.56.40/29 | TURN | jp-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|JP | 20.210.56.40/29 | STUN | jp-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|IN | 52.140.81.48/29 | TURN | in-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|IN | 52.140.81.48/29 | STUN | in-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
*Depending on region/DNS resolving one of the below
Note: HTTPS/TCP 443 access to webrtc.svc.frontlineworker.com is also required to obtain TURN server credentials.
Frontline Conferencing servers (SFU)
TeamViewer provides a global network of distributed SFUs, including a load balancing mechanism that automatically assigns the optimal SFU to xAssist users based on their region.
To enable conference calls, webrtc.svc.frontlineworker.com must be reachable via HTTPS / TCP 443 for signaling purposes.
|Region| IP Range | Host | Type |Protocol | Port(s) |TCP/UDP|
|------|----------------|--------------------------------------|---------------------------------|---------|-----------|-------|
|GLOBAL|* |webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|EU |20.54.230.192/29|eu-webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|EU |20.54.230.192/29|eu-{0..10}.sfu.svc.frontlineworker.com|Multicall Gateway Video/Audio/RTP| RTP |40000-45000| UDP |
|US |20.84.226.80/29 |us-webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|US |20.84.226.80/29 |us-{0..10}.sfu.svc.frontlineworker.com|Multicall Gateway Video/Audio/RTP| RTP |40000-45000| UDP |
|SA |20.201.68.120/29|sa-webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|SA |20.201.68.120/29|sa-{0..10}.sfu.svc.frontlineworker.com|Multicall Gateway Video/Audio/RTP| RTP |40000-45000| UDP |
|JP |20.210.56.40/29 |jp-webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|JP |20.210.56.40/29 |jp-{0..10}.sfu.svc.frontlineworker.com|Multicall Gateway Video/Audio/RTP| RTP |40000-45000| UDP |
|IN |52.140.81.48/29 |in-webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|IN |52.140.81.48/29 |in-{0..10}.sfu.svc.frontlineworker.com|Multicall Gateway Video/Audio/RTP| RTP |40000-45000| UDP |
*Depending on region/DNS resolving one of the below
Note: HTTPS/TCP 443 access to webrtc.svc.frontlineworker.com is also required to authenticate against the SFUs.
xAssist security information
xAssist peer-to-peer (1 to 1 call)
The underlying WebRTC framework forces DTLS and SRTP on all connections, meaning that video and audio are encrypted end-to-end.
Even with Turn, packets are only decrypted by the recipient, never by the Turn server.
xAssist conferences
Forced end-to-end encryption using DTLS/SRTP from peer to SFU. SFU decrypts and re-encrypts the media to send it to the recipient. No peer's media is ever stored in persistent storage.
The cipher suite used is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
External sources
- https://webrtc-security.github.io/
- https://github.com/versatica/mediasoup
