Se você estiver hospedado conosco, isso já está pré-configurado no seu site. Este guia é para administradores que hospedam o Discourse por conta própria.
O Discourse Live usa WebRTC para chamadas de voz e vídeo. Ele vem com servidores STUN públicos para ajudar os participantes a se conectarem diretamente. Os administradores podem substituir esses servidores e adicionar TURN para suportar redes onde conexões diretas falham.
Para um servidor dedicado à sua comunidade, recomendamos executar o coturn como seu servidor STUN e TURN, com autenticação de segredo compartilhado para TURN. Isso fornece descoberta de endereço público e um fallback de retransmissão sem distribuir uma senha TURN permanente ou depender de servidores STUN de terceiros.
Este guia se aplica às chamadas peer-to-peer do Live. Salas que usam LiveKit usam a própria configuração ICE/TURN do LiveKit em vez disso. Saiba mais sobre a configuração LiveKit do Live.
O que STUN e TURN fazem?
- STUN ajuda o navegador a descobrir seu endereço IP público e porta para que ele possa tentar uma conexão direta.
- TURN retransmite mídia quando uma conexão direta não pode ser estabelecida.
Um navegador que aprende seu endereço público pode oferecê-lo como um candidato reflexivo do servidor (srflx), o que torna possíveis conexões diretas através de NAT domésticos e de escritório. Sem isso, a maioria das chamadas recorre à retransmissão TURN, adicionando latência e banda de retransmissão.
O STUN deve permanecer aberto mesmo quando você executa o TURN. Uma resposta de alocação TURN também contém o endereço público do navegador, mas apenas alguns navegadores (como o Firefox) o usam como candidato. Navegadores baseados em Chromium e Safari descobrem seu endereço público apenas por meio de uma solicitação STUN Binding separada, e os navegadores nunca anexam credenciais às solicitações Binding. Se o servidor desabilitar o STUN (no-stun) ou exigir autenticação para ele (secure-stun), esses navegadores não obterão um candidato srflx e todas as chamadas nas quais participarem serão retransmitidas.
Com o TURN de segredo compartilhado configurado, o Live permite conexões diretas e retransmitidas. Configurar o TURN não força todas as chamadas a passar pela retransmissão. Configuração ICE do Live.
1. Prepare um servidor TURN
Você pode usar um serviço TURN gerenciado que suporte autenticação de segredo compartilhado TURN REST API, ou executar o coturn você mesmo.
Para uma configuração auto-hospedada, prepare:
- Um servidor com um endereço IP público e largura de banda suficiente para chamadas retransmitidas.
- Um nome de host como
turn.example.com, apontando diretamente para esse servidor. - Acesso de firewall para seu ouvinte TURN e faixa de portas de retransmissão UDP.
- Um certificado válido se você oferecer TURN sobre TLS.
Os navegadores dos participantes se conectam diretamente ao TURN. Um proxy reverso HTTP comum ou proxy CDN não pode transportar tráfego TURN.
Exemplo de configuração coturn
Gere um segredo aleatório:
openssl rand -hex 32
Mantenha o resultado em privado. Você digitará o mesmo valor no coturn e no Discourse.
Em um servidor com um IP público atribuído diretamente, use o seguinte como ponto de partida em /etc/turnserver.conf:
listening-port=3478
fingerprint
realm=turn.example.com
use-auth-secret
static-auth-secret=REPLACE_WITH_YOUR_RANDOM_SECRET
# Não adicione no-stun ou secure-stun: os navegadores enviam solicitações STUN Binding
# sem credenciais, e muitos dependem delas para descobrir seu endereço público.
min-port=49152
max-port=65535
no-multicast-peers
# Este exemplo começa sem TLS.
no-tls
no-dtls
Substitua o nome de host e o segredo, proteja o arquivo de configuração e reinicie o coturn. Remova qualquer configuração no-auth ou user= estática conflitante. O modo de segredo compartilhado do Coturn habilita internamente o mecanismo de autenticação necessário. Referência de configuração Coturn.
O STUN anônimo apenas reporta o endereço do próprio cliente de volta a ele; ele não pode retransmitir tráfego, portanto, não transforma seu servidor em um retransmissor aberto. Versões recentes do coturn mantêm os atributos opcionais de resposta MAPPED-ADDRESS e RFC 5780 desativados por padrão, o que mantém as respostas Binding próximas ao tamanho da solicitação e limita sua utilidade para ataques de reflexão. Deixe rfc5780 e stun-backward-compatibility desabilitados.
Permita tráfego de entrada para:
| Porta | Protocolo | Propósito |
|---|---|---|
3478 |
UDP | STUN e TURN |
3478 |
TCP | TURN |
49152–65535 |
UDP | Mídia retransmitida |
Permita também o tráfego de saída correspondente. A faixa de retransmissão deve corresponder a min-port e max-port.
Se o servidor estiver atrás de um NAT, configure o mapeamento external-ip=IP_PUBLICO/IP_PRIVADO do coturn e encaminhe as portas de escuta e de retransmissão. As portas de retransmissão devem reter seus números de porta através do NAT. Opções de implantação Coturn.
Adicione TLS para redes restritivas
TURN sobre TLS fornece outra opção de conexão para participantes cujas redes bloqueiam UDP.
Remova no-tls e configure:
tls-listening-port=5349
cert=/path/to/fullchain.pem
pkey=/path/to/privkey.pem
Abra 5349/TCP, garanta que o coturn possa ler o certificado e a chave, e reinicie-o após as renovações de certificado.
Você pode usar 443/TCP em vez disso, se essa porta estiver disponível no servidor TURN. Isso pode ajudar em redes restritivas, embora algumas redes também inspecionem e bloqueiem tráfego não HTTP na porta 443. A faixa de retransmissão UDP ainda é necessária quando os navegadores acessam o TURN via TCP ou TLS. Documentação do servidor Coturn.
2. Configure o Discourse
Em Admin → Configurações, procure estas configurações do Live:
| Configuração | Valor |
|---|---|
live_stun_servers |
A URI STUN do seu servidor coturn — substitua as entradas padrão |
live_turn_secret |
O valor usado para o static-auth-secret do coturn |
live_turn_secret_servers |
Suas URIs TURN, separadas por | |
live_turn_servers |
Vazio |
live_turn_username |
Vazio |
live_turn_credential |
Vazio |
Para a configuração acima, insira isto em live_stun_servers:
stun:turn.example.com:3478
E isto em live_turn_secret_servers:
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp
Se você habilitou TLS, adicione o endpoint:
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp|turns:turn.example.com:5349?transport=tcp
Use URIs stun:, turn: e turns:, sem //. Liste apenas os endpoints que seu servidor realmente suporta.
Navegadores baseados em Chromium também enviam solicitações STUN para os servidores TURN que você lista, então um live_stun_servers vazio pode funcionar desde que o coturn responda a STUN anônimo. Listar a URI STUN explicitamente torna a configuração mais clara, cobre outros navegadores e permite que os diagnósticos de conexão do Live a testem sozinhos.
A lista live_turn_secret_servers usa credenciais geradas a partir do segredo compartilhado. A lista separada live_turn_servers usa um nome de usuário e senha fixos. Definições de configuração do Live.
Salve as configurações e depois peça aos participantes que saiam e rejoinem as chamadas para obter a nova configuração.
3. Verifique a configuração
Teste com dois participantes em redes diferentes, como banda larga residencial e dados móveis, e em mais de um navegador — pelo menos um navegador baseado em Chromium e Firefox. Confirme que o áudio funciona em ambas as direções e depois teste vídeo e compartilhamento de tela.
Enquanto estiver em uma sala peer-to-peer, abra o menu ⋮ da sala e escolha Diagnóstico de conexão:
- Em Servidores STUN/TURN, cada servidor deve mostrar Acessível. Os servidores TURN devem listar um Endereço de retransmissão e os servidores UDP devem listar um Endereço público. “Endereço público: Nenhum” significa que as solicitações STUN não receberam resposta — verifique se não há
no-stun/secure-stune se3478/UDPestá aberto. - Em Pares, a rota mostra como cada conexão transporta a mídia: Direta (mesma rede), Direta (através de NAT via STUN) ou Retransmitida via TURN. A maioria dos participantes em redes residenciais comuns deve conectar-se diretamente.
- Copiar relatório produz um relatório em texto que você pode compartilhar com quem estiver resolvendo problemas. Ele inclui os endereços IP dos participantes, então compartilhe-o de forma privada.
Em navegadores Chromium, chrome://webrtc-internals mostra os mesmos detalhes em um nível mais baixo:
- Um candidato
srflxrepresenta um endereço público descoberto. - Um candidato
relayrepresenta uma retransmissão TURN disponível. - O par de candidatos selecionado mostra a conexão que realmente transporta a mídia.
Uma chamada direta bem-sucedida não prova que a retransmissão funciona. Teste também de uma rede que exige TURN, ou use um cliente de teste WebRTC com iceTransportPolicy: "relay" e credenciais temporárias.
Verifique os logs do coturn para alocações autenticadas com sucesso. Solicitações sem credenciais válidas não devem obter uma alocação de retransmissão. Um desafio de autenticação 401 inicial é normal; falhas repetidas de autenticação precisam de investigação.
Mantenha o servidor dedicado à sua comunidade
O segredo compartilhado fica no Discourse e no servidor TURN. Os participantes recebem credenciais temporárias em vez disso. O Live atualmente gera credenciais válidas por 12 horas para criar alocações; uma alocação estabelecida pode continuar enquanto é renovada. Geração de credenciais do Live.
Isso evita um retransmissor aberto anônimo, mas as credenciais TURN não estão vinculadas à origem do navegador: um participante pode copiar e reutilizar suas credenciais temporárias. Para limitar o abuso:
- Restrinja o acesso ao Live aos grupos pretendidos.
- Monitore a largura de banda de retransmissão e as contagens de alocações.
- Defina cotas de alocação e limites de largura de banda do coturn apropriados para sua comunidade.
- Bloqueie o acesso de retransmissão a destinos privados, link-local e outros internos alcançáveis a partir do host TURN.
- Mantenha o coturn atualizado e rotacione o segredo compartilhado se ele for exposto.
Use um segredo dedicado para esta implantação do Discourse. Seu servidor também responderá a solicitações STUN anônimas de qualquer pessoa; isso é esperado, usa pouca largura de banda e não concede acesso de retransmissão. Autenticação e controles de acesso Coturn.
Alternativas
Substituir apenas os servidores STUN públicos
Defina live_stun_servers para suas próprias URIs STUN, separadas por |:
stun:stun.example.com:3478
Deixe as configurações TURN vazias se você não precisar de uma retransmissão. Somente STUN não pode fazer as chamadas funcionarem em todas as redes.
Usar TURN com nome de usuário e senha fixos
Se seu provedor não suportar autenticação de segredo compartilhado, configure live_turn_servers, live_turn_username e live_turn_credential. Deixe as configurações de segredo compartilhado vazias.
Os participantes recebem essas credenciais fixas, o que as torna mais fáceis de reutilizar fora do seu site. Além disso, o Live currently força conexões retransmitidas quando servidores TURN estáticos são configurados e a lista STUN está vazia. Prefira autenticação de segredo compartilhado quando seu provedor a suportar. Configuração ICE do Live.