WebRTC and Selective Forwarding Unit
xAssist kann so konfiguriert werden, dass es WebRTC als Kommunikationsprotokoll verwendet, um Echtzeitkommunikation über Peer-to-Peer-Verbindungen zu ermöglichen. WebRTC ist eine recht komplexe Domäne 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 zurückkehrendem Datenverkehr 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 auf Ihre Webcam zugreifen können.
- Google.Policies.Chrome::VideoCaptureAllowed
- Google.Policies.Chrome::AudioCaptureAllowed
Erforderliche Bandbreite
xAssist passt sich kontinuierlich an die verfügbare Bandbreite an. Wenn nur eine geringe Bandbreite zur Verfügung steht, wird die Streaming-Qualität automatisch reduziert. Dies gilt in erster Linie für die Videoqualität. Selbst wenn die Videoübertragung ausfällt, sollte die Audioübertragung noch möglich sein.
Alles in allem hängt es von einer Vielzahl unterschiedlicher Faktoren ab, wie viel Bandbreite für die Nutzung von xAssist benötigt wird. Im Allgemeinen gilt die folgende Bandbreitennutzung:
Latenzzeit
Auch die Latenzzeit ist ein wichtiger Faktor bei der Verwendung von xAssist. Eine niedrige Latenz ist besser als eine hohe Latenz.
Allgemeine Informationen
UDP wird gegenüber TCP bevorzugt
UDP wird gegenüber TCP bevorzugt, da es die Latenzzeit der Paketübertragung verringert, die durch die Unterschiede zwischen den beiden Protokollen verursacht wird.
Bevollmächtigte und Paketinspektion
Kein Browser unterstützt UDP mit Proxies, was bedeutet, dass die Daten den Proxy umgehen müssen, wenn Sie UDP verwenden wollen. Die Paketinspektion hat den Preis einer höheren Latenzzeit. Oft ist die Latenz bei der Verwendung der Paketprüfung 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 seine tatsächliche öffentliche IP-Adresse und den Port hinter einem NAT-Dienst (Network Address Translation) mit. Mithilfe eines STUN-Servers können wir feststellen, ob der Client Peer-to-Peer-Verbindungen von anderen Clients im Internet akzeptiert.
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 für die Einleitung der Video- und Audioströme zwischen den Clients verwendet. In xAssist erfolgt die Signalisierung für normale Anrufe über das Frontline Command Center und im Falle eines Konferenzgesprächs über die Selective Forwarding Unit.
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), die zwischen den Clients stattfindet (mit Hilfe eines STUN-Servers), oder vermittelt mit Hilfe eines TURN-Servers.
Bei normalen Anrufen (keine Konferenz) besteht die erste Option der Clients (Smart Glass und Expert via Web-UI) in einer direkten 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. Daher versucht der STUN-Server, die öffentliche IP-Adresse und den Port der Clients zu finden, die eine Peer-to-Peer-Kommunikation zwischen ihren verschiedenen lokalen Netzwerken 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, sind die Video- und Audioströme Peer-to-Peer (mit End-to-End-Verschlüsselung) und es sollte nur eine sehr begrenzte Kommunikation mit dem STUN/TURN-Server stattfinden, 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 RELAYED-Kommunikation über den TURN-Server (immer noch mit End-to-End-Verschlüsselung).
Selektive Weiterleitungseinheit (SFU)
Im Falle einer Telefonkonferenz kommuniziert jeder Client mit der SFU anstelle der anderen Clients. Die SFU sendet dann die Streams an alle anderen Clients, die an dem Konferenzgespräch teilnehmen. Wie bei einem normalen 1-zu-1-Anruf ist die Kommunikationsoption zur SFU HOST, REFLEXIVE oder RELAYED, und die Video- und Audioströme werden zwischen jedem Client und der SFU 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. Daher ist die Verschlüsselung zwischen den Clients nicht Ende-zu-Ende, sondern Hop-by-Hop verschlüsselt.
Firewall-Konfiguration für xAssist-Clients
Für die erwähnten Regeln sollte Ihr NAT den Clients (Smart Glasses und Experten über die Web-UI) ausgehenden Datenverkehr mit zurückkehrendem Datenverkehr als Antwort erlauben, wobei Ihr NAT so konfiguriert sein sollte, dass es eine endpunktunabhängige Zuordnung vornimmt, und vorzugsweise eine adressabhängige Filterung oder eine endpunktunabhängige Filterung.
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.
Kommunikation mit der Kommandozentrale Frontline
Host zu Host Kommunikation
Eingehender und ausgehender UDP-Verkehr muss erlaubt sein. Die Portbereiche können über Gruppenrichtlinien für den Webbrowser konfiguriert werden.
Frontline STUN- und TURN-Server
TeamViewer (Classic) bietet ein globales Netzwerk von verteilten STUN/TURN-Servern, einschließlich eines Lastausgleichsmechanismus, der xAssist-Nutzern automatisch den optimalen STUN/TURN-Server auf der Grundlage der Region zuweist.
*Abhängig von der Region/DNS-Auflösung einer der folgenden Punkte
Um TURN-Server-Anmeldeinformationen zu erhalten, ist auch ein HTTPS/TCP 443-Zugang zu webrtc.svc.frontlineworker.com erforderlich.
Frontline Server für Konferenzen (SFU)
TeamViewer (Classic) bietet ein globales Netzwerk verteilter SFUs mit einem Lastausgleichsmechanismus, der xAssist-Nutzern automatisch die optimale SFU auf der Grundlage der Region zuweist.
Um Telefonkonferenzen zu ermöglichen, muss webrtc.svc.frontlineworker.com zu Signalisierungszwecken über HTTPS / TCP 443 erreichbar sein.
*Abhängig von der Region/DNS-Auflösung einer der folgenden Punkte
Zur Authentifizierung gegenüber den SFUs ist auch ein HTTPS/TCP 443-Zugang zu webrtc.svc.frontlineworker.com erforderlich.
xAssist Sicherheitsinformationen
xAssist Peer-to-Peer (1 zu 1 Anruf)
Das zugrunde liegende Framework WebRTC erzwingt DTLS und SRTP für alle Verbindungen, d. h. Video und Audio werden Ende-zu-Ende verschlüsselt.
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 vom Peer zur SFU. Die SFU entschlüsselt die Medien und verschlüsselt sie erneut, um sie an den Empfänger zu senden. Kein Medium eines Peers wird jemals in einem persistenten Speicher abgelegt.
Es wird die Cipher Suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 verwendet.
Externe Quellen
- https://webrtc-security.github.io/
- https://github.com/versatica/mediasoup
