xAssist Requirements - TeamViewer Support
<main> <article class="userContent"> <p>WebRTC and Selective Forwarding Unit<br></p><p>xAssist can be configured to use WebRTC as a communication protocol to enable real-time communication over peer-to-peer connections. WebRTC is a rather complex domain and uses Real-time Transport Protocol to transfer audio and video. Please make sure that your network infrastructure does not block WebRTC communication and allows outgoing traffic with returning traffic in response.</p><p>For the best user experience, we recommend using the latest Google Chrome or Microsoft Edge (Chromium-based) browser. Please make sure that the web browser can access the computer's webcam, microphone, and speakers, or else xAssist will not work properly.</p><h4 data-id="group-policies">Group Policies</h4><p>In Microsoft Active Directory Environments Group Policies can deny access to the computer webcam and microphone. Please make sure that you are able to access your webcam.</p><ul><li>Google.Policies.Chrome::VideoCaptureAllowed</li><li>Google.Policies.Chrome::AudioCaptureAllowed</li></ul><h2 data-id="required-bandwidth">Required Bandwidth</h2><p>xAssist continuously adapts to the available bandwidth. If only low bandwidth is available then the streaming quality will automatically be reduced. This applies primarily to video quality, even if the video feed cuts out it should still be able to transfer audio.</p><p>All things considered, xAssist depends on a multitude of varying factors with how much bandwidth is required to use xAssist. In general, the following bandwidth usage applies:</p><div class="embedExternal embedImage display-large float-none"> <div class="embedExternal-content"> <a class="embedImage-link" href="https://us.v-cdn.net/6032394/uploads/CDR0ON5JZJLE/image.png" rel="nofollow noreferrer noopener ugc" target="_blank"> <img class="embedImage-img" src="https://us.v-cdn.net/6032394/uploads/CDR0ON5JZJLE/image.png" alt="image.png" height="192" width="1166" loading="lazy" data-display-size="large" data-float="none"></img></a> </div> </div> <h2 data-id="latency">Latency</h2><p>Latency is also an important factor while using xAssist. Lower latency is better than high latency.</p><div class="embedExternal embedImage display-large float-none"> <div class="embedExternal-content"> <a class="embedImage-link" href="https://us.v-cdn.net/6032394/uploads/GBFSRJNC3QGB/image.png" rel="nofollow noreferrer noopener ugc" target="_blank"> <img class="embedImage-img" src="https://us.v-cdn.net/6032394/uploads/GBFSRJNC3QGB/image.png" alt="image.png" height="261" width="1174" loading="lazy" data-display-size="large" data-float="none"></img></a> </div> </div> <h2 data-id="general-information">General Information</h2><h3 data-id="udp-is-preferred-over-tcp">UDP is preferred over TCP</h3><p>UDP is preferred over TCP because it will lower the latency of the package transmission that is caused by the differences between both protocols.</p><h3 data-id="proxies-and-package-inspection">Proxies and Package Inspection</h3><p>No browser supports UDP using Proxies which means that the data needs to bypass the proxy if you want to use UDP. Package Inspection comes with the cost of a higher Latency. Often the Latency is so high, while using package inspection, that it prevents video calls from being established.</p><h2 data-id="webrtc-terms">WebRTC Terms</h2><h3 data-id="stun-server">STUN Server</h3><p>A STUN server performs a very simple job, it tells the client what its actual public IP address and Port behind a Network Address Translation (NAT) service. Using a STUN server we can infer if the client accepts Peer to Peer connections from other clients on the Internet.</p><h3 data-id="turn-server">TURN Server</h3><p>A TURN server provides a fallback solution for clients that cannot establish a Peer to Peer connection and acts as a media server proxy between the two peers.</p><h3 data-id="signaling">Signaling</h3><p>Signaling is used for the initiation of the video and audio streams between the clients. In xAssist signaling for normal Calls is done via the Frontline Command Center and in case of a Conference Call via the Selective Forwarding Unit.</p><h3 data-id="interactive-connectivity-establishment-(ice)">Interactive Connectivity Establishment (ICE)</h3><p>WebRTC uses ICE to try and 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) taking place between the clients (with the help of a STUN server), or relayed with the help of a TURN Server.</p><p>In the case of normal calls (not conference), the clients' (Smart Glass and Expert via Web-UI) first option is to directly connect peer-to-peer. This option is called HOST.</p><p>The next option is to establish a peer-to-peer connection with Network Address Translation (NAT) taking place between the clients. This option is called REFLEXIVE. Therefore, the STUN Server will try to find public IP and port of the Clients that allows peer-to-peer communication between their different local Networks.</p><p>The last option is to use a TURN Server that would relay the video and audio streams. This option is called RELAYED.</p><p>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 only very limited communication with the STUN/TURN server should have taken place, to gather the different candidates for the three options.</p><p>If neither of the first two options is 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).</p><div class="embedExternal embedImage display-large float-none"> <div class="embedExternal-content"> <a class="embedImage-link" href="https://us.v-cdn.net/6032394/uploads/O4TA3WCGZBPL/xassistcall.png" rel="nofollow noreferrer noopener ugc" target="_blank"> <img class="embedImage-img" src="https://us.v-cdn.net/6032394/uploads/O4TA3WCGZBPL/xassistcall.png" alt="xAssistCall.png" height="844" width="1800" loading="lazy" data-display-size="large" data-float="none"></img></a> </div> </div> <h3 data-id="selective-forwarding-unit-(sfu)">Selective Forwarding Unit (SFU)</h3><p>In case of a conference call, each client communicates with the SFU instead of the other clients. The SFU then sends the streams to all other clients that take part in the conference 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 will be End-to-End encrypted between each client and the SFU. That means that the SFU will decrypt the incoming streams and send new encrypted streams to the clients. Therefore the encryption between the client is not end-to-end, rather hop-by-hop encrypted.</p><div class="embedExternal embedImage display-large float-none"> <div class="embedExternal-content"> <a class="embedImage-link" href="https://us.v-cdn.net/6032394/uploads/JJ22Y5XGIBFE/xassistconference.png" rel="nofollow noreferrer noopener ugc" target="_blank"> <img class="embedImage-img" src="https://us.v-cdn.net/6032394/uploads/JJ22Y5XGIBFE/xassistconference.png" alt="xAssistConference.png" height="844" width="1800" loading="lazy" data-display-size="large" data-float="none"></img></a> </div> </div> <h2 data-id="firewall-configuration-for-xassist-clients">Firewall Configuration for xAssist Clients</h2><p>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, having your NAT configured to do endpoint-independent mapping, and preferably address-dependent filtering or endpoint-independent filtering.</p><p>If not all rules mentioned in the below sections can get implemented (e.g. due to IT policies), then WebRTC will automatically choose the best possible option as described in the section ‘<strong>Interactive Connectivity Establishment (ICE)</strong>’.</p><h3 data-id="communication-with-frontline-command-center">Communication with Frontline Command Center</h3><pre class="code codeBlock" spellcheck="false" tabindex="0">| Host/IP | Type | Protocol | Port | TCP/UDP | |-----------------------------------|--------------------|-------------|------|---------| | frontlineworker.com/[your domain] | Application Server | HTTPS/WSS | 443 | TCP | </pre><h3 data-id="host-to-host-communication">Host to Host Communication</h3><p>Inbound and outbound UDP traffic must be allowed. The port ranges can be configured via group policies for the web browser.</p><pre class="code codeBlock" spellcheck="false" tabindex="0">| Purpose | Destination IP | Protocol | Port(s) | |------------------------|--------------------|----------|---------------| | WebRTC Peer Connection | remote peer's IP | UDP | 1025 to 65535 | </pre><h3 data-id="frontline-stun-and-turn-server">Frontline STUN and TURN Server</h3><p>TeamViewer provides a global network of distributed STUN/TURN servers including a load balancing mechanism which automatically assigns xAssist users the optimal STUN/TURN server based on the region.</p><pre class="code codeBlock" spellcheck="false" tabindex="0">|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 | </pre><p>*Depending on region/DNS resolving one of the below</p><p>To receive TURN server credentials, HTTPS/TCP 443 access to <a href="unsafe:webrtc.svc.frontlineworker.com" rel="nofollow noreferrer ugc">webrtc.svc.frontlineworker.com</a> is required as well.</p><h3 data-id="frontline-conferencing-servers-(sfu)">Frontline Conferencing Servers (SFU)</h3><p>TeamViewer provides a global network of distributed SFUs including a load balancing mechanism that automatically assigns xAssist users the optimal SFU based on the region.</p><p>To allow conference calls, webrtc.svc.frontlineworker.com needs to be reachable via HTTPS / TCP 443 for signaling purposes.</p><pre class="code codeBlock" spellcheck="false" tabindex="0">|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 | </pre><p>*Depending on region/DNS resolving one of the below</p><p>To authenticate against the SFUs HTTPS/TCP 443 access to <a href="unsafe:webrtc.svc.frontlineworker.com" rel="nofollow noreferrer ugc">webrtc.svc.frontlineworker.com</a> is required as well.</p><h2 data-id="xassist-security-information">xAssist Security Information</h2><h3 data-id="xassist-peer-to-peer-(1-to-1-call)">xAssist Peer-to-Peer (1 to 1 call)</h3><p>The underlaying framework WebRTC forces DTLS and SRTP on all connections, which means Video and Audio are End-to-End encrypted.</p><p>Even with turn, the packages are only decrypted by the receiver, never by the turn server.</p><h3 data-id="xassist-conferences">xAssist Conferences</h3><p>Forced End-to-End encryption using DTLS/SRTP from Peer to SFU. SFU decrypts the media and encrypts it again to send it to the receiver. No media of a peer is ever stored in persistent storage.</p><p>Cipher Suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 is used.</p><h4 data-id="external-sources">External Sources</h4><ol><li><a href="https://webrtc-security.github.io/" rel="nofollow noreferrer ugc">https://webrtc-security.github.io/</a></li><li><a href="https://github.com/versatica/mediasoup" rel="nofollow noreferrer ugc">https://github.com/versatica/mediasoup</a></li></ol><h2></h2><h4 data-id="-1"></h4> </article> </main>
