Inicio
» Cómo
»
Consigue que las llamadas de Nextcloud Talk se realicen cuando falle Direct Media.
Consigue que las llamadas de Nextcloud Talk se realicen cuando falle Direct Media.
Para solucionar un problema con una llamada de Nextcloud Talk que no se conecta o tiene transmisión unidireccional, configure un relé TURN accesible, introduzca su nombre de host, puerto y clave compartida en la configuración de Talk y permita el tráfico tanto a través del receptor TURN como de sus puertos de relé. TURN proporciona a WebRTC una ruta de retransmisión cuando falla una conexión directa; no soluciona problemas de Wi-Fi débil, pérdida de paquetes ni sobrecarga de red.
Ejemplo ilustrativo: Imagine una pequeña organización cuyos empleados pueden unirse a una llamada de Talk desde la oficina, pero no pueden enviar vídeo de forma fiable desde la red de un hotel. El cortafuegos del hotel podría bloquear la conexión directa de los medios. El siguiente ejemplo muestra cómo su administrador comprueba la ruta, configura coTURN y prueba el cambio; no se trata de un informe de una implementación o prueba real.
1. Confirme que un relé es la solución correcta.
Nextcloud Talk intenta conectar a los participantes directamente. STUN ayuda a los dispositivos a descubrir la dirección IP pública y el puerto configurados por el enrutador. Si un cortafuegos o una NAT restrictiva impiden la conexión directa, TURN retransmite el contenido multimedia. Un servidor STUN por sí solo no puede realizar esta retransmisión.
Compara una llamada en la red de la oficina con una desde una red independiente, como un punto de acceso móvil. Si la llamada se conecta en un lugar, pero falla repetidamente al establecer audio o video en la ubicación con restricciones, TURN es una buena opción a seguir. Si la llamada se conecta, pero la imagen sigue borrosa o entrecortada en todas las redes, primero mide el ancho de banda, la pérdida de paquetes, la calidad de Wi-Fi y la carga de la CPU; enrutar más contenido multimedia a través de un repetidor puede aumentar la carga y no generará capacidad.
Ilustración: una página de administrador con campos de configuración y una credencial enmascarada, que representa la configuración que se debe revisar antes de una llamada de prueba.
Registre la versión de Talk, el nombre de host y el puerto de TURN, si el host de TURN está detrás de NAT y si hay un backend de alto rendimiento (HPB) instalado. Mantenga la información confidencial. Los comandos que se muestran a continuación asumen Linux con systemd; las rutas de los paquetes varían.
2. Configure coTURN con autenticación de clave compartida.
La documentación de Nextcloud Talk recomienda coTURN 4.5.0.8 o posterior porque las versiones anteriores tienen un problema con el socket UDP IPv6. Instálelo desde el repositorio de su distribución y localice su archivo de configuración activo (a menudo /etc/turnserver.conf). Genere un secreto aleatorio en el host TURN:
openssl rand -hex 32
Almacene ese valor en un gestor de contraseñas o en un almacén de configuración protegido. En la configuración activa de coTURN, configure el listener, la autenticación de clave compartida y el dominio. Reemplace el nombre de host y la clave de ejemplo con los valores reales:
La documentación de Talk solo incluye lt-cred-mechversiones de coTURN anteriores a la 4.5.0.8; actualice las instalaciones antiguas en lugar de copiar la configuración heredada sin más. Si coTURN está detrás de NAT, configure sus direcciones públicas y de retransmisión según lo indicado en la guía de implementación y asegúrese de que el nombre DNS se resuelva a una dirección accesible para los participantes.
Ilustración: un editor de configuración que representa el oyente coTURN y la configuración de autenticación; utilice los nombres de los parámetros documentados en el texto, no los valores inferidos de la imagen.
3. Abra la ruta del oyente y del repetidor.
Permita el puerto de escucha de TURN (3478 en este ejemplo) a través de los firewalls del host y ascendentes para UDP y TCP. Para TLS, coTURN también necesita un certificado y una clave privada válidos, y Talk debe usar turns:. El puerto 443 puede alcanzar redes más restrictivas, pero verifique si hay conflictos: un HPB también puede necesitar ese puerto, lo que requiere direcciones IP o hosts separados.
Los medios también utilizan puertos de retransmisión. Permita el rango UDP de retransmisión de coTURN en el firewall del host, el grupo de seguridad de la nube y el enrutador. Si configura min-porty max-port, abra ese rango exacto; permitir solo el oyente no es suficiente. Para un host TURN detrás de NAT, reenvíe tanto el rango del oyente como el de retransmisión y configure sus direcciones públicas/de retransmisión. Mantenga las restricciones de pares de coTURN para evitar el acceso a servicios internos no relacionados.
Ilustración: las entradas del firewall representan el tráfico de escucha y de retransmisión que debe permitirse; el rango exacto de puertos depende de la configuración de coTURN.
Reinicie coTURN después de editar y compruebe que el servicio esté activo. Por ejemplo, en un host systemd:
sudo systemctl restart coturn
sudo systemctl status coturn --no-pager
El estado del servicio confirma que el proceso se ha iniciado; no prueba que un navegador remoto pueda acceder al servidor de retransmisión. Compruebe los cortafuegos del host y del proveedor por separado, y revise los registros de coTURN en busca de errores de enlace, fallos de autenticación o mensajes de cuota de asignación.
4. Agrega el servidor en Talk y verifica que se trata de una llamada real.
Como administrador, abra Configuración de administración > Talk . Ingrese el nombre de host y el puerto de TURN, como turn.example.org:3478, y el mismo secreto que static-auth-secret. No incluya https://, turn:, ni turns:en el campo de nombre de host; elija el esquema en los controles de Talk. Mantenga UDP y TCP habilitados cuando sea posible. Use turns:solo después de configurar TLS en coTURN.
Guarda y ejecuta la comprobación TURN integrada de Talk, si está disponible. Luego, llama desde la red con restricciones a una red diferente y verifica el audio y el video bidireccionales. Revisa los registros de coTURN durante la llamada para detectar errores de asignación o autenticación. En el ejemplo, el administrador compara la conexión tipo hotel con la llamada de oficina.
Ilustración: una ventana de llamada para dos personas representa la verificación de extremo a extremo después de guardar la configuración de TURN; confirme que cada participante puede enviar y recibir contenido multimedia.
Si la comprobación falla, compare el nombre de host, el puerto y la clave secreta, y luego verifique el DNS, las reglas del firewall, el rango UDP del relé, el reenvío NAT y los registros de servicio. Una comprobación básica podría pasar por alto un problema en la ruta del relé, así que realice la prueba desde una red externa. Para un diagnóstico exclusivo de TURN, siga el procedimiento específico del navegador de Talk; su método de consola es temporal y el comportamiento del navegador difiere.
TURN no gestiona las llamadas grupales de forma escalable. Nextcloud indica que, para grupos más grandes, las llamadas con más de 5 a 10 usuarios requieren HPB. Si TURN se conecta pero la calidad del vídeo es deficiente, compruebe el ancho de banda, la pérdida de paquetes, las interferencias de Wi-Fi y la carga del servidor antes de modificar las cuotas de retransmisión.
Verificación
La solución se confirma mediante tres señales observables: Talk acepta la configuración TURN, los registros de coTURN muestran asignaciones de retransmisión durante una llamada y los participantes en diferentes redes pueden intercambiar audio y video en ambas direcciones. Si solo funciona la llamada de oficina o los registros no muestran ninguna solicitud entrante, la ruta pública sigue bloqueada o el host y el puerto configurados no coinciden. Si el flujo multimedia persiste, pero la calidad sigue siendo deficiente, la conectividad TURN funciona y es probable que el problema restante se encuentre en otra parte de la red o la infraestructura de llamadas.