Caminhos de mídia para videochamada
Uma visão geral dos caminhos da rede de mídia usados pela videochamada – para a equipe de TI
Endereço do servidor de retransmissão de videochamada: vcct.healthdirect.org.au
Alcançando a conexão da melhor qualidade
1. Para a maioria dos caminhos de rede, a negociação provavelmente resultará em uma conexão de mídia válida.
- O ponto a ponto direto via UDP fornece a melhor conexão , mas muitas vezes estará indisponível em redes institucionais, devido às restrições de segurança de suas políticas de rede.
- Uma conexão TCP encapsulada segura é a opção menos desejável para transferência de mídia, mas provavelmente será suportada sem alterações na segurança da rede.
Opção recomendada: Para muitas redes, permitir a saída NAT para a porta UDP 3478 no servidor de retransmissão (caminho de rede 2, acima) fornecerá baixa latência com pouca sobrecarga. Isso deve exigir apenas uma alteração pequena e de baixo risco na configuração da sua rede.
2. Para garantir que o tráfego de videochamada seja priorizado como comunicação em tempo real, observe as opções abaixo:
- Se o seu roteador for capaz de priorizar o tráfego com o valor do campo DSCP de 34 (também conhecido como Assured Forwarding 41 ou AF41), você pode configurar isso. Todo o tráfego WebRTC em tempo real é marcado desta forma e isso melhorará a qualidade da videochamada e de outras soluções de videoconferência.
- Se o seu roteador não for capaz da funcionalidade acima, você pode configurar o QoS para priorizar pacotes UDP no intervalo de portas 5000-40000 e isso ajudará a priorizar pacotes de vídeo e reduzir qualquer atraso. WebRTC usa protocolo RTP para entregar fluxos de mídia e RTP geralmente usa UDP 5000-40000. Fazer isso pode priorizar alguns pacotes que não precisam disso, mas a maioria serão pacotes RTP. Configurar o QoS dessa forma garantirá que os fluxos de vídeo tenham o mínimo de interrupções e instabilidade.
A videochamada tentará usar o melhor caminho de rede que puder encontrar.
A tabela a seguir lista os caminhos de rede que serão procurados, em ordem de preferência:
| Caminho de rede | Porta do servidor STUN/retransmissão |
|---|---|
|
1: UDP ponto a ponto direto, com passagem NAT assistida por servidor STUN Cada endpoint descobrirá seu endereço de Internet externo usando o servidor STUN fornecido. Esse endereço é fornecido ao outro endpoint e usado para configurar a conexão por meio da Tradução de Endereço de Rede. A mídia flui por portas selecionadas aleatoriamente em uma grande variedade de portas UDP 49152 - 65535. |
3478 (UDP) |
|
2: Via servidor de retransmissão de videochamada, usando saída roteada por UDP Se uma conexão não puder ser estabelecida usando o ponto a ponto direto acima, a porta UDP 3478 do servidor TURN configurada será tentada para estabelecer uma retransmissão para o terminal remoto. Esse endereço de retransmissão é fornecido ao outro terminal e usado para configurar a conexão por meio da retransmissão, de volta à conexão do terminal local com o servidor TURN. A mídia flui para a porta UDP 3478 no servidor TURN. |
3478 (UDP) |
|
3: Via servidor de retransmissão de chamada de vídeo, usando saída roteada por TCP Se uma conexão não puder ser estabelecida usando UDP com o TURN Server, a conexão com o TURN Server será estabelecida via TCP 443 e não por UDP 3478. A mídia flui para fora para a porta TCP 443 no TURN Server. |
3478 (TCP) |
|
4: Via servidor de retransmissão de videochamada, usando tunelamento TCP por meio de um servidor proxy da web local Se uma conexão roteada via NAT não puder ser estabelecida com o TURN Server, uma conexão em túnel para a porta TCP 443 será tentada por meio do servidor proxy da web configurado pelo navegador. A mídia flui para fora através do proxy da web, para a porta TCP 443 no servidor TURN. |
443 (TCP) |
|
5a, 5b: Via servidor de retransmissão de videochamada, usando TCP seguro Como 3 ou 4 acima, mas usando uma conexão TLS TCP com o TURN Server. |
443 (TCP/TLS) |
Para obter mais informações, consulte Servidores de retransmissão de videochamada .