Los problemas con las llamadas de Nextcloud Talk suelen describirse como "mala calidad de vídeo", pero las causas subyacentes no son siempre las mismas. Un usuario puede tener suficiente ancho de banda y aun así no poder conectarse porque un cortafuegos bloquea el tráfico WebRTC punto a punto. Otra llamada puede conectarse correctamente a través de TURN, pero percibirse como más lenta debido a la transmisión de todo el contenido multimedia. Una reunión numerosa puede presentar problemas incluso con un servidor TURN que funcione a la perfección, ya que la implementación sigue utilizando la topología punto a punto integrada en lugar del backend de alto rendimiento.
Por lo tanto, el enfoque más útil para la resolución de problemas consiste en separar la conectividad , la ruta de medios y la escalabilidad . A fecha de 6 de octubre de 2026, la documentación oficial de Nextcloud Talk sigue describiendo TURN como la alternativa cuando no es posible la conectividad WebRTC directa y recomienda el puerto 443 para una compatibilidad máxima. También indica que puede ser necesario un servidor TURN cuando se utiliza el backend de alto rendimiento. Consulte la documentación oficial de Nextcloud Talk TURN y la guía oficial de configuración de coturn para Talk .
Utilice el patrón de síntomas para elegir la siguiente acción en lugar de cambiar varias configuraciones a la vez.
| Síntoma | Área más probable | Primera acción | Compensación |
|---|---|---|---|
| La llamada funciona en una red, pero falla desde una red corporativa o de hotel. | Cortafuegos, NAT o fallo de TURN faltante | Verificar TURN sobre UDP/TCP y, donde sea necesario, TLS en el puerto 443. | El reenvío mejora la accesibilidad, pero consume ancho de banda TURN y puede aumentar la latencia. |
| Las llamadas entre dos personas funcionan bien, pero las llamadas con más personas se vuelven inestables. | Topología de llamadas y carga del cliente/carga de CPU | Evaluar el backend de alto rendimiento de Nextcloud Talk | Más infraestructura, pero mejor escalabilidad para llamadas con múltiples participantes. |
| El vídeo se conecta, pero se ve pixelado o se congela. | Pérdida de paquetes, latencia, Wi-Fi, capacidad de enlace ascendente o sobrecarga de los puntos finales. | Pruebe desde una red cableada o que funcione correctamente antes de cambiar TURN. | TURN no puede crear ancho de banda que no esté disponible. |
| La prueba TURN falla aunque coturn se está ejecutando. | Desajuste de clave secreta, cortafuegos, asignación NAT, DNS o puertos de retransmisión | Verifique las credenciales, la asignación de IP pública y el rango de retransmisión. | Abrir un amplio rango de relés es más sencillo; reducirlo disminuye los puertos expuestos, pero requiere una planificación de capacidad deliberada. |
Comience con dos pruebas breves. Primero, realice una llamada entre dos clientes en redes sencillas, como dos conexiones de banda ancha normales. Luego, repita la prueba desde una red con restricciones, como una red Wi-Fi corporativa, una VPN o un punto de acceso móvil. Si solo falla la red con restricciones, TURN es un fuerte sospechoso. Si ambas llamadas se conectan, pero la calidad del video es deficiente, recopile información sobre la red y los dispositivos antes de modificar la arquitectura de retransmisión.
La secuencia de conexión documentada de Nextcloud intenta primero la conectividad directa entre pares, utiliza STUN para descubrir direcciones accesibles y recurre a TURN cuando no se puede establecer una ruta directa. Esto significa que TURN es principalmente una alternativa de conectividad , no un optimizador universal de la calidad de vídeo. Una ruta retransmitida puede ser más fiable, pero también es más larga y transfiere el ancho de banda multimedia al servidor TURN.
Para implementaciones autoalojadas, coturn es la implementación de TURN más común documentada por Nextcloud. Nextcloud recomienda la autenticación con clave compartida para esta integración. Genere una clave secreta aleatoria segura y utilice el mismo valor tanto en coturn como en la configuración de administración de Talk.
openssl rand -hex 32Una configuración mínima normalmente incluye un puerto de escucha, huella digital, autenticación con clave compartida, un dominio y restricciones de pares. La ubicación exacta del archivo depende de su sistema operativo y paquete. Una configuración representativa es:
listening-port=443
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_RANDOM_SECRET
realm=turn.example.com
total-quota=0
bps-capacity=0
stale-nonce
no-multicast-peersLas versiones anteriores de coturn pueden requerir opciones que las versiones más recientes ya no necesitan, así que no copie una configuración antigua sin más. El documento actualizado de Nextcloud coturn indica explícitamente las directivas que dependen de la versión. Compruebe la versión de coturn instalada con las instrucciones actuales de Nextcloud coturn .
Si coturn está detrás de NAT, configure correctamente su asignación de direcciones públicas a privadas. La propia documentación de configuración de coturn explica la external-ipasignación y exige que los puertos de retransmisión se asignen de forma consistente a través de NAT. Consulte el ejemplo de configuración de coturn en la fuente original .
Para la transmisión de contenido multimedia en tiempo real, UDP suele ser el protocolo de transporte preferido, ya que evita la retransmisión TCP y el bloqueo de cabecera de cola. Sin embargo, algunas redes corporativas y de invitados bloquean UDP por completo. TCP o TURN sobre TLS pueden ofrecer una alternativa viable en redes que solo permiten tráfico web.
Para una máxima accesibilidad, Nextcloud recomienda escuchar en el puerto 443 y admite TURN/TLS. El uso de ambos turn:mejora turns:la compatibilidad, pero también implica la gestión de certificados y rutas de transporte adicionales. Si todos los usuarios se encuentran en redes controladas donde se sabe que UDP funciona, un diseño más sencillo que priorice UDP puede ser más fácil de operar. Si los usuarios se conectan habitualmente desde hoteles, instalaciones de clientes, oficinas con acceso restringido o VPN, la configuración adicional suele justificar el uso de TCP/TLS como alternativa.
Un error común es abrir únicamente el puerto de escucha de TURN. El cliente primero se comunica con coturn a través de su servidor de escucha, pero coturn también asigna puntos finales de retransmisión para el tráfico multimedia. La configuración predeterminada de coturn para el tráfico ascendente utiliza puertos UDP 49152-65535para la asignación de retransmisión. Si este rango está bloqueado por el firewall del host, el grupo de seguridad en la nube, el enrutador ascendente o el dispositivo NAT, la autenticación puede ser exitosa, pero el tráfico multimedia sigue fallando.
Puedes mantener el rango de relés predeterminado o reducirlo deliberadamente con min-porty max-port. La disyuntiva es clara: un rango amplio es operativamente sencillo y ofrece mucha capacidad de asignación; un rango estrecho es más fácil de describir en la política del firewall, pero puede convertirse en un cuello de botella de capacidad si demasiados relés simultáneos necesitan puertos. Dimensiona un rango reducido a partir de la concurrencia esperada en lugar de elegir un número pequeño arbitrario.
Si el host TURN tiene una dirección privada detrás de un enrutador, conserve la asignación de puertos uno a uno para el rango de retransmisión seleccionado y configure la asignación de direcciones públicas en coturn. Si el host tiene una IP pública directamente en su interfaz, el paso de asignación NAT es innecesario.
Abra el área de administración de Nextcloud y vaya a la configuración de Talk. Agregue el servidor TURN usando el host y el puerto directamente, no una http://URL https://. La documentación actual de Talk de Nextcloud indica que el esquema TURN se selecciona por separado, por lo que el campo del servidor debe tener el formato turn.example.com:443.
Introduzca la misma clave compartida configurada en coturn y habilite los protocolos que su servidor acepta. Si utiliza TLS, seleccione el esquema TURN correspondiente y asegúrese de que el certificado coincida con el nombre de host TURN. También puede usar su propio servicio TURN como servidor STUN, lo que simplifica la administración del host, aunque mantener STUN y TURN separados puede ser útil cuando se requieren dominios de fallo independientes o repetidores distribuidos geográficamente.
No revele la clave secreta compartida en capturas de pantalla, tickets ni ejemplos de configuración públicos. Nextcloud la utiliza para obtener credenciales TURN temporales para los clientes.
Tras guardar la configuración de Talk, utilice la comprobación administrativa que verifica si el servidor TURN devuelve candidatos ICE utilizables. Un resultado satisfactorio demuestra que el navegador pudo obtener candidatos que funcionan correctamente del servicio TURN configurado. Esto no garantiza que todas las redes de usuarios, todas las rutas de retransmisión y todas las llamadas de gran tamaño funcionen correctamente.
Repita una llamada real desde al menos una red con restricciones. Esto es importante porque una verificación del servidor puede ser exitosa mientras que la red del usuario aún bloquea UDP, la resolución DNS o un protocolo de transporte específico. Si UDP falla, pero TCP/TLS en el puerto 443 funciona, mantenga la ruta alternativa. Si todas las rutas fallan, revise los registros del firewall, los registros de coturn, el DNS, la validez del certificado, la clave compartida y la asignación NAT.
TURN y el backend de alto rendimiento resuelven problemas diferentes. TURN reenvía el tráfico cuando los clientes no pueden establecer la ruta WebRTC necesaria. El backend de alto rendimiento modifica la forma en que se gestionan los medios multiparticipantes, de modo que cada participante no tenga que subir una transmisión independiente a todos los demás.
La interfaz Talk de Nextcloud advierte que ejecutarlo sin el backend de alto rendimiento está pensado únicamente para llamadas muy pequeñas, generalmente descritas en el proyecto como de dos o tres participantes. Si el problema solo aparece al aumentar el número de participantes, añadir TURN puede permitir la conexión de más clientes, pero no eliminará la carga de subida peer-to-peer ni el consumo de CPU. Consulte los requisitos del sistema de Nextcloud Talk y la guía del proyecto sobre el backend de alto rendimiento antes de aumentar el número de llamadas grupales.
Incluso con el backend de alto rendimiento, mantenga TURN disponible cuando los usuarios se conecten desde redes con restricciones. Nextcloud documenta un rango de medios WebRTC predeterminado 20000-40000para el backend y señala específicamente que un cliente limitado al puerto 443 aún podría requerir TURN para reenviar paquetes a ese rango del backend.
| Opción | Ventajas | Costos y límites | Mejor ajuste |
|---|---|---|---|
| Co-retorno autogestionado | Control total, ruta de datos bajo su administración, configuración predecible. | Usted gestiona certificados, actualizaciones, monitoreo, ancho de banda, política de firewall y capacidad geográfica. | Organizaciones con habilidades de infraestructura o requisitos de control estrictos |
| Turno gestionado | Menor esfuerzo operativo y cobertura geográfica potencialmente más sencilla. | El costo del servicio continuo y los medios pueden transitar por un proveedor de retransmisión de terceros. | Equipos que priorizan la simplicidad operativa y el alcance multirregional. |
| No girar | Menor coste de servidor y ruta más corta cuando WebRTC directo siempre funciona. | Las llamadas pueden fallar en NAT simétricas y cortafuegos restrictivos. | Entornos controlados donde las redes de los clientes son conocidas y han sido probadas. |
min-portactual max-port.Si Nextcloud Talk funciona en algunas redes pero no en otras, configure un servicio TURN accesible correctamente y verifique el oyente, la clave compartida, la asignación NAT y los puertos de retransmisión. Si las llamadas se conectan pero la calidad es deficiente, primero mida la carga de la red del cliente y del punto final, ya que TURN puede aumentar la latencia en lugar de eliminarla. Si el problema se agrava con el número de participantes, la solución arquitectónica más adecuada suele ser el backend de alto rendimiento, manteniendo TURN como vía de compatibilidad para redes restringidas.
Configure Z-Push con Kopano para la sincronización segura de correo electrónico, contactos, calendario y tareas mediante ActiveSync. Compare las opciones de backend e implementación y, a continuación, verifique la configuración móvil.
Solucione los problemas de desconexión de Jitsi Meet con una lista de verificación práctica para navegadores, dispositivos móviles, redes inestables, cortafuegos y servidores autogestionados.
Solucione los problemas de calidad de las llamadas de Nextcloud Talk, configure coturn, abra los puertos correctos, pruebe los candidatos ICE y decida cuándo TURN o HPB es la solución adecuada.
Implementa Element Web en Nginx con un servidor principal personalizado, HTTPS, almacenamiento en caché y encabezados de seguridad, además de comprobaciones sencillas para detectar problemas de configuración comunes.
Solucione el error de presentación "Tipo de archivo no compatible" de BigBlueButton comprobando la extensión del archivo, exportando un PDF real, probando con otro archivo e identificando cuándo debe ponerse en contacto con un administrador.
Solucione los errores de Matrix Synapse "Demasiados archivos abiertos" comprobando el límite del servicio, aplicando una modificación de systemd y verificando el proceso en ejecución.
Configura la búsqueda de texto completo de Nextcloud con Elasticsearch 8, instala las aplicaciones necesarias, configura el índice, ejecuta el primer rastreo y verifica los resultados de la búsqueda.
Crea un bot de Matrix con Python y Simple-Matrix-Bot-Lib, compara las opciones de autenticación y despliegue, prueba los comandos y comprende cuándo usar matrix-nio en su lugar.
Instala Jitsi Meet en Ubuntu 24.04 con DNS, reglas de firewall, repositorios oficiales, SSL de Let's Encrypt, comprobaciones de servicio y solución de problemas de NAT.
Solucione los errores de certificado de sincronización de ownCloud Desktop comprobando la URL del servidor, el nombre y la cadena del certificado, la hora del sistema, la versión del cliente y el almacén de CA de confianza.
