Toggle sidebar Toggle sidebar

Visioconférence/Réunion Download Loss:Poor

Status
Not open for further replies.

AGS001

Customer
Joined
Sep 7, 2022
Messages
10
Reaction score
1
Bonjour,

Contexte:
V18 en on Premise , sur VM (Windows), SSD server, 8Go de ram, 4Coeur, FTTO 500Megas, FW Sonicwall.

J'ai constaté que depuis le dernier patch de la V18 Update 9 Final ( Build 31) avoir des pertes de paquets sur le Download d'une visio.
Voici les résultats des nombreux self-tests que nous avons effectué (ils sont toujours identiques)(au besoin, je peux vous fournir les ZIP):

1717161068013.png

1717161187785.png
Les symptômes sont: hachures d'images et décalages de voix. (Je précise qu'une conférence sans image fonctionne parfaitement bien et aucun soucis sur la téléphonie normale)

Coté FW, pendant les tests effectués, je ne suis même pas a 20% de ma fibre. (en temps réel)
Aprés analyse des logs FW, il y avait beaucoup de control UTM sur l'IP 157.230.118.238 (serveur en Allemagne permettant les multiples réunions hébergées apparement..), je l'ai donc exclue de toute analyse… (DPi SSL, IPS, APP Control, Antispyware, Gateway Antivirus, et même Content filter ^^ )

Chose étrange, J'ai pu faire un Self-test sur une connexion 4G en dehors de mon réseau, les perfs sont bonnes.

Questions:
Avez vous constaté le même soucis ces derniers jours?
Mise a part de la Qos que j'ai mis en place sur mon FW et qui n'a pas fonctionné; que me préconisez vous?
Enfin, comment fonctionne réellement les Visio sous 3CX? (de base, je pensais que c'était mon serveur local qui hébergeait cela...?!)

Merci pour vos reponses :)
 
"Les symptômes sont: hachures d'images et décalages de voix."
Click to expand...
Oui, cela résulte certainement de la perte de paquets.

Je l'ai moi-même essayé sur le même serveur et voici le résultat pour votre information.
1717398691955.png

Il est assez rare d'avoir des problèmes de perte de paquets en téléchargement. Cela peut indiquer un itinéraire pas très optimal entre le serveur et votre fournisseur, alors que l'itinéraire entre votre fournisseur et le serveur est correct (un itinéraire différent).

Alternativement, cela peut aussi être un problème avec l'adaptateur réseau de la machine où le test est effectué. Nous avons remarqué que sur des machines utilisant certains adaptateurs wifi, après que la machine soit mise en veille et se réveille, l'adaptateur cesse de fonctionner correctement et toute la machine doit être redémarrée pour retrouver ses performances optimales.

Ce que je peux suggérer ici (et cela peut sembler un cliché) est de redémarrer la machine sur laquelle vous effectuez le test et d'essayer à nouveau. Si la machine a un adaptateur wifi externe, déconnectez-le/reconnectez-le et essayez à nouveau.

Si cela ne donne rien, le problème peut être dû à l'itinéraire mentionné précédemment ou à quelque chose d'autre lié au réseau que nous ne pouvons pas dépanner.

Puis-je vous demander de m'envoyer en message privé le fichier .zip de dépannage exporté du Self-Test pour que nous puissions également y jeter un coup d'œil ?
 
Last edited:
Bonjour,
les machines sur lesquelles ont fait le test sont toutes en RJ45, patchés et redémarrés.
Un changement de Codec pourrait-il ameliorer la done?
Est ce qu'on peut choisir d'autres serveurs dans la region Europe du Webmeeting? (paramètre de conférences)
 
Est-il possible que les paquets UDP entrants soient abandonnés par votre pare-feu ?
 
C'est possible... Quels sont les ports UDP en entrants pour du Web meeting? (ils changent tout le temps non?)
 
Si mon FW abandonnait des paquets, le test 3CX Pare-feu ne fonctionnerait-il pas?
 
Coté wmr, l'adresse a changé, ce n'est plus wmr.3cx.com mais wmr.3cx.net?
 
Non, le vérificateur de pare-feu vérifie la connexion PBX. Dans ce cas, l'utilisateur final doit communiquer avec la plateforme vc

The list of vc servers can be obtained here:
nslookup v18-vc-qos.3cx.net

Vous pouvez également être intéressé par la rubrique "Zero-trust networks" de cet article
 
J'ai suivi votre tuto, tout est ok de mon coté…. (notamment le split dns)
Je viens de refaire un self Test en connexion 4G, ca fonctionne parfaitement bien.
Si je fais une réunion 4G avec une personne de mon entreprise, ca lagg. (Packet loss in download)
Si je fais une réunion 4G avec une personne en 4G, ca fonctionne...
Est ce lié a ma connexion FTTO ou au FW qui abandonne des paquets?

Autre question, est-il normal de voir dans l'onglet Téléphone, Recherche DesktopApp, certains sont avec mon IP publique d'autres en IP privée de mon LAN?
 
Avec 2 utilisateurs, la bande passante requise est d'environ 600 kbps haut/bas.
Si vous n'utilisez pas la vidéo, la bande passante requise est d'environ 32 kbps.
Vous pouvez vérifier si vous rencontrez moins de problèmes en utilisant uniquement l’audio.
Si votre réseau dispose de cette quantité de bande passante disponible, cela ne devrait pas être lié au FTTO.
Avez-vous la possibilité de contourner le pare-feu pour un test ? Pour la deuxième question, il est préférable d'ouvrir un fil de discussion séparé, car il n'est pas lié à vc
 
Ce matin, mes collègues ont essayé une réunion a 8 en coupant tous la caméra, et les symptômes étaient identiques…
Je n'ai pas la possibilité de contourner mon pare-feu…
 
Bonjour,
mon problème est résolu, j'ai augmenté le nombre de paquet UDP/sec sur le FW sur la fonction UDP Flood Protection. (pas sur que ca eu un grand effet…car jamais dépassé en temps réel)
Mon opérateur avait des problèmes de routes réseaux (après ce changement, j'ai gagné 10ms sur un ping google.)
Merci
Cordialement
 
  • Like
Reactions: OlegR_3CX
Hi, good to know.
Is the self test ok now?
 
  • Like
Reactions: OlegR_3CX
Le self Test indique toujours un download Loss: Poor/Acceptable, ce quil ne faut pas tenir compte car nous venons de faire une réunion d'une heure a 12 personnes et tout a bien fonctionné.
La seule chose pertinente dans le self test qu'il faut retenir est s'il affiche des petits panneaux triangulaires Jaunes en bas a droite de chaque écran...
 
Le serveur d'autotest se trouve sur la même zone que le serveur de réunion, vous devriez donc l'atteindre avec les mêmes performances. En termes de quantité de données, l'autotest est conçu pour simuler une réunion réelle avec 16 personnes. C'est étrange que cela ne fonctionne pas correctement dans votre cas
 
Oui... et l'auto test indique 9 fois sur 10 des Loss: Poor sur des visios a 2 et jamais sur du 4 et 16 personnes…..( même en effectuant un test a 2h du matin)
Comme je vous l'ai dit, je n'ai confiance qu'a la notion de panneaux jaunes indiquant eux un vrai problème...
 
Pendant la réunion, vous pouvez voir la perte de liaison descendante dans la colonne > section statistiques. Lorsque vous avez une perte, la plateforme tente de récupérer, mais au-delà d'une certaine limite, la qualité de la conférence s'en ressent. Si vous appuyez sur "Autotest", vous pouvez activer le dépannage. De cette manière, les statistiques de télémétrie sont enregistrées à la fin d'une réunion normale. Vous pourrez l'analyser plus tard ou nous l'envoyer en privé.

Community Verified icon
 
About the yellow triangle, it doesn't appear for downlink loss, because this info is not available per user, and the triangle reports a specific user problem. But it doesn't mean that downlink loss is not present. Check the stats (during a normal meeting) to see this info. If you see downlink loss for the self test, you should see it also during a normal meeting. If you have downlink loss only for the test, it means that you have some issue in reaching the test server, but not the meeting server and we will investigate more in this direction. If you have downlink loss also during normal meetings, it means that you have problems reaching any of our servers and we will go in this direction. Try with at least 2 people in the meeting, more is better
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,973
Messages
590,075
Members
164,895
Latest member
jasonkkrause
3CX Logo Footer Copyright © Sitemap Privacy
Top Bottom