Test de capacité WebRTC
Exécutez une boucle locale peer‑to‑peer réelle et confirmez que les messages renvoyés sont effectivement reçus — pas de test de fuite.
Boucle locale uniquement — pas de serveur STUN ou TURN
Boucle WebRTC locale
Deux pairs dans cet onglet, 5 messages renvoyés en écho, iceServers : [] — aucun serveur STUN ou TURN contacté
Aucune boucle locale n’a encore été exécutée. Lancer la boucle crée deux connexions pair dans cet onglet, négocie localement et échange 5 messages identifiés afin que chaque réponse puisse être appariée au ping qui l’a produite.
Comment tester
- •Exécutez la boucle : deux pairs sont créés dans cet onglet, négocient localement et échangent cinq messages identifiés que le second pair renvoie en écho.
- •Vérifiez la valeur Echo Replies — seules les réponses uniques et correctement appariées sont comptées. Les doublons et messages non liés sont signalés séparément et ne sont jamais comptés.
- •Comparez Handshake (temps jusqu’à « connected ») avec Echo RTT (la médiane aller‑retour de ces réponses) ; ce sont des mesures distinctes.
Limitations du navigateur
- •Ceci est un test de capacité locale. Ce n’est pas un test de fuite et n’évalue pas le comportement du VPN ou du DNS.
- •Une réussite couvre uniquement ce navigateur : aucun microphone ni caméra n’est capturé, et aucune requête ne quitte la page — ce n’est donc pas une preuve qu’un appel se connecte via Internet.
Conseils de dépannage
- •Les extensions de confidentialité strictes peuvent bloquer les connexions pair à pair ; désactivez‑les pour retester.
À propos du Test de capacité WebRTC
Le Test de capacité WebRTC exécute une véritable boucle locale : deux objets RTCPeerConnection sont créés dans cet onglet avec iceServers défini sur une liste vide, un échange offre/réponse est complété, et le second pair renvoie cinq messages individuellement identifiés. Un essai compte comme un échange de données uniquement lorsque les cinq réponses reviennent appariées au ping qui les a produits.
Parce que le pair destinataire doit être en écoute avant que le canal n'existe, le gestionnaire d'écho est attaché avant le début de la négociation — et parce qu'une réponse n'a de sens que si elle peut être reliée à une requête, chaque message porte son propre identifiant et est chronométré depuis son horodatage d'envoi. Les échos dupliqués et les charges utiles non liées sont comptés et ignorés plutôt que considérés comme un succès, et le temps de poignée de main est rapporté séparément du temps de trajet aller-retour médian.
Conseils pour un résultat fiable
- Exécutez le test dans le navigateur que vous utilisez réellement pour passer des appels — les capacités varient selon les moteurs et les profils.
- Lisez d'abord le graphique Réponses d'écho. Il ne compte que les échos appariés uniques ; si le total est inférieur à cinq, la liste d'étapes explique pourquoi l'échange ne s'est pas terminé.
- Comparez la poignée de main et le RTT d'écho comme des mesures distinctes : une poignée de main rapide avec des aller-retours lents, ou l'inverse, indique des causes différentes.
- Relancez après avoir modifié VPN, pare-feu ou paramètres d'extension, car chacun peut influer sur l'autorisation d'une connexion pair-à-pair.
Problèmes courants et solutions
L'exécution échoue avant l'ouverture de la connexion
Les extensions axées sur la confidentialité et les versions de navigateur durcies désactivent RTCPeerConnection entièrement. Désactivez-les pour ce site et retestez ; si cela échoue toujours, la build du navigateur n'offre pas WebRTC.
La connexion s'ouvre mais l'échange d'échos est incomplet
Un pair connecté avec des échos manquants pointe vers le canal de données plutôt que vers la connexion : un canal bloqué ou bridé peut s'ouvrir puis perdre des messages. Réessayez et vérifiez les extensions qui modifient le contenu des pages ou le réseau.
Les candidats ICE ont été rejetés lors de l'ajout
La liste d'étapes compte les candidats rejetés au lieu de les masquer. Cela indique normalement un décalage entre ce qui a été recueilli et ce que l'autre côté attendait — souvent un proxy ou une extension qui réécrit les candidats.
La boucle locale réussit mais les appels échouent toujours
Le chemin local fonctionne, donc la défaillance se situe ailleurs : filtrage réseau, atteignabilité TURN ou le propre signalement du service. Utilisez le diagnostic réseau de l'application d'appel qui échoue ensuite.
FAQ
Est-ce un test de fuite WebRTC ?
Non — volontairement. Il vérifie uniquement la capacité locale et n'évalue pas le comportement du VPN ou du DNS. Utilisez un test de fuite dédié si c'est votre préoccupation.
Un succès signifie-t-il que mes appels fonctionneront ?
Il élimine une cause d'échec, rien de plus. Un succès montre que ce navigateur peut établir une connexion pair locale et échanger des données ; les appels sur Internet dépendent en plus du chemin réseau, de l'atteignabilité des relais et du service lui-même.
Utilise‑t‑il mon micro ou ma caméra ?
Non. La boucle locale n'ajoute pas de pistes média et ne demande aucune permission. Si vous voulez vérifier la capture, utilisez le Test du microphone ou le Test de la webcam, qui ouvrent effectivement un flux.
Pourquoi les réponses en double ne sont-elles pas comptées ?
Parce qu'une réponse répétée prouve moins qu'une réponse appariée : elle ne montre pas que ce ping spécifique a fait l'aller-retour. Ignorer les doublons maintient l'exactitude du nombre de messages distincts ayant complété l'échange.
Contacte‑t‑il un serveur ?
Non. Les deux pairs sont créés avec une liste iceServers vide, donc aucun serveur STUN ou TURN n'est contacté et aucune adresse n'est envoyée. Seuls des candidats locaux (host) sont recueillis, localement.