diff options
Diffstat (limited to 'src/Technique/Operations/Jitsi.md')
| -rw-r--r-- | src/Technique/Operations/Jitsi.md | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/src/Technique/Operations/Jitsi.md b/src/Technique/Operations/Jitsi.md index 354710e..5f26131 100644 --- a/src/Technique/Operations/Jitsi.md +++ b/src/Technique/Operations/Jitsi.md @@ -13,16 +13,16 @@ Par contre Facebook Messenger impose Google Chrome/Chromium pour les visio de gr 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. +- 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 +1. Mener nos propres tests +2. Chercher d'autres retours #### Mener nos propres tests @@ -31,9 +31,9 @@ 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 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) +- 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 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 : @@ -69,8 +69,8 @@ Apparemment une issue est dédiée en particulier au problème que nous rencontr 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 +- 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 @@ -81,13 +81,13 @@ On peut débugger le signaling WebRTC sous Chromium avec [chrome://webrtc-intern 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. +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` +- `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. |