⚙️ Documentation technique - Appels audio Tchap
Les appels audio Tchap sont chiffrés de bout en bout par une technologie embarqué dans les clients Tchap.
Pour maximiser les possibilités de connexion entre les appareils de deux appareils Tchap, il est conseillé de vérifier les points suivants :
Sur les postes clients (web browser, mobile):
- à minima, permettre l'ouverture de flux TLS/TCP vers le port 443 en direction des serveurs *.turn.tchap.gouv.fr
- les flux TCP ou UDP (non TLS) vers les serveurs *.turn.tchap.gouv.fr améliore la connexion quand c'est possible.
Sur les appareils sécurisés :
- permettre l'ouverture de flux TLS/TCP vers le port 443 en direction des serveurs *.turn.tchap.gouv.fr
Selon nos mesures, un appel audio consomme entre 3 et 5ko/s. Selon le mode de connexion choisi lors de l'établissement de l'appel webRTC, les données circulent directement entre les clients ou alors transitent par nos serveurs relai coturn.
Afin de ne pas peser trop lourd sur les infrastructures réseaux, nous avons décidé de ne permettre que les appels audio dans un premier temps.
Selon nos mesures les appels vidéo consomment environ 300ko/s, soit presque 100 fois plus.
Les appels audio Tchap se basent sur le protocole webRTC. Nous avons installés des serveurs relais coturn (TURN and STUN), hebergés par outscale en zone SecnumCloud, sur les urls : .turn.tchap.gouv.fr* afin de faciliter les appels entre les appareils.
Si deux appareils de test sont sur le même réseau, ils sont en mesure de se voir et de se connecter directement entre eux (protocole UDP)
Si deux appareils ne sont pas sur le même réseau, ils utilisent les serveurs coturn pour se découvrir (STUN et NAT hole punching). Les serveurs utilisés pour la découverte des ports et IPs sont *.turn.tchap.gouv.fr, port 3478.
Une fois découverts, si la configuration réseau le permet, ils vont communiquer en webRTC directement (les paquets de données VoIP transiteront directement d'un appareil à l'autre en peer-to-peer).
Si les configurations réseau ne permettent pas une communication webRTRC directe, ils vont alors communiquer via les serveurs coturn qui serviront de relais pour acheminer les paquets de données VoIP via des flux en UDP si possible et TCP sinon, port 3478.
Finalement, si les flux UDP ne passent pas, le serveur TURN encapsule le trafic WebRTC en TLS sur TCP sur le port 443, qui est généralement ouvert sur la plupart des pare-feu pour le trafic HTTPS, permettant ainsi de contourner les restrictions sur les ports UDP.
Le but de ce plan de test est de s'assurer que les appels audio aboutissent dans les conditions de réseaux les plus courantes des utilisateurs et administrations.
En résumé, les différents mécanismes de fallback de webRTC permettent de gérer de nombreuses situations. Le mécanisme le plus résilient étant le flux TLS/TCP (appelé anciennement SSL), il faut s'assurer que:
> le poste client (web browser, mobile) peut ouvrir un flux TLS/TCP vers le port 443 en direction des serveurs *.turn.tchap.gouv.fr
Point d'attention technique sur l'établissement de la connection
Pour maximiser les possibilités de connexion entre les appareils de deux appareils Tchap, il est conseillé de vérifier les points suivants :
Sur les postes clients (web browser, mobile):
- à minima, permettre l'ouverture de flux TLS/TCP vers le port 443 en direction des serveurs *.turn.tchap.gouv.fr
- les flux TCP ou UDP (non TLS) vers les serveurs *.turn.tchap.gouv.fr améliore la connexion quand c'est possible.
Sur les appareils sécurisés :
- permettre l'ouverture de flux TLS/TCP vers le port 443 en direction des serveurs *.turn.tchap.gouv.fr
Bande passante requise
Selon nos mesures, un appel audio consomme entre 3 et 5ko/s. Selon le mode de connexion choisi lors de l'établissement de l'appel webRTC, les données circulent directement entre les clients ou alors transitent par nos serveurs relai coturn.
Afin de ne pas peser trop lourd sur les infrastructures réseaux, nous avons décidé de ne permettre que les appels audio dans un premier temps.
Selon nos mesures les appels vidéo consomment environ 300ko/s, soit presque 100 fois plus.
Technologie mise en oeuvre
Les appels audio Tchap se basent sur le protocole webRTC. Nous avons installés des serveurs relais coturn (TURN and STUN), hebergés par outscale en zone SecnumCloud, sur les urls : .turn.tchap.gouv.fr* afin de faciliter les appels entre les appareils.
Si deux appareils de test sont sur le même réseau, ils sont en mesure de se voir et de se connecter directement entre eux (protocole UDP)
Si deux appareils ne sont pas sur le même réseau, ils utilisent les serveurs coturn pour se découvrir (STUN et NAT hole punching). Les serveurs utilisés pour la découverte des ports et IPs sont *.turn.tchap.gouv.fr, port 3478.
Une fois découverts, si la configuration réseau le permet, ils vont communiquer en webRTC directement (les paquets de données VoIP transiteront directement d'un appareil à l'autre en peer-to-peer).
Si les configurations réseau ne permettent pas une communication webRTRC directe, ils vont alors communiquer via les serveurs coturn qui serviront de relais pour acheminer les paquets de données VoIP via des flux en UDP si possible et TCP sinon, port 3478.
Finalement, si les flux UDP ne passent pas, le serveur TURN encapsule le trafic WebRTC en TLS sur TCP sur le port 443, qui est généralement ouvert sur la plupart des pare-feu pour le trafic HTTPS, permettant ainsi de contourner les restrictions sur les ports UDP.
Le but de ce plan de test est de s'assurer que les appels audio aboutissent dans les conditions de réseaux les plus courantes des utilisateurs et administrations.
En résumé, les différents mécanismes de fallback de webRTC permettent de gérer de nombreuses situations. Le mécanisme le plus résilient étant le flux TLS/TCP (appelé anciennement SSL), il faut s'assurer que:
> le poste client (web browser, mobile) peut ouvrir un flux TLS/TCP vers le port 443 en direction des serveurs *.turn.tchap.gouv.fr
Mis à jour le : 10/06/2024
Merci !