WebRTC und Selective Forwarding Unit
Assist kann so konfiguriert werden, dass WebRTC als Kommunikationsprotokoll verwendet wird, um die 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. Stellen Sie sicher, dass Ihre Netzwerkinfrastruktur die WebRTC-Kommunikation nicht blockiert und ausgehenden Datenverkehr mit Rückfluss als Antwort zulässt.
Für eine optimale Benutzererfahrung empfehlen wir die Verwendung des neuesten Browsers Google Chrome oder Microsoft Edge (Chromium-basiert). Bitte stellen Sie sicher, dass der Webbrowser auf die Webcam, das Mikrofon und die Lautsprecher des Computers zugreifen kann, da Assist 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
Benötigte Bandbreite
Assist 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 wenn der Video-Feed unterbrochen wird, sollte der Ton noch übertragen werden können.
Insgesamt hängt Assist von einer Vielzahl verschiedener Faktoren ab, um zu bestimmen, wie viel Bandbreite für die Nutzung von Assist erforderlich ist. Im Allgemeinen gelten die folgenden Bandbreitenanforderungen:
Latenz
Auch die Latenz ist ein wichtiger Faktor bei der Verwendung von xAssist.
Hinweis: Eine niedrige Latenz ist besser als eine hohe Latenz.
Allgemeine Informationen
UDP wird TCP vorgezogen
UDP wird TCP vorgezogen, da es die Latenz bei der Paketübertragung reduziert, die durch die Unterschiede zwischen den beiden Protokollen verursacht wird.
Vollmachten und Paketinspektion
Kein Browser unterstützt UDP über Proxys, was bedeutet, dass die Daten den Proxy umgehen müssen, wenn Sie UDP verwenden möchten. Die Paketüberprüfung geht auf Kosten einer höheren Latenz. Oft ist die Latenz bei der Verwendung von Packet Inspection so hoch, dass Videoanrufe nicht mehr aufgebaut werden können.
WebRTC-Bedingungen
STUN-Server
Ein STUN-Server erledigt eine sehr einfache Aufgabe: Er teilt dem Client mit, welche öffentliche IP-Adresse und welcher Port sich hinter einem NAT-Dienst (Network Address Translation) befinden. Durch die Verwendung eines STUN-Servers können wir ableiten, ob der Client Peer-to-Peer-Verbindungen von anderen Clients im Internet akzeptiert.
TURN-Server
Ein TURN-Server bietet eine Fallbacklösung für Clients, die keine Peer-to-Peer-Verbindung herstellen können, und fungiert als Medienserver-Proxy zwischen den beiden Peers.
Signalisierung
Die Signalisierung wird verwendet, um die Video- und Audiostreams zwischen Clients zu initiieren. In Assist erfolgt die Signalisierung bei normalen Anrufen über das Frontline Command Center und bei Telefonkonferenzen über die Selective Forwarding Unit.
Interaktives Konnektivitäts-Establishment (ICE)
WebRTC verwendet ICE, um zu versuchen, den besten Weg für die Clients (Web- und Datenbrillen) zu finden, um in einem Anruf miteinander zu kommunizieren: Peer-to-Peer, Peer-to-Peer mit Network Address Translation (NAT) zwischen den Clients (unter Verwendung eines STUN-Servers) oder Relay über einen TURN-Server.
Bei normalen Anrufen (nicht Konferenzen) ist die erste Option für die Clients (Smart Glass und Expert über Web-UI) eine direkte Peer-to-Peer-Verbindung. Diese Option heißt HOST.
Die nächste Option besteht darin, eine Peer-to-Peer-Verbindung mit Network Address Translation (NAT) zwischen den Clients herzustellen. Diese Option wird als REFLEXIVE bezeichnet. Dies 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 Netzwerken ermöglichen.
Die letzte Option besteht darin, einen TURN-Server zu verwenden, der die Video- und Audiostreams weiterleitet. Diese Option wird als RELAYED bezeichnet.
Wenn die Option HOST oder REFLEXIVE verfügbar ist, dann sind die Video- und Audiostreams Peer-to-Peer (mit Ende-zu-Ende-Verschlüsselung) und es sollte eine sehr eingeschränkte Kommunikation mit dem STUN/TURN-Server gegeben 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 Ende-zu-Ende-Verschlüsselung).
Selektive Weiterleitungseinheit (SFU)
Im Falle einer Telefonkonferenz kommuniziert jeder Client mit der SFU anstelle der anderen Clients. Die SFU sendet die Streams dann an alle anderen Clients im Anruf. Wie bei einem normalen 1-zu-1-Anruf ist die Kommunikationsoption zur SFU HOST, REFLEXIVE oder RELAYED, und die Video- und Audiostreams zwischen jedem Client und der SFU werden Ende-zu-Ende-verschlüsselt. Das bedeutet, dass die SFU die eingehenden Streams entschlüsselt und neue verschlüsselte Streams an die Clients sendet. Daher erfolgt die Verschlüsselung zwischen den Clients nicht Ende-zu-Ende, sondern Hop-by-Hop.
Firewall-Konfiguration für xAssist-Clients
Für die genannten Regeln sollte Ihre NAT es den Clients (Smart Glasses und Experten über die Web-Benutzeroberfläche) ermöglichen, ausgehenden Datenverkehr mit zurückkehrendem Datenverkehr als Antwort zu haben, wenn Ihre NAT so konfiguriert ist, dass sie eine endpunktunabhängige Zuordnung und vorzugsweise eine adressabhängige Filterung oder eine endpunktunabhängige Filterung durchführt.
Wenn nicht alle in den folgenden Abschnitten genannten Regeln implementiert werden können (z. B. aufgrund von IT-Richtlinien), wählt WebRTC automatisch die bestmögliche Option aus, wie im Abschnitt Interactive Connectivity Establishment (ICE) beschrieben.
|Host/IP | Typ | Protokoll | Hafen | TCP/UDP |
|-----------------------------------|--------------------|-------------|------|---------|
| frontlineworker.com/[Ihre Domain] | Anwendungsserver | HTTPS/WSS | 443 | TCP |
Host-zu-Host-Kommunikation
Ein- und ausgehender UDP-Datenverkehr muss zugelassen werden. Die Portbereiche können über Gruppenrichtlinien für den Webbrowser konfiguriert werden.
|Zweck | Ziel-IP | Protokoll | Hafen(s) |
|------------------------|--------------------|----------|---------------|
| WebRTC-Peer-Verbindung | IP-Adresse des Remote-Peers| UDP | 1025 bis 65535 |
Frontline-STUN- und TURN-Server
TeamViewer bietet ein globales Netzwerk von verteilten STUN/TURN-Servern, einschließlich eines Load-Balancing-Mechanismus, der Assist-Benutzer automatisch dem optimalen STUN/TURN-Server für ihre Region zuweist.
|Region| IP-Bereich |Zweck| Ziel-IP |Protokoll| Hafen(s) |
|------|------------------|-------|-----------------------------------------|--------|------------------|
|GLOBAL| * | DREHEN | 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 | DREHEN | 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 | DREHEN | 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 | DREHEN | 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 | DREHEN | 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 wird eine der folgenden Probleme aufgelöst
Hinweis: HTTPS/TCP 443-Zugriff auf webrtc.svc.frontlineworker.com ist auch erforderlich, um Anmeldeinformationen für den TURN-Server zu erhalten.
Frontline-Konferenzserver (SFU)
TeamViewer bietet ein globales Netzwerk von verteilten SFUs, einschließlich eines Load-Balancing-Mechanismus, der xAssist-Benutzern basierend auf ihrer Region automatisch die optimale SFU zuweist.
Um Telefonkonferenzen zu ermöglichen, müssen webrtc.svc.frontlineworker.com zu Signalisierungszwecken über HTTPS / TCP 443 erreichbar sein.
|Region| IP-Bereich | Gastgeber | Typ |Protokoll | Hafen(s) |TCP/UDP|
|------|----------------|--------------------------------------|---------------------------------|---------|-----------|-------|
|GLOBAL|* |webrtc.svc.frontlineworker.com |Multicall-Gateway-Signalisierung |HTTPS/WSS|443 | TCP |
|EU |20.54.230.192/29|eu-webrtc.svc.frontlineworker.com |Multicall-Gateway-Signalisierung |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-Signalisierung |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-Signalisierung |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-Signalisierung |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-Signalisierung |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 wird eine der folgenden Probleme aufgelöst
Hinweis: Der HTTPS/TCP 443-Zugriff auf webrtc.svc.frontlineworker.com ist auch erforderlich, um sich bei den SFUs zu authentifizieren.
Assist-Sicherheitsinformationen
Assist Peer-to-Peer (1 zu 1 Anruf)
Das zugrunde liegende WebRTC-Framework erzwingt DTLS und SRTP auf allen Verbindungen, was bedeutet, dass Video und Audio Ende-zu-Ende verschlüsselt sind.
Auch bei Turn werden Pakete nur vom Empfänger entschlüsselt, niemals vom Turn-Server.
Assist-Konferenzen
Erzwungene Ende-zu-Ende-Verschlüsselung mit DTLS/SRTP vom Peer zur SFU. SFU entschlüsselt die Medien und verschlüsselt sie erneut, um sie an den Empfänger zu senden. Die Medien von keinem Peer werden jemals im persistenten Speicher gespeichert.
Die verwendete Verschlüsselungssammlung ist TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.