WebRTC und selektive Weiterleitungseinheit
xAssist kann so konfiguriert werden, dass es WebRTC als Kommunikationsprotokoll verwendet, um Echtzeitkommunikation über Peer-to-Peer-Verbindungen zu ermöglichen. WebRTC ist ein komplexer Standard und verwendet das Real-time Transport Protocol zur Übertragung von Audio und Video. Bitte stellen Sie sicher, dass Ihre Netzwerkinfrastruktur die WebRTC-Kommunikation nicht blockiert und ausgehenden Datenverkehr mit Rückverkehr als Antwort zulässt.
Für ein optimales Benutzererlebnis empfehlen wir die Verwendung des neuesten Google Chrome oder Microsoft Edge Browsers (Chromium-basiert). Bitte stellen Sie sicher, dass der Webbrowser auf die Webcam, das Mikrofon und die Lautsprecher des Computers zugreifen kann, da xAssist sonst nicht richtig funktioniert.
Gruppenrichtlinien
In Microsoft Active-Directory-Umgebungen können Gruppenrichtlinien den Zugriff auf die Webcam und das Mikrofon des Computers verweigern. Bitte stellen Sie sicher, dass Sie Zugriff auf Ihre Webcam haben.
- Google.Policies.Chrome::VideoCaptureAllowed
- Google.Policies.Chrome::AudioCaptureAllowed
Erforderliche Bandbreite
xAssist passt sich kontinuierlich an die verfügbare Bandbreite an. Ist die verfügbare Bandbreite gering, wird die Streaming-Qualität automatisch reduziert. Dies gilt in erster Linie für die Videoqualität, aber auch bei einer Unterbrechung der Videoübertragung sollte der Ton noch übertragen werden können.
Insgesamt hängt es von verschiedenen Faktoren ab, wie viel Bandbreite für die Nutzung von xAssist erforderlich ist. Im Allgemeinen gelten die folgenden Anforderungen:
Latenzzeit
Auch die Latenzzeit ist ein wichtiger Faktor bei der Verwendung von xAssist.
Hinweis: Eine geringe Latenzzeit ist besser als eine hohe Latenzzeit.
Allgemeine Informationen
UDP wird gegenüber TCP bevorzugt
UDP wird gegenüber TCP bevorzugt, weil es die durch die Unterschiede zwischen den beiden Protokollen bedingte Latenz bei der Paketübertragung verringert.
Bevollmächtigte und Paketprüfung
Kein Browser unterstützt UDP über Proxys, d. h. die Daten müssen den Proxy umgehen, wenn Sie UDP verwenden wollen. Die Paketprüfung geht mit einer höheren Latenz einher. Oft ist die Latenz bei der Verwendung von Paketinspektion so hoch, dass sie den Aufbau von Videoanrufen verhindert.
WebRTC-Begriffe
STUN-Server
Ein STUN-Server erfüllt eine sehr einfache Aufgabe: Er teilt dem Client mit, wie seine tatsächliche öffentliche IP-Adresse und sein Port hinter einem NAT-Dienst (Network Address Translation) lauten. Mit Hilfe eines STUN-Servers können wir feststellen, ob der Client Peer-to-Peer-Verbindungen von anderen Clients im Internet annimmt.
TURN-Server
Ein TURN-Server bietet eine Fallback-Lösung für Clients, die keine Peer-to-Peer-Verbindung aufbauen können, und fungiert als Medienserver-Proxy zwischen den beiden Peers.
Signalisierung
Die Signalisierung wird verwendet, um die Video- und Audioströme zwischen den Clients zu initiieren. In xAssist erfolgt die Signalisierung über das Frontline Command Center für normale Anrufe und über die Selective Forwarding Unit für Konferenzgespräche.
Interaktive Konnektivitätseinrichtung (ICE)
WebRTC verwendet ICE, um den besten Weg zu finden, wie die Clients (Web und Smart Glasses) in einem Anruf miteinander kommunizieren können: Peer-to-Peer, Peer-to-Peer mit Network Address Translation (NAT) zwischen den Clients (unter Verwendung eines STUN-Servers) oder vermittelt unter Verwendung eines TURN-Servers.
Für normale Anrufe (keine Konferenzen) ist die erste Option für die Clients (Smart Glass und Expert via Web UI) eine direkte Peer-to-Peer-Verbindung. Diese Option wird HOST genannt.
Die nächste Möglichkeit besteht darin, eine Peer-to-Peer-Verbindung mit Network Address Translation (NAT) zwischen den Clients herzustellen. Diese Option wird REFLEXIVE genannt. Das bedeutet, dass der STUN-Server versucht, eine öffentliche IP-Adresse und einen Port für die Clients zu finden, die eine Peer-to-Peer-Kommunikation zwischen ihren verschiedenen lokalen Netzen ermöglichen.
Die letzte Option ist die Verwendung eines TURN-Servers, der die Video- und Audioströme weiterleitet. Diese Option wird RELAYED genannt.
Wenn die Option HOST oder REFLEXIVE verfügbar ist, dann sind die Video- und Audioströme Peer-to-Peer (mit Ende-zu-Ende-Verschlüsselung) und es sollte nur eine sehr begrenzte Kommunikation mit dem STUN/TURN-Server stattgefunden haben, um die verschiedenen Kandidaten für die drei Optionen zu sammeln.
Wenn keine der ersten beiden Optionen verfügbar ist (aufgrund von symmetrischem NAT, Firewall oder anderen Problemen), verwenden die Clients die RELAYED-Kommunikation über den TURN-Server (immer noch mit End-to-End-Verschlüsselung).
Selektive Weiterleitungseinheit (SFU)
Bei einer Telefonkonferenz kommuniziert jeder Client mit der SFU und nicht mit den anderen Clients. Die SFU sendet dann die Streams an alle anderen Clients des Anrufs. Wie bei einem normalen 1-zu-1-Anruf ist die Kommunikationsoption für die SFU HOST, REFLEXIVE oder RELAYED, und die Video- und Audioströme zwischen jedem Client und der SFU werden Ende-zu-Ende verschlüsselt. Das bedeutet, dass die SFU die eingehenden Ströme entschlüsselt und neue verschlüsselte Ströme an die Clients sendet. Die Verschlüsselung zwischen den Clients erfolgt also nicht Ende-zu-Ende, sondern Hop-by-Hop.
Firewall-Konfiguration für xAssist-Clients
Für die genannten Regeln sollte Ihr NAT den Clients (Smart Glasses und Experten über die Web-UI) ausgehenden Verkehr mit zurückkehrendem Verkehr als Antwort erlauben, wenn Ihr NAT für endpunktunabhängiges Mapping und vorzugsweise adressabhängige Filterung oder endpunktunabhängige Filterung konfiguriert ist.
Wenn nicht alle in den folgenden Abschnitten genannten Regeln umgesetzt werden können (z. B. aufgrund von IT-Richtlinien), wählt WebRTC automatisch die bestmögliche Option, wie im Abschnitt Interaktiver Verbindungsaufbau (ICE) beschrieben.
| Host/IP | Type | Protocol | Port | TCP/UDP |
|-----------------------------------|--------------------|-------------|------|---------|
| frontlineworker.com/[your domain] | Application Server | HTTPS/WSS | 443 | TCP |
Host-zu-Host Kommunikation
Eingehender und ausgehender UDP-Verkehr muss erlaubt sein. Die Portbereiche können über Gruppenrichtlinien für den Webbrowser konfiguriert werden.
| Purpose | Destination IP | Protocol | Port(s) |
|------------------------|--------------------|----------|---------------|
| WebRTC Peer Connection | remote peer's IP | UDP | 1025 to 65535 |
Frontline STUN- und TURN-Server
TeamViewer bietet ein globales Netzwerk von verteilten STUN/TURN-Servern, einschließlich eines Lastausgleichsmechanismus, der xAssist-Nutzer automatisch dem optimalen STUN/TURN-Server für ihre Region zuweist.
|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 |
*Abhängig von der Region/DNS-Auflösung einer der folgenden Punkte
Hinweis: Der HTTPS/TCP 443-Zugang zu webrtc.svc.frontlineworker.com ist auch erforderlich, um die Anmeldedaten für den TURN-Server zu erhalten.
Frontline Server für Konferenzen (SFU)
TeamViewer bietet ein globales Netzwerk verteilter SFUs, einschließlich eines Lastausgleichsmechanismus, der den xAssist-Benutzern automatisch die optimale SFU auf der Grundlage ihrer Region zuweist.
Um Telefonkonferenzen zu ermöglichen, muss webrtc.svc.frontlineworker.com zu Signalisierungszwecken über HTTPS / TCP 443 erreichbar sein.
|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 |
*Abhängig von der Region/DNS-Auflösung einer der folgenden Punkte
Hinweis: Der HTTPS/TCP 443-Zugang zu webrtc.svc.frontlineworker.com ist auch für die Authentifizierung gegenüber den SFUs erforderlich.
xAssist Sicherheitsinformationen
xAssist Peer-to-Peer (1 zu 1 Anruf)
Das zugrundeliegende WebRTC-Framework erzwingt DTLS und SRTP für alle Verbindungen, was bedeutet, dass Video und Audio Ende-zu-Ende verschlüsselt werden.
Auch bei Turn werden die Pakete nur vom Empfänger entschlüsselt, niemals vom Turn-Server.
xAssist-Konferenzen
Erzwungene Ende-zu-Ende-Verschlüsselung mit DTLS/SRTP von der Gegenstelle zur SFU. Die SFU entschlüsselt und verschlüsselt die Medien erneut, um sie an den Empfänger zu senden. Die Medien der Gegenstelle werden niemals in einem dauerhaften Speicher abgelegt.
Die verwendete Verschlüsselungssuite ist TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
Externe Quellen
- https://webrtc-security.github.io/
- https://github.com/versatica/mediasoup
