Stabilit=c3=a9 de jitsi (d=c3=a9bit utile)

Le
BERTRAND Jo=c3=abl
Bonsoir à tous,

Toujours dans mes problèmes d'installation de jitsi, j'observe des
déconnexions répétées et des taux de paquets perdus assez importants,
même dans la résolution la plus basse.

Configuration :
- serveur (i7, 16 Go de mémoire), debian testing ;
- une connexion VDSL2 (6Mbps en sortie) ;
- deux utilisateurs max côté WAN.

Les logs du videobridge sont pleins de choses comme cela :

JVB 2020-04-14 17:56:55.187 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2188,now86879815187,lsr37488650,dlsr2428
JVB 2020-04-14 17:56:55.280 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2192,now86879815280,lsr37488650,dlsr8252
JVB 2020-04-14 17:56:55.342 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrcw5852513 remainingRetries=5
JVB 2020-04-14 17:56:55.355 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2201,now86879815355,lsr37488650,dlsr2573
JVB 2020-04-14 17:56:55.381 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2203,now86879815381,lsr37488650,dlsr4172
JVB 2020-04-14 17:56:55.642 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrcw5852513 remainingRetries=4
JVB 2020-04-14 17:56:55.653 INFOS: [201]
org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair:
192.168.254.1:10000/udp/host -> 192.168.10.103:40804/udp/host
(stream.RTP), failing.
JVB 2020-04-14 17:56:55.780 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2220,now86879815780,lsr37488650,dlsr!9163
JVB 2020-04-14 17:56:55.942 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrcw5852513 remainingRetries=3
JVB 2020-04-14 17:56:55.960 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2218,now86879815960,lsr37488650,dlsr#1134
JVB 2020-04-14 17:56:56.053 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt4499,now86879816053,lsr37571356,dlsrP06
JVB 2020-04-14 17:56:56.187 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt4505,now86879816187,lsr37571356,dlsr414
JVB 2020-04-14 17:56:56.242 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrcw5852513 remainingRetries=2
JVB 2020-04-14 17:56:56.311 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt4502,now86879816311,lsr37571356,dlsr!724
JVB 2020-04-14 17:56:56.311 INFOS: [760]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrc"97576325 remainingRetries=9
JVB 2020-04-14 17:56:56.352 AVERTISSEMENT: [781]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream70417375
ssrcw5852513,rtt2139,now86879816352,lsr37681391,dlsri219
JVB 2020-04-14 17:56:56.528 AVERTISSEMENT: [781]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream70417375
ssrcw5852513,rtt2145,now86879816528,lsr37681391,dlsr374

J'ai dû rajouter une option de conf non documentée :

org.ice4j.ice.harvest.ALLOWED_ADDRESSES2.168.254.1

en plus de

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS2.168.254.1

pour forcer l'écoute sur cette seule adresse (sinon, avec toutes les
interfaces réseau du serveur, c'était la fête !). Il paraît qu'on peut
aussi écrire "ip1;ip2;ip3", mais je n'ai pas réussi à le faire
fonctionner comme ça. Il existe l'option inverse, pour bloquer des
interfaces spécifiques.

Constatations :
- je ne sature _jamais_ la liaison VDSL (le débit max du à jitsi est de
l'ordre de 320 à 350 kbps avec deux connexions côté WAN) ;
- le traffic sur les ports UDP/10000 ne sont que rarement supérieurs à
150kbps ;
- le routage est correct ;
- le serveur fait les pieds au mur (charge inférieure à 1 au moment des
tests) ;
- même le son est totalement moisi (en raison des pertes de paquets).

D'où ma question : pourquoi autant de perte de paquets ? Et pourquoi le
débit n'est pas plus haut ? J'avoue ne plus savoir où chercher.

Pour information, le premier client accède au serveur au travers d'un
VPN (en fait deux VPN/TAP sur UDP, bridgés avec du spanning tree). Ce
VPN fait passer de la VoIP sans aucun problème. Le second client tente
de se connecter directement côté WAN avec une connexion 3G. J'ai aussi
tenté deux clients sur le VPN. Même résultat, les performances sont
catastrophiques.

Je prends toute idée

Bien cordialement,

JKB
Vos réponses
Trier par : date / pertinence
raphael.poitevin
Le #26543321
Pour ma part, ça tourne sur un dual core 2.7gHz, 2go de ram, buster +
LXC derrière une connexion ADSL et je suis plutôt satisfait. Quel ques
bugs, mais ce sont les mêmes rencontrés lorsqu’on utilise framatalk par
exemple. Ça nous arrive d’être trois.
Raphaël
BERTRAND Joël
Bonsoir à tous,
Toujours dans mes problèmes d'installation de jitsi, j'observe des
déconnexions répétées et des taux de paquets perdus a ssez importants,
même dans la résolution la plus basse.
Configuration :
- serveur (i7, 16 Go de mémoire), debian testing ;
- une connexion VDSL2 (6Mbps en sortie) ;
- deux utilisateurs max côté WAN.
Les logs du videobridge sont pleins de choses comme cela :
JVB 2020-04-14 17:56:55.187 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2188,now86879815187,lsr37488650,dlsr 2428
JVB 2020-04-14 17:56:55.280 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2192,now86879815280,lsr37488650,dlsr 8252
JVB 2020-04-14 17:56:55.342 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrcw5852513 remainingRetries=5
JVB 2020-04-14 17:56:55.355 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2201,now86879815355,lsr37488650,dlsr 2573
JVB 2020-04-14 17:56:55.381 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2203,now86879815381,lsr37488650,dlsr 4172
JVB 2020-04-14 17:56:55.642 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrcw5852513 remainingRetries=4
JVB 2020-04-14 17:56:55.653 INFOS: [201]
org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair:
192.168.254.1:10000/udp/host -> 192.168.10.103:40804/udp/host
(stream.RTP), failing.
JVB 2020-04-14 17:56:55.780 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2220,now86879815780,lsr37488650,dlsr !9163
JVB 2020-04-14 17:56:55.942 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrcw5852513 remainingRetries=3
JVB 2020-04-14 17:56:55.960 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt2218,now86879815960,lsr37488650,dlsr #1134
JVB 2020-04-14 17:56:56.053 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt4499,now86879816053,lsr37571356,dlsr P06
JVB 2020-04-14 17:56:56.187 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt4505,now86879816187,lsr37571356,dlsr 414
JVB 2020-04-14 17:56:56.242 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrcw5852513 remainingRetries=2
JVB 2020-04-14 17:56:56.311 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,streamy3021973
ssrc"97576325,rtt4502,now86879816311,lsr37571356,dlsr !724
JVB 2020-04-14 17:56:56.311 INFOS: [760]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrc"97576325 remainingRetries=9
JVB 2020-04-14 17:56:56.352 AVERTISSEMENT: [781]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream70417375
ssrcw5852513,rtt2139,now86879816352,lsr37681391,dlsr= 69219
JVB 2020-04-14 17:56:56.528 AVERTISSEMENT: [781]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream70417375
ssrcw5852513,rtt2145,now86879816528,lsr37681391,dlsr= 80374
J'ai dû rajouter une option de conf non documentée :
org.ice4j.ice.harvest.ALLOWED_ADDRESSES2.168.254.1
en plus de
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS2.168.254.1
pour forcer l'écoute sur cette seule adresse (sinon, avec toutes les
interfaces réseau du serveur, c'était la fête !). Il para ît qu'on peut
aussi écrire "ip1;ip2;ip3", mais je n'ai pas réussi à le f aire
fonctionner comme ça. Il existe l'option inverse, pour bloquer des
interfaces spécifiques.
Constatations :
- je ne sature _jamais_ la liaison VDSL (le débit max du à jits i est de
l'ordre de 320 à 350 kbps avec deux connexions côté WAN) ;
- le traffic sur les ports UDP/10000 ne sont que rarement supérieurs à
150kbps ;
- le routage est correct ;
- le serveur fait les pieds au mur (charge inférieure à 1 au mo ment des
tests) ;
- même le son est totalement moisi (en raison des pertes de paquets).
D'où ma question : pourquoi autant de perte de paquets ? Et pourquo i le
débit n'est pas plus haut ? J'avoue ne plus savoir où chercher.
Pour information, le premier client accède au serveur au travers d' un
VPN (en fait deux VPN/TAP sur UDP, bridgés avec du spanning tree). Ce
VPN fait passer de la VoIP sans aucun problème. Le second client ten te
de se connecter directement côté WAN avec une connexion 3G. J'a i aussi
tenté deux clients sur le VPN. Même résultat, les performa nces sont
catastrophiques.
Je prends toute idée...
Bien cordialement,
JKB
NoSpam
Le #26543346
Essaye avec tes deux clients une conférence sur le site meet.jit.si dans
les mêmes conditions de leur côté que celle de tes tests.
Le 15/04/2020 à 11:50, BERTRAND Joël a écrit :
Raphaël POITEVIN a écrit :
Je ne suis pas assez compétent en réseau pour comprendre tous les
détails. Il est vrai qu’avec mes correspondants, on n’utilise que
l’audio. Est-ce que tu as essayé déjà comme ça pourvoir comment ça se
comporte ?

Même motif, même punition.
Les deux clients sur le LAN, ça fonctionne. Le son est audible. Si j'en
colle un sur le WAN, c'est une catastrophe. La communication s'établit
puis le trafic baisse sur le 10000/UDP (mais uniquement côté WAN). Le
son est inaudible (comme si les paquets UDP arrivaient dans un ordre
totalement aléatoire).
Dès que je mets la vidéo, je me retrouve avec des messages aléatoires :
"a network problème occurred. Reconnecting".
Je n'arrive pas à analyser car pour moi, soit ça passe, soit ça ne
passe pas. Mais je ne vois pas pourquoi une communication s'établirait
pour planter par la suite.
JKB
wanadoo
Le #26543347
Bonjour,
sans information sur la configuration du réseau, vu que tu évoques une
liaison redondée et avec du spanning tree, selon le chemin emprunté, tes
trames udp peuvent effectivement être fortement "dé-triées". As-tu
essayé éventuellement de faire le test avec une seule liaison et en
suspendant le spanning tree ?
Cordialement,
Fernand
Le 15/04/2020 à 11:50, BERTRAND Joël a écrit :
Raphaël POITEVIN a écrit :
Je ne suis pas assez compétent en réseau pour comprendre tous les
détails. Il est vrai qu’avec mes correspondants, on n’utilise que
l’audio. Est-ce que tu as essayé déjà comme ça pourvoir comment ça se
comporte ?

Même motif, même punition.
Les deux clients sur le LAN, ça fonctionne. Le son est audible. Si j'en
colle un sur le WAN, c'est une catastrophe. La communication s'établit
puis le trafic baisse sur le 10000/UDP (mais uniquement côté WAN). Le
son est inaudible (comme si les paquets UDP arrivaient dans un ordre
totalement aléatoire).
Dès que je mets la vidéo, je me retrouve avec des messages aléatoires :
"a network problème occurred. Reconnecting".
Je n'arrive pas à analyser car pour moi, soit ça passe, soit ça ne
passe pas. Mais je ne vois pas pourquoi une communication s'établirait
pour planter par la suite.
JKB
Wallace
Le #26543349
J'allais suggérer la même chose car à mon avis c'est la gigue / latence
qui doit poser problème vu que le serveur est derrière un vdsl.
Déjà que sur des vps la qualité des confs fluctue vraiment en cause la
qualité de la mise à disposition du cpu (fameux % cpu ready de la
virtualisaton adjaçante) cumulé au fait qu'il vaut mieux que le Jitsi
soit directement en public sans NAT pour pouvoir fonctionner
correctement avec tous les navigateurs.
Mes conclusions pour le moment sont : serveur dédié, optimisation kernel
low latency voir quelques brides de RT, ips v4 et v6 publiques et avec
ça on arrive à tenir 50 utilisateurs sur différents salons en même
temps. Les personnes qui se font déconnecter sont plus sur des soucis de
liaisons chez eux ou sur le trajet vers le serveur.
Le 15/04/2020 à 12:35, NoSpam a écrit :
Essaye avec tes deux clients une conférence sur le site meet.jit.si
dans les mêmes conditions de leur côté que celle de tes tests.
Le 15/04/2020 à 11:50, BERTRAND Joël a écrit :
Raphaël POITEVIN a écrit :
Je ne suis pas assez compétent en réseau pour comprendre tous les
détails. Il est vrai qu’avec mes correspondants, on n’utilise que
l’audio. Est-ce que tu as essayé déjà comme ça pourvoir comment ça se
comporte ?

    Même motif, même punition.
    Les deux clients sur le LAN, ça fonctionne. Le son est audible.
Si j'en
colle un sur le WAN, c'est une catastrophe. La communication s'établit
puis le trafic baisse sur le 10000/UDP (mais uniquement côté WAN). Le
son est inaudible (comme si les paquets UDP arrivaient dans un ordre
totalement aléatoire).
    Dès que je mets la vidéo, je me retrouve avec des messages
aléatoires :
"a network problème occurred. Reconnecting".
    Je n'arrive pas à analyser car pour moi, soit ça passe, soit ça ne
passe pas. Mais je ne vois pas pourquoi une communication s'établirait
pour planter par la suite.
    JKB

NoSpam
Le #26543352
Le 15/04/2020 à 13:52, BERTRAND Joël a écrit :
NoSpam a écrit :
Essaye avec tes deux clients une conférence sur le site meet.jit.si dans
les mêmes conditions de leur côté que celle de tes tests.

C'est globalement pire qu'avec mon propre serveur.

Donc pas de problème côté serveur à priori. Je ne vois pas comment
déboguer côté client ...
---
Daniel
Publicité
Poster une réponse
Anonyme