Si estás alojado por nosotros, esto ya está preconfigurado en tu sitio. Esta guía es para administradores que alojan Discourse por su cuenta.
Discourse Live utiliza WebRTC para llamadas de voz y vídeo. Se entrega con servidores STUN públicos para ayudar a los participantes a conectar directamente. Los administradores pueden reemplazar esos servidores y añadir TURN para soportar redes donde las conexiones directas fallan.
Para un servidor dedicado a tu comunidad, recomendamos ejecutar coturn como tu servidor STUN y TURN, con autenticación de secreto compartido para TURN. Esto proporciona descubrimiento de dirección pública y una alternativa de reenvío sin distribuir una contraseña TURN permanente ni depender de servidores STUN de terceros.
Esta guía se aplica a las llamadas de igual a igual (peer-to-peer) de Live. Las salas que utilizan LiveKit usan la propia configuración de ICE/TURN de LiveKit en su lugar. Aprende sobre la configuración de LiveKit de Live.
¿Qué hacen STUN y TURN?
- STUN ayuda al navegador a descubrir su dirección IP pública y puerto para que pueda intentar una conexión directa.
- TURN reenvía los medios cuando no se puede establecer una conexión directa.
Un navegador que conoce su dirección pública puede ofrecerla como un candidato reflexivo de servidor (srflx), lo que hace posibles las conexiones directas a través de NAT de casa y oficina. Sin uno, la mayoría de las llamadas recurren al reenvío TURN, añadiendo latencia y ancho de banda de reenvío.
STUN debe permanecer abierto incluso cuando ejecutes TURN. La respuesta de asignación de TURN también contiene la dirección pública del navegador, pero solo algunos navegadores (como Firefox) la usan como candidato. Los navegadores basados en Chromium y Safari solo descubren su dirección pública mediante una solicitud Binding de STUN separada, y los navegadores nunca adjuntan credenciales a las solicitudes Binding. Si el servidor deshabilita STUN (no-stun) o requiere autenticación para él (secure-stun), esos navegadores no obtienen ningún candidato srflx y todas las llamadas a las que se unen se reenvían.
Con TURN configurado con secreto compartido, Live permite conexiones directas y reenviadas. Configurar TURN no fuerza todas las llamadas a través del reenvío. Configuración de ICE de Live.
1. Prepara un servidor TURN
Puedes usar un servicio TURN gestionado que soporte autenticación de secreto compartido de la API REST de TURN, o ejecutar coturn tú mismo.
Para una configuración autoalojada, prepara:
- Un servidor con una dirección IP pública y ancho de banda suficiente para llamadas reenviadas.
- Un nombre de host como
turn.example.com, apuntando directamente a ese servidor. - Acceso por firewall para su oyente TURN y el rango de puertos de reenvío UDP.
- Un certificado válido si ofreces TURN sobre TLS.
Los navegadores de los participantes se conectan a TURN directamente. Un proxy inverso HTTP estándar o un proxy CDN no puede transportar tráfico TURN.
Ejemplo de configuración de coturn
Genera un secreto aleatorio:
openssl rand -hex 32
Mantén el resultado en privado. Ingresarás el mismo valor en coturn y Discourse.
En un servidor con una IP pública asignada directamente, usa lo siguiente como punto de partida en /etc/turnserver.conf:
listening-port=3478
fingerprint
realm=turn.example.com
use-auth-secret
static-auth-secret=REEMPLAZA_CON_TU_SECRETO_ALEATORIO
# No agregues no-stun o secure-stun: los navegadores envían solicitudes Binding de STUN
# sin credenciales, y muchos dependen de ellas para descubrir su dirección pública.
min-port=49152
max-port=65535
no-multicast-peers
# Este ejemplo comienza sin TLS.
no-tls
no-dtls
Reemplaza el nombre de host y el secreto, protege el archivo de configuración y reinicia coturn. Elimina cualquier configuración no-auth conflictiva o user= estática. El modo de secreto compartido de Coturn habilita el mecanismo de autenticación que necesita internamente. Referencia de configuración de Coturn.
El STUN anónimo solo informa la dirección del propio cliente de vuelta a él; no puede reenviar tráfico, por lo que no convierte tu servidor en un reenvío abierto. Las versiones recientes de coturn mantienen las atributos opcionales de RFC 5780 y MAPPED-ADDRESS desactivados por defecto, lo que mantiene las respuestas Binding cerca del tamaño de la solicitud y limita su utilidad para ataques de reflexión. Deja rfc5780 y stun-backward-compatibility deshabilitados.
Permite tráfico entrante a:
| Puerto | Protocolo | Propósito |
|---|---|---|
3478 |
UDP | STUN y TURN |
3478 |
TCP | TURN |
49152–65535 |
UDP | Medios reenviados |
Permite también el tráfico saliente correspondiente. El rango de reenvío debe coincidir con min-port y max-port.
Si el servidor está detrás de NAT, configura el mapeo external-ip=IP_PÚBLICA/IP_PRIVADA de coturn y reenvía los puertos de escucha y reenvío. Los puertos de reenvío deben retener sus números de puerto a través de NAT. Opciones de despliegue de Coturn.
Añade TLS para redes restrictivas
TURN sobre TLS proporciona otra opción de conexión para participantes cuyas redes bloquean UDP.
Elimina no-tls y configura:
tls-listening-port=5349
cert=/ruta/a/fullchain.pem
pkey=/ruta/a/privkey.pem
Abre 5349/TCP, asegúrate de que coturn pueda leer el certificado y la clave, y reinícialo después de las renovaciones de certificados.
Puedes usar 443/TCP en su lugar si ese puerto está disponible en el servidor TURN. Esto puede ayudar en redes restrictivas, aunque algunas redes también inspeccionan y bloquean tráfico no HTTP en el puerto 443. El rango de reenvío UDP sigue siendo requerido cuando los navegadores llegan a TURN sobre TCP o TLS. Documentación del servidor Coturn.
2. Configura Discourse
En Administración → Ajustes, busca estos ajustes de Live:
| Ajuste | Valor |
|---|---|
live_stun_servers |
La URI STUN de tu servidor coturn — reemplaza las entradas por defecto |
live_turn_secret |
El valor usado para static-auth-secret de coturn |
live_turn_secret_servers |
Tus URIs TURN, separados por | |
live_turn_servers |
Vacío |
live_turn_username |
Vacío |
live_turn_credential |
Vacío |
Para la configuración anterior, ingresa esto en live_stun_servers:
stun:turn.example.com:3478
Y esto en live_turn_secret_servers:
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp
Si habilitaste TLS, añade su endpoint:
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp|turns:turn.example.com:5349?transport=tcp
Usa URIs stun:, turn: y turns:, sin //. Lista solo endpoints que tu servidor realmente soporta.
Los navegadores basados en Chromium también envían solicitudes STUN a los servidores TURN que listes, por lo que un live_stun_servers vacío puede funcionar siempre que coturn responda a STUN anónimo. Listar la URI STUN explícitamente hace la configuración más clara, cubre otros navegadores y permite que los diagnósticos de conexión de Live lo prueben por sí solos.
La lista live_turn_secret_servers usa credenciales generadas desde el secreto compartido. La lista separada live_turn_servers usa un nombre de usuario y contraseña fijos. Definiciones de ajustes de Live.
Guarda los ajustes, luego haz que los participantes salgan y vuelvan a unirse a las llamadas para obtener la nueva configuración.
3. Verifica la configuración
Prueba con dos participantes en diferentes redes, como banda ancha doméstica y datos móviles, y en más de un navegador — al menos un navegador basado en Chromium y Firefox. Confirma que el audio funciona en ambas direcciones, luego prueba el vídeo y el compartir pantalla.
Mientras estés en una sala de igual a igual, abre el menú ⋮ de la sala y elige Diagnósticos de conexión:
- En Servidores STUN/TURN, cada servidor debería mostrar Alcanzable. Los servidores TURN deberían listar una Dirección de reenvío, y los servidores UDP deberían listar una Dirección pública. “Dirección pública: Ninguna” significa que las solicitudes STUN no obtuvieron respuesta — revisa por
no-stun/secure-stuny que3478/UDPesté abierto. - En Pares, la ruta muestra cómo cada conexión transporta medios: Directo (misma red), Directo (a través de NAT mediante STUN), o Reenviado a través de TURN. La mayoría de los participantes en redes domésticas normales deberían conectar directamente.
- Copiar informe produce un informe de texto que puedes compartir con quien esté solucionando problemas. Incluye las direcciones IP de los participantes, así que compártelo privadamente.
En navegadores Chromium, chrome://webrtc-internals muestra los mismos detalles a un nivel más bajo:
- Un candidato
srflxrepresenta una dirección pública descubierta. - Un candidato
relayrepresenta un reenvío TURN disponible. - El par de candidatos seleccionado muestra la conexión que realmente transporta medios.
Una llamada directa exitosa no prueba que el reenvío funcione. También prueba desde una red que requiera TURN, o usa un cliente de prueba WebRTC con iceTransportPolicy: "relay" y credenciales temporales.
Revisa los registros de coturn para asignaciones autenticadas exitosas. Las solicitudes sin credenciales válidas no deben obtener una asignación de reenvío. Un desafío de autenticación inicial 401 es normal; los fallos repetidos de autenticación necesitan investigación.
Mantén el servidor dedicado a tu comunidad
El secreto compartido permanece en Discourse y el servidor TURN. Los participantes reciben credenciales temporales en su lugar. Live actualmente genera credenciales válidas para crear asignaciones durante 12 horas; una asignación establecida puede continuar mientras se actualiza. Generación de credenciales de Live.
Esto previene un reenvío abierto anónimo, pero las credenciales TURN no están vinculadas a un origen de navegador: un participante puede copiar y reutilizar sus credenciales temporales. Para limitar el abuso:
- Restringe el acceso de Live a los grupos pretendidos.
- Monitorea el ancho de banda de reenvío y los recuentos de asignaciones.
- Establece cuotas de asignación de coturn y límites de ancho de banda apropiados para tu comunidad.
- Bloquea el acceso de reenvío a destinos privados, de enlace local y otros internos accesibles desde el host TURN.
- Mantén coturn actualizado y rota el secreto compartido si se expone.
Usa un secreto dedicado para este despliegue de Discourse. Tu servidor también responderá solicitudes STUN anónimas de cualquier persona; esto es esperado, usa poco ancho de banda y no concede acceso de reenvío. Autenticación y controles de acceso de Coturn.
Alternativas
Reemplaza solo los servidores STUN públicos
Establece live_stun_servers a tus propias URIs STUN, separadas por |:
stun:stun.example.com:3478
Deja los ajustes TURN vacíos si no necesitas un reenvío. STUN solo no puede hacer que las llamadas funcionen en todas las redes.
Usa TURN con un nombre de usuario y contraseña fijos
Si tu proveedor no soporta autenticación de secreto compartido, configura live_turn_servers, live_turn_username, y live_turn_credential. Deja los ajustes de secreto compartido vacíos.
Los participantes reciben esas credenciales fijas, lo que hace que sea más fácil reutilizarlas fuera de tu sitio. Además, Live actualmente fuerza conexiones de reenvío cuando se configuran servidores TURN estáticos y la lista STUN está vacía. Prefiere la autenticación de secreto compartido cuando tu proveedor la soporta. Configuración de ICE de Live.