tixie/deuxfleurs-website
1
0
Fork 0
forked from Deuxfleurs/site
Code Pull requests Activity

Mise à jour de la page

Browse source
This commit is contained in:
Quentin 2020-04-04 12:32:20 +02:00
parent 7b9cd66237
commit 7f6727dca0
2 changed files with 144 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

118
src/Documentation/Technique/Services/Jitsi/exemple_offre.txt Normal file
View file

@ -0,0 +1,118 @@
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

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

@ -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). 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 * 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 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.