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 :
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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
raphael.poitevin
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 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 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
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 <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 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 :
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.
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 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 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
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
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.
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
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
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.
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
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
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.
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 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
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 ...
