Rework website structure

3 files changed, 0 insertions, 212 deletions

diff --git a/src/Documentation/Technique/Services/Jitsi/exemple_offre.txt b/src/Documentation/Technique/Services/Jitsi/exemple_offre.txt
deleted file mode 100644
index 3af76ec..0000000
--- a/src/Documentation/Technique/Services/Jitsi/exemple_offre.txt
+++ /dev/null
@@ -1,118 +0,0 @@
-type: offer, sdp: v=0
-o=- 1923518516 2 IN IP4 127.0.0.1
-s=-
-t=0 0
-a=msid-semantic: WMS 48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1
-a=group:BUNDLE audio video data
-m=audio 10000 RTP/SAVPF 111 103 104 126
-c=IN IP4 82.253.205.190
-a=rtpmap:111 opus/48000/2
-a=rtpmap:103 ISAC/16000
-a=rtpmap:104 ISAC/32000
-a=rtpmap:126 telephone-event/8000
-a=fmtp:111 minptime=10;useinbandfec=1
-a=rtcp:9 IN IP4 0.0.0.0
-a=rtcp-fb:111 transport-cc
-a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
-a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
-a=setup:actpass
-a=mid:audio
-a=sendrecv
-a=ice-ufrag:97nc61e52b11gu
-a=ice-pwd:k2df7f8vgknj27sctj550cl2u
-a=fingerprint:sha-1 FC:4F:0B:F5:34:07:D8:09:47:D2:3C:FE:D1:8E:05:4B:05:10:CD:A1
-a=candidate:1 1 ssltcp 2130706431 172.17.0.1 8080 typ host generation 0
-a=candidate:2 1 ssltcp 2130706431 192.168.1.4 8080 typ host generation 0
-a=candidate:4 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
-a=candidate:5 1 udp 2113932031 192.168.1.4 10000 typ host generation 0
-a=candidate:3 1 ssltcp 1677724415 82.253.205.190 8080 typ srflx raddr 192.168.1.4 rport 8080 generation 0
-a=candidate:6 1 udp 1677724415 82.253.205.190 10000 typ srflx raddr 192.168.1.4 rport 10000 generation 0
-a=ssrc:3265394670 cname:mixed
-a=ssrc:3265394670 msid:mixedmslabel mixedlabelaudio0
-a=ssrc:3265394670 mslabel:mixedmslabel
-a=ssrc:3265394670 label:mixedlabelaudio0
-a=ssrc:3761143749 cname:sMYSy0kNyRU3eK0c-1
-a=ssrc:3761143749 msid:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1 8a034425-b6b5-4928-ab5f-9ca0ec4168c4-1
-a=ssrc:3761143749 mslabel:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1
-a=ssrc:3761143749 label:8a034425-b6b5-4928-ab5f-9ca0ec4168c4-1
-a=ssrc:3240916804 cname:75Ayhq4Cuv7k5JAP-1
-a=ssrc:3240916804 msid:27755a82-e9e7-4cc4-bdb3-354a06b3f32a-1 45de0b7f-8590-4232-9bde-77d55a7366b5-1
-a=rtcp-mux
-m=video 10000 RTP/SAVPF 100 107 101 96 97 99
-c=IN IP4 82.253.205.190
-a=rtpmap:100 VP8/90000
-a=rtpmap:107 H264/90000
-a=rtpmap:101 VP9/90000
-a=rtpmap:96 rtx/90000
-a=rtpmap:97 rtx/90000
-a=rtpmap:99 rtx/90000
-a=fmtp:100 x-google-start-bitrate=800
-a=fmtp:107 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f;x-google-start-bitrate=800
-a=fmtp:101 x-google-start-bitrate=800
-a=fmtp:96 apt=100
-a=fmtp:97 apt=101
-a=fmtp:99 apt=107
-a=rtcp:9 IN IP4 0.0.0.0
-a=rtcp-fb:100 ccm fir
-a=rtcp-fb:100 nack
-a=rtcp-fb:100 nack pli
-a=rtcp-fb:100 transport-cc
-a=rtcp-fb:107 ccm fir
-a=rtcp-fb:107 nack
-a=rtcp-fb:107 nack pli
-a=rtcp-fb:107 transport-cc
-a=rtcp-fb:101 ccm fir
-a=rtcp-fb:101 nack
-a=rtcp-fb:101 nack pli
-a=rtcp-fb:101 transport-cc
-a=rtcp-fb:96 ccm fir
-a=rtcp-fb:96 nack
-a=rtcp-fb:96 nack pli
-a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
-a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
-a=setup:actpass
-a=mid:video
-a=sendrecv
-a=ice-ufrag:97nc61e52b11gu
-a=ice-pwd:k2df7f8vgknj27sctj550cl2u
-a=fingerprint:sha-1 FC:4F:0B:F5:34:07:D8:09:47:D2:3C:FE:D1:8E:05:4B:05:10:CD:A1
-a=candidate:1 1 ssltcp 2130706431 172.17.0.1 8080 typ host generation 0
-a=candidate:2 1 ssltcp 2130706431 192.168.1.4 8080 typ host generation 0
-a=candidate:4 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
-a=candidate:5 1 udp 2113932031 192.168.1.4 10000 typ host generation 0
-a=candidate:3 1 ssltcp 1677724415 82.253.205.190 8080 typ srflx raddr 192.168.1.4 rport 8080 generation 0
-a=candidate:6 1 udp 1677724415 82.253.205.190 10000 typ srflx raddr 192.168.1.4 rport 10000 generation 0
-a=ssrc:3339205972 cname:75Ayhq4Cuv7k5JAP-1
-a=ssrc:3339205972 msid:27755a82-e9e7-4cc4-bdb3-354a06b3f32a-1 4de277cb-7421-402a-bbb1-2090dab4540e-1
-a=ssrc:3560865865 cname:sMYSy0kNyRU3eK0c-1
-a=ssrc:3560865865 msid:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1 21a02fe8-c9f4-49fe-aaef-4c4ad48a3516-1
-a=ssrc:3560865865 mslabel:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1
-a=ssrc:3560865865 label:21a02fe8-c9f4-49fe-aaef-4c4ad48a3516-1
-a=ssrc:1942865873 cname:mixed
-a=ssrc:1942865873 msid:mixedmslabel mixedlabelvideo0
-a=ssrc:1942865873 mslabel:mixedmslabel
-a=ssrc:1942865873 label:mixedlabelvideo0
-a=ssrc:3656552182 cname:sMYSy0kNyRU3eK0c-1
-a=ssrc:3656552182 msid:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1 21a02fe8-c9f4-49fe-aaef-4c4ad48a3516-1
-a=ssrc:3656552182 mslabel:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1
-a=ssrc:3656552182 label:21a02fe8-c9f4-49fe-aaef-4c4ad48a3516-1
-a=ssrc:4136660991 cname:75Ayhq4Cuv7k5JAP-1
-a=ssrc:4136660991 msid:27755a82-e9e7-4cc4-bdb3-354a06b3f32a-1 4de277cb-7421-402a-bbb1-2090dab4540e-1
-a=ssrc-group:FID 3560865865 3656552182
-a=ssrc-group:FID 3339205972 4136660991
-a=rtcp-mux
-a=x-google-flag:conference
-m=application 10000 DTLS/SCTP 5000
-c=IN IP4 82.253.205.190
-a=setup:actpass
-a=mid:data
-a=ice-ufrag:97nc61e52b11gu
-a=ice-pwd:k2df7f8vgknj27sctj550cl2u
-a=fingerprint:sha-1 FC:4F:0B:F5:34:07:D8:09:47:D2:3C:FE:D1:8E:05:4B:05:10:CD:A1
-a=candidate:1 1 ssltcp 2130706431 172.17.0.1 8080 typ host generation 0
-a=candidate:2 1 ssltcp 2130706431 192.168.1.4 8080 typ host generation 0
-a=candidate:4 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
-a=candidate:5 1 udp 2113932031 192.168.1.4 10000 typ host generation 0
-a=candidate:3 1 ssltcp 1677724415 82.253.205.190 8080 typ srflx raddr 192.168.1.4 rport 8080 generation 0
-a=candidate:6 1 udp 1677724415 82.253.205.190 10000 typ srflx raddr 192.168.1.4 rport 10000 generation 0
-a=sctpmap:5000 webrtc-datachannel 1024
diff --git a/src/Documentation/Technique/Services/Jitsi/index.md b/src/Documentation/Technique/Services/Jitsi/index.md
deleted file mode 100644
index dee7b53..0000000
--- a/src/Documentation/Technique/Services/Jitsi/index.md
+++ /dev/null
@@ -1,94 +0,0 @@
-## 2020-04-02 Campagne de debug Jitsi
-
-Contact: Quentin
-
-### Description du problème
-
-Les conversations à 3+ donc relayées par le serveur ne fonctionnent pas bien.
-Louison m'a rapporté que ça avait marché pour lui (3 utilisateurs avec un Webkit).
-Mais moi ça a échoué hier soir (01/04/2020) avec des participants sous Firefox.
-Le bug est toujours le même : on entend 2 personnes sur 3 ou on voit 2 personnes sur 3, on recharge la page et c'est quelqu'un d'autre pour qui ça ne fonctionne plus. Souvent c'est que dans un sens.
-À chaque fois en passant sur Facebook Messenger, le problème est résolu instantanément.
-Par contre Facebook Messenger impose Google Chrome/Chromium pour les visio de groupe (et ne supporte donc pas Firefox).
-
-D'où mes 2 suspicions :
-
-  - Firefox a un bug quelconque dans sa pile WebRTC déclenché par le mode conversation de groupe
-  - Jitsi a un problème avec les déconnexions/changement de connexion/petit hoquets du réseau et n'arrive pas à se reconnecter. Ça pourrait être rendu pire à certain moment de la journée comme le soir où le réseau est plus sollicité. Et ce serait provoqué lors du reload on repasse de 3 à 2, en P2P donc puis de nouveau de 2 à 3.
-
-### Approfondissement
-
-Avant d'aller plus loin, nous avons voulu prendre le temps d'identifier précisément les problèmes d'expérience utilisateurs et leur corrélation avec la plateforme de l'utilisateur (navigateur, OS).
-
-Pour celà, nous avons suivi deux approches :
-  1. Mener nos propres tests
-  2. Chercher d'autres retours
-
-#### Mener nos propres tests
-
-Nous avons effectué deux appels : un avec Firefox seulement et un avec Chrome/Chromium seulement.
-Merci à Alex, Adrien et Maximilien pour leur participation.
-
-Voilà les conclusions que nous avons tirées de nos tests :
-
-  - L'appel avec Firefox a déclenché le bug immédiatement, peu importe la version de Firefox ou de l'OS (firefox stable/nightly, fedora stable/beta, etc.)
-  - Le passage de tout le monde sous Chrome/Chromium a permis d'avoir une conversation stable.
-  - Adrien avait sa Livebox avec pare-feu configuré en mode "élevé" et a du ajouter dans sa liste blanche les ports utilisés par Jitsi (`4443/tcp` et `10000/udp` au moment du test, seul un des deux a besoin d'être accessible)
-
-Nous avons donc demandé à Adrien quels étaient les ports ouverts par défaut dans le mode élevé de sa box :
-
-![Livebox Parefeu Personnalisé](livebox_parefeu_personnalise.png)
-
-Nous avons dans un premier temps retenu le port `995/tcp` pour Jitsi, le port UDP ne pouvant être changé (limitation de Jitsi).
-Cependant, pour des raisons de sécurité, les navigateurs ne peuvent pas utiliser les ports en dessous de `1024/*`, à l'exception des ports `80/tcp` et `443/tcp` comme l'indique ;'issue [#3583](https://bugs.chromium.org/p/webrtc/issues/detail?id=3583) de Chromium.
-
-La capture n'indique pas de port TCP supérieur à 1024, nous ne pouvons donc pas résoudre ce problème de notre côté, car à l'heure actuelle, nos ports `80/tcp` et `443/tcp` sont utilisés et nous n'avons qu'une seule IP publique.
-Les utilisateurs activant le parefeu en mode élevé devront ajouter une exception dans leur parefeu eux-mêmes.
-
-#### Chercher d'autres retours
-
-[Tedomum](https://tedomum.net/) a eu connaissance de problèmes similaires.
-Ils ont également identifié Firefox et assurent qu'avec l'application Android ça marche bien.
-Ils me confirment que le problème vient bien du logiciel et non pas de notre déploiement.
-Ils m'ont pointé entre autre vers cette issue github [#4758](https://github.com/jitsi/jitsi-meet/issues/4758)
-Apparemment une issue est dédiée en particulier au problème que nous rencontrons de déconnexion partielle d'un participant, mais nous ne l'avons pas encore retrouvée.
-
-### Correctifs
-
-  1. Notre instance Jitsi a été reconfigurée pour refuser Firefox. Suivre l'avancée du développement de Jitsi pour Firefox
-    * [#4758](https://github.com/jitsi/jitsi-meet/issues/4758)
-    * [#5439](https://github.com/jitsi/jitsi-meet/issues/5439)
-    * _À compléter_
-  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 control/data plane de Jitsi
-
-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 control plane de Jitsi : Prosody sur HTTPS via Bosh/XMPP
-
-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` pour initialiser le data plane.
-On peut débugger le signaling WebRTC sous Chromium avec [chrome://webrtc-internarls](chrome://webrtc-internals/).
-
-Quand plus de deux participants sont connectés dans la conversation, Jitsi n'envoie pas les offres de chaque participant aux autres participants. À la place, elle envoie qu'une seule offre, celle de son VideoBridge.
-
-Ainsi, le VideoBridge est une sorte de client WebRTC particulier, qui récolte et redispatche à travers WebRTC tous les flux video/audio. 
-
-#### Le data plane de Jitsi : videobridge sur DTLS/SCTP via 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.
diff --git a/src/Documentation/Technique/Services/Jitsi/livebox_parefeu_personnalise.png b/src/Documentation/Technique/Services/Jitsi/livebox_parefeu_personnalise.png
deleted file mode 100644
index 16c922a..0000000
--- a/src/Documentation/Technique/Services/Jitsi/livebox_parefeu_personnalise.png
+++ /dev/null