Re: Stabilité de jitsi (débit utile)
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. Quelques
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 <joel.bertrand@systella.fr> writes:
> 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,stream=793021973
> ssrc=2297576325,rtt=32188,now=1586879815187,lsr=1537488650,dlsr=182428
> JVB 2020-04-14 17:56:55.280 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=32192,now=1586879815280,lsr=1537488650,dlsr=188252
> JVB 2020-04-14 17:56:55.342 INFOS: [773]
> org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
> Sending a FIR to ssrc=775852513 remainingRetries=5
> JVB 2020-04-14 17:56:55.355 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=32201,now=1586879815355,lsr=1537488650,dlsr=192573
> JVB 2020-04-14 17:56:55.381 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=32203,now=1586879815381,lsr=1537488650,dlsr=194172
> JVB 2020-04-14 17:56:55.642 INFOS: [773]
> org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
> Sending a FIR to ssrc=775852513 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,stream=793021973
> ssrc=2297576325,rtt=32220,now=1586879815780,lsr=1537488650,dlsr=219163
> JVB 2020-04-14 17:56:55.942 INFOS: [773]
> org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
> Sending a FIR to ssrc=775852513 remainingRetries=3
> JVB 2020-04-14 17:56:55.960 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=32218,now=1586879815960,lsr=1537488650,dlsr=231134
> JVB 2020-04-14 17:56:56.053 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=34499,now=1586879816053,lsr=1537571356,dlsr=5006
> JVB 2020-04-14 17:56:56.187 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=34505,now=1586879816187,lsr=1537571356,dlsr=13414
> JVB 2020-04-14 17:56:56.242 INFOS: [773]
> org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
> Sending a FIR to ssrc=775852513 remainingRetries=2
> JVB 2020-04-14 17:56:56.311 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=34502,now=1586879816311,lsr=1537571356,dlsr=21724
> JVB 2020-04-14 17:56:56.311 INFOS: [760]
> org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
> Sending a FIR to ssrc=2297576325 remainingRetries=9
> JVB 2020-04-14 17:56:56.352 AVERTISSEMENT: [781]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=1070417375
> ssrc=775852513,rtt=32139,now=1586879816352,lsr=1537681391,dlsr=69219
> JVB 2020-04-14 17:56:56.528 AVERTISSEMENT: [781]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=1070417375
> ssrc=775852513,rtt=32145,now=1586879816528,lsr=1537681391,dlsr=80374
>
> J'ai dû rajouter une option de conf non documentée :
>
> org.ice4j.ice.harvest.ALLOWED_ADDRESSES=192.168.254.1
>
> en plus de
>
> org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.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
Reply to: