WebRTC et Unité de Transfert Sélectif
xAssist peut être configuré pour utiliser WebRTC comme protocole de communication afin de permettre une communication en temps réel via des connexions peer-to-peer. WebRTC est un domaine assez complexe et utilise le protocole de transport en temps réel pour transmettre de l’audio et de la vidéo. Assurez-vous que votre infrastructure réseau ne bloque pas les communications WebRTC et autorise le trafic sortant avec le trafic de retour en réponse.
Pour une expérience utilisateur optimale, nous vous recommandons d’utiliser la dernière version du navigateur Google Chrome ou Microsoft Edge (basé sur Chromium). Assurez-vous que le navigateur Web peut accéder à la webcam, au microphone et aux haut-parleurs de l’ordinateur, sinon xAssist ne fonctionnera pas correctement.
Stratégies de 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. Assurez-vous d’avoir accès à votre webcam.
- Google.Policies.Chrome ::VideoCaptureAllowed
- Google.Policies.Chrome ::AudioCaptureAllowed
Bande passante requise
xAssist s’adapte en permanence à la bande passante disponible. Si la bande passante disponible est faible, la qualité du streaming est automatiquement réduite. Cela s’applique principalement à la qualité vidéo, mais même si le flux vidéo est interrompu, l’audio doit toujours pouvoir être transmis.
Dans l’ensemble, xAssist dépend d’une variété de facteurs différents pour déterminer la quantité de bande passante requise pour utiliser xAssist. En général, les exigences suivantes en matière de bande passante s’appliquent :
Latence
La latence est également un facteur important lors de l’utilisation de xAssist.
Note: Une faible latence est préférable à une latence élevée.
Informations générales
UDP est préféré à TCP
UDP est préféré à TCP car il réduit la latence de transfert de paquets causée par les différences entre les deux protocoles.
Procurations et inspection des emballages
Aucun navigateur ne prend en charge UDP sur les proxys, ce qui signifie que les données doivent contourner le proxy si vous souhaitez utiliser UDP. L’inspection des paquets se fait au prix 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.
Conditions d’utilisation du WebRTC
Serveur STUN
Un serveur STUN fait un travail très simple, il indique au client quelle est son adresse IP publique réelle et son port derrière un service de traduction d’adresses réseau (NAT). En utilisant un serveur STUN, nous pouvons déduire si le client accepte des connexions peer-to-peer d’autres clients sur Internet.
Serveur TURN
Un serveur TURN fournit une solution de secours pour les clients qui ne peuvent pas établir de connexion d’égal à égal, agissant comme un proxy de serveur multimédia entre les deux homologues.
Signalisation
La signalisation est utilisée pour initier les flux vidéo et audio entre les clients. Dans xAssist, la signalisation s’effectue via le centre de commande de première ligne pour les appels normaux et via l’unité de transfert sélectif pour les conférences téléphoniques.
Établissement de connectivité interactive (ICE)
WebRTC utilise ICE pour essayer de trouver le meilleur moyen pour les clients (web et lunettes intelligentes) de communiquer entre eux lors d’un appel : peer-to-peer, peer-to-peer avec Network Address Translation (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 utilisateur Web) est une connexion peer-to-peer directe. Cette option s’appelle HOST.
L’option suivante consiste à établir une connexion peer-to-peer avec la traduction d’adresses réseau (NAT) entre les clients. Cette option s’appelle REFLEXIVE. Cela signifie que le serveur STUN essaiera de trouver une adresse IP publique et un port pour les clients qui permettront la communication peer-to-peer entre leurs différents réseaux locaux.
La dernière option consiste à utiliser un serveur TURN qui relaierait les flux vidéo et audio. Cette option s’appelle RELAYED.
Si l’option HOST ou REFLEXIVE est disponible, alors les flux vidéo et audio sont peer-to-peer (avec un chiffrement de bout en bout en place) et il devrait y avoir eu une communication très limitée 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 la communication RELAYED via le serveur TURN (toujours avec un chiffrement de bout en bout en place).
Unité d’expédition sélective (SFU)
Dans le cas d’une conférence téléphonique, chaque client communique avec l’Université Simon Fraser plutôt qu’avec les autres clients. L’Université Simon Fraser envoie ensuite les flux à tous les autres clients participant à l’appel. Comme dans le cas d’un appel 1-à-1 normal, l’option de communication avec le SFU sera HOST, REFLEXIVE ou RELAYED, et les flux vidéo et audio entre chaque client et le SFU seront chiffrés de bout en bout. Cela signifie que SFU déchiffrera les flux entrants et enverra de nouveaux flux chiffrés aux clients. Par conséquent, le chiffrement entre les clients n’est pas de bout en bout, mais saut par saut.
Configuration du pare-feu pour les clients xAssist
Pour les règles mentionnées, votre NAT doit permettre aux clients (lunettes intelligentes et experts via l’interface utilisateur Web) d’avoir un trafic sortant avec un trafic de retour en réponse si votre NAT est configuré pour effectuer un mappage indépendant du point de terminaison et, de préférence, un filtrage dépendant de l’adresse ou un filtrage indépendant du point de terminaison.
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 Établissement de connectivité interactive (ICE).
|Hôte/IP | Tapez | Protocole | Port | TCP/UDP | |-----------------------------------|--------------------|-------------|------|---------| | frontlineworker.com/[votre domaine] | Serveur d’applications | HTTPS/WSS | 443 | TCP |
Communication d’hôte à hôte
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.
|Objectif | Adresse IP de destination| Protocole | Port(s) | |------------------------|--------------------|----------|---------------| | Connexion d’homologue WebRTC | l’adresse IP de l’homologue distant| UDP | 1025 à 65535 |
Serveur STUN et TURN de première ligne
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 xAssist au serveur STUN/TURN optimal pour leur région.
|Région| Plage d’adresses IP|Objectif| Adresse IP de destination|Protocole| Port(s) |
|------|------------------|-------|-----------------------------------------|--------|------------------|
|À L’ÉCHELLE MONDIALE| * | TOURNER | turn.svc.frontlineworker.com | TCP |8080 |
|À L’ÉCHELLE MONDIALE| * | ÉTOURDISSEMENT | turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|UE | 20.54.230.192/29 | TOURNER | eu-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|UE | 20.54.230.192/29 | ÉTOURDISSEMENT | eu-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|États-Unis | 20.84.226.80/29 | TOURNER | us-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|États-Unis | 20.84.226.80/29 | ÉTOURDISSEMENT | us-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|SA | 20.201.68.120/29 | TOURNER | sa-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|SA | 20.201.68.120/29 | ÉTOURDISSEMENT | sa-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|JP | 20.210.56.40/29 | TOURNER | jp-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|JP | 20.210.56.40/29 | ÉTOURDISSEMENT | jp-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|IN | 52.140.81.48/29 | TOURNER | in-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|IN | 52.140.81.48/29 | ÉTOURDISSEMENT | in-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
*En fonction de la région/DNS résolvant l’un des problèmes ci-dessous
Note: Un accès HTTPS/TCP 443 à webrtc.svc.frontlineworker.com est également requis pour obtenir les informations d’identification du serveur TURN.
Serveurs de conférence de première ligne (SFU)
TeamViewer fournit un réseau mondial de SFU distribués, y compris un mécanisme d’équilibrage de charge qui attribue automatiquement le SFU optimal aux utilisateurs xAssist en fonction de leur région.
Pour permettre les conférences téléphoniques, webrtc.svc.frontlineworker.com doivent être joignables via HTTPS / TCP 443 à des fins de signalisation.
|Région| Plage d’adresses IP| Hôte | Tapez |Protocole | Port(s) |TCP/UDP|
|------|----------------|--------------------------------------|---------------------------------|---------|-----------|-------|
|GLOBAL|* |webrtc.svc.frontlineworker.com |Signalisation de passerelle d’appel multiple|HTTPS/WSS|443 | TCP |
|EU |20.54.230.192/29|eu-webrtc.svc.frontlineworker.com |Signalisation de passerelle d’appel multiple|HTTPS/WSS|443 | TCP |
|EU |20.54.230.192/29|eu-{0..10}.sfu.svc.frontlineworker.com|Passerelle d’appel multiple Vidéo/Audio/RTP| RTP |40000-45000| UDP |
|États-Unis |20.84.226.80/29 |us-webrtc.svc.frontlineworker.com |Signalisation de passerelle d’appel multiple|HTTPS/WSS|443 | TCP |
|US |20.84.226.80/29 |us-{0..10}.sfu.svc.frontlineworker.com|Passerelle d’appel multiple Vidéo/Audio/RTP| RTP |40000-45000| UDP |
|SA |20.201.68.120/29|sa-webrtc.svc.frontlineworker.com |Signalisation de passerelle d’appel multiple|HTTPS/WSS|443 | TCP |
|SA |20.201.68.120/29|sa-{0..10}.sfu.svc.frontlineworker.com|Passerelle d’appel multiple Vidéo/Audio/RTP| RTP |40000-45000| UDP |
|JP |20.210.56.40/29 |jp-webrtc.svc.frontlineworker.com |Signalisation de passerelle d’appel multiple|HTTPS/WSS|443 | TCP |
|JP |20.210.56.40/29 |jp-{0..10}.sfu.svc.frontlineworker.com|Passerelle d’appel multiple Vidéo/Audio/RTP| RTP |40000-45000| UDP |
|IN |52.140.81.48/29 |in-webrtc.svc.frontlineworker.com |Signalisation de passerelle d’appel multiple|HTTPS/WSS|443 | TCP |
|IN |52.140.81.48/29 |in-{0..10}.sfu.svc.frontlineworker.com|Passerelle d’appel multiple Vidéo/Audio/RTP| RTP |40000-45000| UDP |
*En fonction de la région/DNS résolvant l’un des problèmes ci-dessous
Note: L’accès HTTPS/TCP 443 aux webrtc.svc.frontlineworker.com est également requis pour s’authentifier auprès des SFU.
Informations sur la sécurité xAssist
xAssist peer-to-peer (appel 1 à 1)
Le framework WebRTC sous-jacent force 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échiffrés que par le destinataire, jamais par le serveur Turn.
Conférences xAssist
Chiffrement forcé de bout en bout à l’aide de DTLS/SRTP de l’homologue vers SFU. SFU déchiffre et rechiffre le média pour l’envoyer au destinataire. Aucun média d’un homologue n’est jamais stocké dans un stockage persistant.
La suite de chiffrement utilisée est TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.