diff options
Diffstat (limited to 'src/Documentation/Technique/Services/Jitsi/index.md')
| -rw-r--r-- | src/Documentation/Technique/Services/Jitsi/index.md | 26 |
1 files changed, 26 insertions, 0 deletions
diff --git a/src/Documentation/Technique/Services/Jitsi/index.md b/src/Documentation/Technique/Services/Jitsi/index.md index 5d6fed8..c4a5967 100644 --- a/src/Documentation/Technique/Services/Jitsi/index.md +++ b/src/Documentation/Technique/Services/Jitsi/index.md @@ -62,3 +62,29 @@ Apparemment une issue est dédiée en particulier au problème que nous rencontr 2. Pour relayer la vidéo à travers la plupart des parefeux, notre `videobridge` Jitsi devait écouter sur le port `443/tcp`. Hors, ce port est déjà utilisé par notre frontal HTTPS. À défaut, Jitsi est maintenant configuré avec `8080/tcp` et `10000/udp` (contre `4443/tcp` et `10000/udp` avant). * Un déploiement en IPv6 pourrait résoudre le problème pour une partie des utilisateurs * Avoir un cluster géo-distribué avec plusieurs IPv4 pourrait également résoudre le problème + * Avoir un frontend layer 4 (niveau TCP) qui trouve une signature pour router du DTLS vers videobridge et du TLS vers traefik + +### À propos du videobridge + +Notre videobridge écoute donc sur les ports `8080/tcp` et `10000/udp`. + +WebRTC fonctionne en deux étapes : + - Des offres doivent être échangées via un serveur de signaling quelconque + - Ensuite, ces offres servent à connecter des clients directement via un protocole TCP ou UDP avec un thin layer propre à WebRTC + +#### Le signaling de Jitsi + +Le serveur de signaling Jitsi n'est autre que le serveur de chat prosody. +Pour ça, prosody est exposé à travers HTTP grâce au protocole BOSH (XMPP overs HTTPS). +Une fois l'offre reçue ([exemple](exemple_offre.txt)), elle est enregistrée dans le navigateur à l'aide de `setRemoteDescription`. +On peut débugger le signaling WebRTC sous Chromium avec [chrome://webrtc-internarls](chrome://webrtc-internals/). + +#### Le protocole WebRTC + +WebRTC utilise deux formats de paquets selon [Mozilla Developer Network|RTCDataChannel|DataFormat](https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel#Data_format) : + - `UDP/DTLS/SCTP` + - `TCP/DTLS/SCTP` + +On a donc un format de données arbitraire encapsulé dans du SCTP lui même encapsulé dans du DTLS. +DTLS est prévu pour les datagrammes à l'origine, car WebRTC est prévu d'abord pour fonctionner sous UDP. +Le TCP est là en mode dégradé, en secours, il sert juste de tunnel pour relayer des datagrammes. |