WebRTC und Selective Forwarding Unit

xAssist 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 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

Benötigte 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 wenn der Video-Feed unterbrochen wird, sollte der Ton noch übertragen werden können.

Insgesamt hängt xAssist von einer Vielzahl verschiedener Faktoren ab, um zu bestimmen, wie viel Bandbreite für die Nutzung von xAssist erforderlich ist. Im Allgemeinen gelten die folgenden Bandbreitenanforderungen:

Stufen/Typen Eingehende Bandbreite Ausgehende Bandbreite

Minimale Bandbreite 

300 Kbit/s

300  Kbit/s

Empfohlene Bandbreite

3,2 Mbit/s

2,8 Mbit/s

Latenz

Auch die Latenz ist ein wichtiger Faktor bei der Verwendung von xAssist.

Hinweis: Eine niedrige Latenz ist besser als eine hohe Latenz.

Bewertung Latenz

Empfohlene Latenz

< 100 ms

Akzeptable Latenz

< 400 ms

Schlechte Latenz

> 400 ms

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 xAssist 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 xAssist-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.

xAssist-Sicherheitsinformationen

xAssist 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.

xAssist-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.

Externe Quellen

  1. https://webrtc-security.github.io/
  2. https://github.com/versatica/mediasoup