boris/site
1
0
Fork 0
forked from Deuxfleurs/site
Code Pull requests Activity

Réécriture

Browse source
This commit is contained in:
Quentin 2020-04-04 12:37:41 +02:00
parent 7f6727dca0
commit 0e0a2645a8
1 changed files with 8 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
src/Documentation/Technique/Services/Jitsi/index.md
View file

@ -64,7 +64,7 @@ Apparemment une issue est dédiée en particulier au problème que nous rencontr
* Avoir un cluster géo-distribué avec plusieurs IPv4 pourrait également résoudre le problème * 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 * 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 ### À propos du control/data plane de Jitsi
Notre videobridge écoute donc sur les ports `8080/tcp` et `10000/udp`. Notre videobridge écoute donc sur les ports `8080/tcp` et `10000/udp`.
@ -72,14 +72,18 @@ WebRTC fonctionne en deux étapes :
- Des offres doivent être échangées via un serveur de signaling quelconque - 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 - 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 control plane de Jitsi : Prosody sur HTTPS via Bosh/XMPP
Le serveur de signaling Jitsi n'est autre que le serveur de chat prosody. 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). 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`. 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/). On peut débugger le signaling WebRTC sous Chromium avec [chrome://webrtc-internarls](chrome://webrtc-internals/).
#### Le protocole WebRTC 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) : 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` - `UDP/DTLS/SCTP`