diff options
Diffstat (limited to 'src/Technique/Operations/Jitsi.md')
| -rw-r--r-- | src/Technique/Operations/Jitsi.md | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/src/Technique/Operations/Jitsi.md b/src/Technique/Operations/Jitsi.md index 8e87d8f..354710e 100644 --- a/src/Technique/Operations/Jitsi.md +++ b/src/Technique/Operations/Jitsi.md @@ -33,7 +33,7 @@ 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) + - Adrien avait sa Livebox avec pare-feu configuré en mode "élevé" et a dû 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 : @@ -50,7 +50,7 @@ Les utilisateurs activant le parefeu en mode élevé devront ajouter une excepti [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) +Ils m'ont pointé entre autres 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 @@ -59,7 +59,7 @@ Apparemment une issue est dédiée en particulier au problème que nous rencontr * [#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). + 2. Pour relayer la vidéo à travers la plupart des parefeux, notre `videobridge` Jitsi devait écouter sur le port `443/tcp`. Or 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 @@ -89,6 +89,6 @@ WebRTC utilise deux formats de paquets selon [Mozilla Developer Network|RTCDataC - `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. +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. |