Mise à jour de la page

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.