Caminhos de mídia para videochamada
Uma visão geral dos caminhos de rede de mídia usados pela chamada de vídeo - para equipe de TI
Endereço do servidor de retransmissão de videochamada: vcct.healthdirect.org.au
Alcançando a melhor qualidade de conexão
1. Para a maioria dos caminhos de rede, a negociação provavelmente resultará em uma conexão de mídia válida.
- A conexão ponto a ponto direta via UDP fornece a melhor conexão , mas muitas vezes não estará disponível em redes institucionais devido às restrições de segurança de suas políticas de rede.
- Uma conexão TCP segura em túnel é 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) proporcionará baixa latência com pouca sobrecarga. Isso deve exigir apenas uma pequena alteração 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, veja as opções abaixo:
- Se o seu roteador for capaz de priorizar o tráfego com valor de campo DSCP de 34 (também conhecido como Encaminhamento Garantido 41 ou AF41), você pode configurar isso? Todo o tráfego WebRTC em tempo real é marcado dessa forma, o que melhorará a qualidade das chamadas de vídeo e de outras soluções de videoconferência.
- Se o seu roteador não for compatível com a funcionalidade acima, você pode configurar o QoS para priorizar pacotes UDP na faixa de portas 5000-40000. Isso ajudará a priorizar pacotes de vídeo e reduzir qualquer atraso. O WebRTC usa o protocolo RTP para entregar fluxos de mídia, e o RTP geralmente usa UDP 5000-40000. Isso pode priorizar alguns pacotes que não precisam, 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 jitter.
A chamada de vídeo tentará usar o melhor caminho de rede que puder encontrar.
A tabela a seguir lista os caminhos de rede que ele procurará, em ordem de preferência:
| Caminho de rede | Porta do servidor STUN/Relay |
|---|---|
|
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 um grande intervalo de portas UDP 49152 - 65535. |
3478 (UDP) |
|
2: Via servidor de retransmissão de chamada de vídeo, 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 configurado tentará estabelecer um retransmissor para o ponto final remoto. Este endereço de retransmissão é fornecido ao outro ponto final e usado para configurar a conexão através do retransmissor, retornando através da conexão do ponto final 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 para o servidor TURN, a conexão com o servidor TURN será estabelecida via TCP 443, não UDP 3478. A mídia flui para a porta TCP 443 no servidor TURN. |
3478 (TCP) |
|
4: Via servidor de retransmissão de chamadas de vídeo, usando tunelamento TCP por meio de um servidor proxy da web local Se uma conexão roteada via NAT não puder ser estabelecida para o servidor TURN, uma conexão em túnel para a porta TCP 443 será tentada por meio do servidor proxy da Web configurado no 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 chamada de vídeo, usando TCP seguro Como no 3 ou 4 acima, mas usando uma conexão TLS TCP com o servidor TURN. |
443 (TCP/TLS) |
Para obter mais informações, consulte Servidores de retransmissão de chamadas de vídeo .