Prueba de capacidad WebRTC
Ejecute un bucle local peer-to-peer real y confirme que los mensajes eco regresen realmente — sin pruebas de fuga.
Solo bucle local — sin servidor STUN ni TURN
Bucle WebRTC local
Dos pares en esta pestaña, 5 mensajes devueltos, iceServers: [] — no se contactó ningún servidor STUN o TURN
Aún no se ha ejecutado ningún bucle. Ejecutarlo crea dos conexiones entre pares en esta pestaña, negocia localmente e intercambia 5 mensajes identificados para que cada respuesta pueda emparejarse con el ping que la originó.
Cómo probar
- •Ejecute el bucle: se crean dos pares en esta pestaña, negocian localmente e intercambian cinco mensajes identificados que el segundo par devuelve en eco.
- •Consulte la cifra de Respuestas Eco — solo cuentan las respuestas únicas y correctamente emparejadas. Duplicados y mensajes no relacionados se informan por separado y nunca se cuentan.
- •Compare Handshake (tiempo hasta "conectado") con Echo RTT (la mediana de ida y vuelta de esas respuestas); son mediciones separadas.
Limitaciones del navegador
- •Esta es una prueba de capacidad local. No es una prueba de fuga y no evalúa el comportamiento de VPN o DNS.
- •Un aprobado cubre solo este navegador: no se captura micrófono ni cámara, y ninguna solicitud sale de la página — por tanto no es evidencia de que una llamada se conecte a través de internet.
Consejos de solución de problemas
- •Extensiones de privacidad estrictas pueden bloquear conexiones entre pares; desactívelas para volver a probar.
Sobre el Prueba de capacidad WebRTC
El Prueba de capacidad WebRTC ejecuta un bucle local genuino: se crean dos objetos RTCPeerConnection dentro de esta pestaña con iceServers establecido en una lista vacía, se realiza un intercambio offer/answer y el segundo par devuelve cinco mensajes identificados individualmente. Una ejecución cuenta como intercambio de datos solo cuando las cinco respuestas regresan emparejadas con el ping que las generó.
Porque el par receptor debe estar escuchando antes de que exista el canal, el manejador de eco se adjunta antes de iniciar la negociación — y como una respuesta solo tiene sentido si puede vincularse a una solicitud, cada mensaje lleva su propio identificador y se cronometra desde su propia marca de tiempo de envío. Los ecos duplicados y las cargas útiles no relacionadas se cuentan y se ignoran en lugar de ser considerados un éxito, y el tiempo de establecimiento se informa por separado del tiempo medio de ida y vuelta.
Consejos para un resultado fiable
- Ejecute la comprobación en el navegador desde el que realmente realiza llamadas — la capacidad varía entre motores y perfiles.
- Lea primero la figura Respuestas de Eco. Cuenta únicamente ecos coincidentes únicos; si está por debajo de cinco, la lista de pasos explica por qué el intercambio no se completó.
- Compare el Tiempo de Puesta de Mano con el RTT de Eco como medidas separadas: un establecimiento rápido con tiempos de ida y vuelta lentos, o a la inversa, apunta a causas diferentes.
- Vuelva a ejecutar después de cambiar la configuración de VPN, cortafuegos o extensiones, ya que cada uno puede afectar si se permite o no una conexión entre pares.
Problemas comunes y soluciones
La ejecución falla antes de que la conexión se abra
Las extensiones centradas en privacidad y las compilaciones de navegador endurecidas desactivan RTCPeerConnection por completo. Desactívelas para este sitio y vuelva a probar; si aún falla, la compilación del navegador no ofrece WebRTC.
La conexión se abre pero el intercambio de ecos está incompleto
Un par conectado con ecos faltantes apunta al canal de datos en lugar de a la conexión: un canal bloqueado o estrangulado puede abrirse y luego perder mensajes. Vuelva a intentarlo y revise las extensiones que modifican el contenido de la página o la red.
Se rechazaron candidatos ICE al agregarlos
La lista de pasos cuenta los candidatos rechazados en lugar de ocultarlos. Eso normalmente indica una discordancia entre lo que se recopiló y lo que el extremo remoto esperaba — a menudo un proxy o una extensión que reescribe los candidatos.
El bucle local funciona pero las llamadas siguen fallando
La ruta local funciona, por lo que la falla está en otro lado: filtrado de red, accesibilidad a TURN o el propio señalizador del servicio. Use las herramientas de diagnóstico de red de la aplicación de llamadas que falla a continuación.
FAQ
¿Esto es una prueba de fuga de WebRTC?
No — por diseño. Comprueba únicamente la capacidad local y no evalúa el comportamiento de la VPN o DNS. Use una prueba de fugas dedicada si esa es su pregunta.
¿Un aprobado significa que mis llamadas funcionarán?
Elimina una causa de fallo y nada más. Un aprobado muestra que este navegador puede crear una conexión local entre pares e intercambiar datos; las llamadas por Internet dependen además de la ruta de red, la accesibilidad de relés y del propio servicio.
¿Usa mi micrófono o cámara?
No. El bucle local no añade pistas multimedia ni solicita permisos. Si desea saber si la captura funciona, use la Prueba de Micrófono o la Prueba de Webcam, que sí abren una transmisión.
¿Por qué no se cuentan las respuestas duplicadas?
Porque una respuesta repetida demuestra menos que una coincidencia única: no demuestra que este ping específico hizo el ida y vuelta. Ignorar duplicados mantiene honesta la cifra sobre cuántos mensajes distintos completaron el intercambio.
¿Contacta con algún servidor?
No. Ambos pares se crean con una lista iceServers vacía, por lo que no se contacta ningún servidor STUN o TURN y no se envía ninguna dirección. Solo se recopilan candidatos host, localmente.