WebRTC et Selective Forwarding Unit
xAssist peut être configuré pour utiliser WebRTC comme protocole de communication afin de permettre une communication en temps réel sur des connexions peer-to-peer. WebRTC est un domaine assez complexe qui utilise le protocole de transport en temps réel pour transmettre de l'audio et de la vidéo. Veuillez vous assurer que votre infrastructure réseau ne bloque pas les communications WebRTC et qu'elle autorise le trafic sortant avec un trafic de retour en réponse.
Pour une meilleure expérience utilisateur, nous recommandons d'utiliser la dernière version du navigateur Google Chrome ou Microsoft Edge (basé sur Chromium). Veillez à ce que le navigateur web puisse accéder à la webcam, au microphone et aux haut-parleurs de l'ordinateur, faute de quoi xAssist ne fonctionnera pas correctement.
Politiques du groupe
Dans les environnements Microsoft Active Directory, les stratégies de groupe peuvent refuser l'accès à la webcam et au microphone de l'ordinateur. Veuillez vous assurer que vous avez accès à votre webcam.
- Google.Policies.Chrome::VideoCaptureAllowed
- Google.Policies.Chrome::AudioCaptureAllowed
Largeur de bande requise
xAssist s'adapte en permanence à la bande passante disponible. Si la bande passante disponible est faible, la qualité de la diffusion en continu est automatiquement réduite. Cela s'applique principalement à la qualité vidéo, mais même si le flux vidéo est interrompu, l'audio devrait toujours pouvoir être transmis.
Dans l'ensemble, xAssist dépend d'une série de facteurs différents pour déterminer la largeur de bande requise pour l'utilisation de xAssist. En général, les exigences suivantes en matière de bande passante s'appliquent :
Temps de latence
La latence est également un facteur important lors de l'utilisation de xAssist.
Remarque : une latence faible est préférable à une latence élevée.
Informations générales
UDP est préféré à TCP
L'UDP est préféré au TCP parce qu'il réduit la latence de transfert des paquets causée par les différences entre les deux protocoles.
Proxies et inspection des paquets
Aucun navigateur ne prend en charge l'UDP sur les proxys, ce qui signifie que les données doivent contourner le proxy si vous souhaitez utiliser l'UDP. L'inspection des paquets s'accompagne d'une latence plus élevée. Souvent, la latence lors de l'utilisation de l'inspection des paquets est si élevée qu'elle empêche l'établissement d'appels vidéo.
Termes WebRTC
Serveur STUN
Un serveur STUN a une fonction très simple : il indique au client son adresse IP publique et son port réels derrière un service de traduction d'adresses de réseau (NAT). L'utilisation d'un serveur STUN permet de savoir si le client accepte des connexions d'égal à égal avec d'autres clients sur l'internet.
Serveur TURN
Un serveur TURN constitue une solution de repli pour les clients qui ne peuvent pas établir de connexion poste à poste, en agissant comme un serveur média proxy entre les deux postes.
Signalisation
La signalisation est utilisée pour initier les flux vidéo et audio entre les clients. Dans xAssist, la signalisation se fait via le centre de commande Frontline pour les appels normaux et via l'unité de renvoi sélectif pour les conférences téléphoniques.
Établissement de connectivité interactive (ICE)
WebRTC utilise l'ICE pour essayer de trouver la meilleure façon pour les clients (web et lunettes intelligentes) de communiquer entre eux lors d'un appel : Peer-to-peer, peer-to-peer avec traduction d'adresse réseau (NAT) entre les clients (à l'aide d'un serveur STUN), ou relayé à l'aide d'un serveur TURN.
Pour les appels normaux (pas les conférences), la première option pour les clients (Smart Glass et Expert via l'interface Web) est une connexion directe d'égal à égal. Cette option est appelée HOST.
L'option suivante consiste à établir une connexion d'égal à égal avec traduction d'adresses de réseau (NAT) entre les clients. Cette option est appelée REFLEXIVE. Cela signifie que le serveur STUN essaiera de trouver une adresse IP et un port publics pour les clients qui permettront une communication d'égal à égal entre leurs différents réseaux locaux.
La dernière option consiste à utiliser un serveur TURN qui relaiera les flux vidéo et audio. Cette option est appelée RELAYED.
Si l'option HOST ou REFLEXIVE est disponible, les flux vidéo et audio sont en peer-to-peer (avec un cryptage de bout en bout) et il devrait y avoir eu très peu de communication avec le serveur STUN/TURN pour rassembler les différents candidats pour les trois options.
Si aucune des deux premières options n'est disponible (en raison d'un NAT symétrique, d'un pare-feu ou d'autres problèmes), les clients utiliseront une communication RELAYÉE via le serveur TURN (toujours avec un cryptage de bout en bout).
Unité de réacheminement sélectif (SFU)
Dans le cas d'une conférence téléphonique, chaque client communique avec le SFU au lieu des autres clients. La SFU envoie ensuite les flux à tous les autres clients de l'appel. Comme pour un appel 1 à 1 normal, l'option de communication vers la SFU sera HOST, REFLEXIVE ou RELAYÉE, et les flux vidéo et audio entre chaque client et la SFU seront cryptés de bout en bout. Cela signifie que la SFU décrypte les flux entrants et envoie de nouveaux flux cryptés aux clients. Par conséquent, le cryptage entre les clients n'est pas de bout en bout, mais de saut en saut.
Configuration du pare-feu pour les clients xAssist
Pour les règles mentionnées, votre NAT devrait permettre aux clients (lunettes intelligentes et experts via l'interface Web) d'avoir un trafic sortant avec un trafic de retour en réponse si votre NAT est configuré pour faire un mappage indépendant du point final et de préférence un filtrage dépendant de l'adresse ou un filtrage indépendant du point final.
Si toutes les règles mentionnées dans les sections suivantes ne peuvent pas être mises en œuvre (par exemple, en raison de politiques informatiques), WebRTC choisira automatiquement la meilleure option possible, comme décrit dans la section sur l'établissement de la connectivité interactive (ICE).
| Host/IP | Type | Protocol | Port | TCP/UDP |
|-----------------------------------|--------------------|-------------|------|---------|
| frontlineworker.com/[your domain] | Application Server | HTTPS/WSS | 443 | TCP |
Host-àhost communication
Le trafic UDP entrant et sortant doit être autorisé. Les plages de ports peuvent être configurées via la stratégie de groupe pour le navigateur web.
| Purpose | Destination IP | Protocol | Port(s) |
|------------------------|--------------------|----------|---------------|
| WebRTC Peer Connection | remote peer's IP | UDP | 1025 to 65535 |
Frontline Serveur STUN et TURN
TeamViewer fournit un réseau mondial de serveurs STUN/TURN distribués, y compris un mécanisme d'équilibrage de charge qui affecte automatiquement les utilisateurs de xAssist au serveur STUN/TURN optimal pour leur région.
|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 |
*En fonction de la région/DNS résolvant l'un des points suivants
Note : Un accès HTTPS/TCP 443 à webrtc.svc.frontlineworker.com est également nécessaire pour obtenir les informations d'identification du serveur TURN.
Frontline Serveurs de conférence (SFU)
TeamViewer fournit un réseau mondial de SFU distribués, y compris un mécanisme d'équilibrage de la charge qui attribue automatiquement le SFU optimal aux utilisateurs de xAssist en fonction de leur région.
Pour permettre les conférences téléphoniques, webrtc.svc.frontlineworker.com doit être accessible via HTTPS / TCP 443 à des fins de signalisation.
|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 |
*En fonction de la région/DNS résolvant l'un des points suivants
Note : L'accès HTTPS/TCP 443 à webrtc.svc.frontlineworker.com est également nécessaire pour s'authentifier auprès des SFU.
xInformations sur la sécurité de l'assistance
xAssist peer-to-peer (appel 1 à 1)
Le cadre WebRTC sous-jacent impose DTLS et SRTP sur toutes les connexions, ce qui signifie que la vidéo et l'audio sont chiffrés de bout en bout.
Même avec Turn, les paquets ne sont décryptés que par le destinataire, jamais par le serveur Turn.
xConférences d'assistance
Chiffrement forcé de bout en bout à l'aide de DTLS/SRTP de l'homologue à la SFU. La SFU décrypte et recrypte le média pour l'envoyer au destinataire. Aucun média de l'homologue n'est jamais stocké dans un espace de stockage permanent.
La suite de chiffrement utilisée est TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
Sources externes
- https://webrtc-security.github.io/
- https://github.com/versatica/mediasoup
