Cómo solucionar una cámara WebRTC en la red local

Los fallos WebRTC pueden parecer bruscos porque ocurren varios pasos antes del primer fotograma. La app obtiene la señalización, reúne candidatos de red, negocia la conexión y arranca un decodificador nativo. La telemetría puede funcionar aunque falle cualquiera de ellos.

Creality K2 y rutas remotas compatibles usan WebRTC en Printer Tools. No se diagnostican como una URL MJPEG simple.

Printer Tools

Todas tus impresoras 3D en un solo panel

Monitoriza impresoras Bambu Lab, Klipper, OctoPrint, Creality, Snapmaker, Anycubic, Flashforge, Elegoo y Prusa desde una sola app

Disponible en Android, iPhone, iPad y Mac, con apps complementarias para Apple Watch y Wear OS y acceso remoto opcional mediante VPN, OctoEverywhere u Obico

Confirma el origen de señalización

Printer Tools debe recibir la oferta, detalles de sesión o endpoint desde la impresora o servicio compatible. No se puede pegar como stream una página web genérica que muestre WebRTC.

Verifica el modelo exacto y usa una versión actual. La detección decide si la app debe intentar WebRTC.

Separa telemetría y negociación de cámara

Si el panel se actualiza pero Live View falla, conserva ese dato. Demuestra parte de la ruta y limita el problema a señalización, candidatos, medios o decodificación.

Si ambos fallan, arregla dirección y ruta antes de interpretar mensajes WebRTC.

Revisa ICE y candidatos de red

En una LAN sencilla, los pares pueden conectar con candidatos locales. VLAN, VPN, varias interfaces y aislamiento pueden generar candidatos inalcanzables o bloquear medios después de una señalización correcta.

Prueba móvil e impresora en la LAN principal. Desactiva solo la VPN conflictiva durante la prueba y diseña después una ruta explícita.

Mantén actualizado el runtime nativo

WebRTC usa bibliotecas nativas. Una build puede compilar y fallar al ejecutar si la optimización eliminó clases o binarios necesarios. Usa la última versión oficial antes de informar de una regresión.

Si la app se cierra al abrir cámara, anota versión y plataforma y exporta el log tras reiniciar. No repitas el cierre mientras haya una acción crítica de impresión.

Interpreta síntomas habituales

un rechazo inmediato apunta a endpoint o servicio no disponible;
conexión infinita apunta a señalización o ICE incompletos;
estado sin vídeo apunta a pista o decodificador;
vídeo que empieza y se congela apunta a pérdida, bitrate o bloqueo del decodificador;
cierre de la app apunta a un fallo nativo que necesita la build exacta.

Evita atajos inseguros

No expongas ampliamente puertos de señalización o medios. Para acceso remoto usa el flujo compatible o VPN. Una regla permisiva puede ocultar el diagnóstico y exponer la cámara.

Para Creality, consulta la guía de cámara WebRTC de K2.

Preguntas frecuentes

¿WebRTC es otra URL de vídeo?

No. Incluye señalización, negociación de candidatos y pistas multimedia.

¿Por qué funcionan los datos y falla WebRTC?

La API y la conexión de cámara usan servicios y flujos distintos.

¿Debo redirigir todos los puertos de candidatos?

No. No abras rangos públicos amplios. Repara la ruta local o usa el método remoto compatible.

¿Qué incluyo en un informe de cierre?

Versión, plataforma, modelo, firmware, acción exacta y un log cifrado nuevo después de reabrir.

Fuentes oficiales: MDN — WebRTC API · RFC 8445 — ICE