Partilhar via

Recomendações de rede

  • Artigo

Este artigo resume como o ambiente de rede afeta a qualidade das chamadas de voz e vídeo. Muitos fatores contribuem para a qualidade da mídia em tempo real dos Serviços de Comunicação do Azure que inclui áudio, vídeo e compartilhamento de aplicativos. Alguns dos fatores incluem qualidade de rede e largura de banda, firewall, host e configurações de dispositivo.

Qualidade da rede

A qualidade da mídia em tempo real sobre IP é significativamente afetada pela qualidade da conectividade de rede subjacente, mas especialmente pela quantidade de:

  • Latência. O tempo que leva para obter um pacote IP do ponto A ao ponto B na rede. Esse atraso de propagação de rede é determinado pela distância física entre os dois pontos e qualquer outra sobrecarga incorrida pelos dispositivos pelos quais o tráfego flui. A latência é medida como tempo de ida ou volta (RTT).
  • Perda de pacotes. Uma porcentagem de pacotes que são perdidos em uma janela de tempo específica. A perda de pacotes afeta diretamente a qualidade do áudio, desde pequenos pacotes individuais perdidos que quase não têm impacto até perdas de burst back-to-back que causam corte de áudio completo.
  • Jitter de chegada entre pacotes, também conhecido como jitter. A variação média no atraso entre pacotes sucessivos. Os Serviços de Comunicação podem adaptar-se a alguns níveis de jitter através de buffering. É apenas quando o desvio excede o buffering que um participante percebe seus efeitos.

Largura de banda de rede

Certifique-se de que sua rede esteja configurada para suportar a largura de banda exigida por sessões de mídia simultâneas dos Serviços de Comunicação e outros aplicativos de negócios. Testar o caminho de rede de ponta a ponta para gargalos de largura de banda é fundamental para a implantação bem-sucedida de sua solução de Serviços de Comunicação Multimídia.

Os seguintes requisitos de largura de banda são para os SDKs JavaScript.

Largura de banda Cenários
40 Kbps Chamadas de áudio ponto a ponto
500 Kbps Chamadas de áudio ponto a ponto e compartilhamento de tela
500 Kbps Videochamada com qualidade ponto a ponto 360 pixels a 30 FPS
1,2 Mbps Videochamadas peer-to-peer com qualidade HD com resolução HD de 720 pixels a 30 FPS
500 Kbps Videochamada em grupo 360 pixels a 30 FPS
1,2 Mbps Videochamadas em grupo HD com resolução de HD 720 pixels a 30 FPS
1,5 Mbps Chamadas de vídeo peer-to-peer com qualidade HD com resolução de HD 1080 pixels a 30 FPS

Os seguintes requisitos de largura de banda são para os SDKs nativos do Windows, Android e iOS.

Largura de banda Cenários
30 Kbps Chamadas de áudio ponto a ponto
130 Kbps Chamadas de áudio ponto a ponto e compartilhamento de tela
500 Kbps Videochamada com qualidade ponto a ponto 360 pixels a 30 FPS
1,2 Mbps Videochamadas peer-to-peer com qualidade HD com resolução HD de 720 pixels a 30 FPS
1,5 Mbps Chamadas de vídeo peer-to-peer com qualidade HD com resolução de HD 1080 pixels a 30 FPS
500 Kbps/1 Mbps Videochamadas em grupo
1 Mbps/2 Mbps Videochamadas em grupo HD, vídeos de 540 pixels em uma tela de 1080 pixels

Configuração da firewall

As ligações aos Serviços de Comunicação requerem ligação à Internet para portas e endereços IP específicos para proporcionar experiências multimédia de alta qualidade. Sem acesso a essas portas e endereços IP, os Serviços de Comunicação não funcionarão corretamente. A lista de intervalos de IP e permitir domínios listados que precisam ser habilitados são:

Categoria Intervalos de IP ou FQDN Portas
Tráfego multimédia Intervalo de endereços IP da nuvem pública do Azure 20.202.0.0/16 O intervalo fornecido acima é o intervalo de endereços IP no processador de mídia ou no serviço TURN dos Serviços de Comunicação do Azure. UDP 3478 a 3481, portas TCP 443
Sinalização, telemetria, registo *.skype.com, *.microsoft.com, *.azure.net, *.azure.com, *.office.com TCP 443, 80

Os pontos de extremidade abaixo devem ser acessíveis apenas para clientes do GCC High do governo dos EUA.

Categoria Intervalos de IP ou FQDN Portas
Tráfego multimédia 52.127.88.0/21, 52.238.114.160/32, 52.238.115.146/32, 52.238.117.171/32, 52.238.118.132/32, 52.247.167.192/32, 52.247.169.1/32, 52.247.172.50/32, 52.247.172.103/32, 104.212.44.0/22, 195.134.228.0/22 UDP 3478 a 3481, portas TCP 443
Sinalização, telemetria, registo *.gov.teams.microsoft.us, *.infra.gov.skypeforbusiness.us, *.online.gov.skypeforbusiness.us, gov.teams.microsoft.us TCP 443, 80

Otimização de rede

As tarefas a seguir são opcionais e não são necessárias para implantar os Serviços de Comunicação. Use esta orientação para otimizar o desempenho da rede e dos Serviços de Comunicação ou se souber que tem algumas limitações de rede. Você pode querer otimizar ainda mais se:

  • Os Serviços de Comunicação são executados lentamente. Talvez você tenha largura de banda insuficiente.
  • As chamadas continuam caindo. As quedas podem ser causadas por bloqueadores de firewall ou proxy.
  • As chamadas têm estáticas e recortadas, ou as vozes soam como robôs. Esses problemas podem ser causados por desvios ou perda de pacotes.
Tarefa de otimização de rede Detalhes
Planeie a sua rede Nesta documentação, você pode encontrar requisitos mínimos para sua rede para chamadas. Consulte o exemplo do Teams para planejar sua rede.
Resolução de nomes externos Certifique-se de que todos os computadores que executam os SDKs dos Serviços de Comunicação podem resolver consultas DNS externas para descobrir os serviços fornecidos pelos servidores de comunicação e que os firewalls não estão impedindo o acesso. Certifique-se de que os SDKs possam resolver os endereços *.skype.com, *.microsoft.com, *.azure.net, *.azure.com e *.office.com.
Manter a persistência da sessão Verifique se o firewall não altera os endereços ou portas NAT (conversão de endereços de rede) mapeados para UDP.
Validar o tamanho do pool NAT Valide o tamanho do pool de NAT necessário para a conectividade do usuário. Quando vários usuários e dispositivos acessarem os Serviços de Comunicação usando NAT ou conversão de endereço de porta, certifique-se de que os dispositivos ocultos atrás de cada endereço IP publicamente roteável não excedam o número suportado. Certifique-se de que endereços IP públicos adequados sejam atribuídos aos pools NAT para evitar o esgotamento da porta. O esgotamento da porta contribui para que os utilizadores internos e os dispositivos não consigam ligar-se aos Serviços de Comunicação.
Orientações para deteção e prevenção de intrusões Se o seu ambiente tiver um sistema de deteção de intrusão ou um sistema de prevenção de intrusão implantado para uma camada extra de segurança para conexões de saída, permita todas as URLs dos Serviços de Comunicação.
Configurar VPN de túnel dividido Forneça um caminho alternativo para o tráfego do Teams que ignora a rede virtual privada (VPN), comumente conhecida como VPN de túnel dividido. O túnel dividido significa que o tráfego dos Serviços de Comunicação não passa pela VPN, mas vai diretamente para o Azure. Ignorar sua VPN tem um impacto positivo na qualidade da mídia e reduz a carga dos dispositivos VPN e da rede da organização. Para implementar uma VPN de túnel dividido, trabalhe com seu fornecedor de VPN. Outras razões pelas quais recomendamos ignorar a VPN:
  • Normalmente, as VPNs não são projetadas ou configuradas para suportar mídia em tempo real.
  • As VPNs também podem não suportar UDP, o que é necessário para os Serviços de Comunicação.
  • As VPNs também introduzem uma camada extra de criptografia sobre o tráfego de mídia que já está criptografado.
  • A conectividade com os Serviços de Comunicação pode não ser eficiente devido ao tráfego fixo através de um dispositivo VPN.
Implementar QoS Use a Qualidade de Serviço (QoS) para configurar a priorização de pacotes. A QoS melhora a qualidade das chamadas e ajuda-o a monitorizar e a resolver problemas de qualidade das chamadas. A QoS deve ser implementada em todos os segmentos de uma rede gerenciada. Mesmo quando uma rede é adequadamente provisionada para largura de banda, a QoS fornece redução de riscos se ocorrerem eventos de rede imprevistos. Com a QoS, o tráfego de voz é priorizado para que esses eventos imprevistos não afetem negativamente a qualidade.
Otimizar Wi-Fi Semelhante à VPN, as redes Wi-Fi não são necessariamente projetadas ou configuradas para suportar mídia em tempo real. Planejar ou otimizar uma rede Wi-Fi para oferecer suporte aos Serviços de Comunicação é uma consideração importante para uma implantação de alta qualidade. Considere estes fatores:
  • Implemente QoS ou Wi-Fi Multimedia para garantir que o tráfego de mídia esteja sendo priorizado adequadamente em relação às suas redes Wi-Fi.
  • Planeie e otimize as bandas Wi-Fi e a colocação de pontos de acesso. A faixa de 2,4 GHz pode fornecer uma experiência adequada, dependendo do posicionamento do ponto de acesso, mas os pontos de acesso são frequentemente afetados por outros dispositivos de consumo que operam nessa faixa. A faixa de 5 GHz é mais adequada para mídia em tempo real por causa de seu alcance denso, mas requer mais pontos de acesso para obter cobertura suficiente. Os pontos de extremidade também precisam suportar esse intervalo e ser configurados para usar essas bandas de acordo.
  • Se estiver a utilizar redes Wi-Fi de banda dupla, considere implementar a direção de banda. A direção de banda é uma técnica implementada por fornecedores de Wi-Fi para influenciar clientes de banda dupla a usar a faixa de 5 GHz.
  • Quando os pontos de acesso do mesmo canal estão muito próximos, eles podem causar sobreposição de sinal e competir involuntariamente, o que resulta em uma experiência de usuário degradada. Certifique-se de que os pontos de acesso próximos uns dos outros estão em canais que não se sobrepõem.
Cada fornecedor de redes sem fios tem as suas próprias recomendações para implementar a sua solução sem fios. Consulte o seu fornecedor de Wi-Fi para obter orientações específicas.

Sistemas operacionais e navegadores (para SDKs JavaScript)

Os SDKs de voz e vídeo dos Serviços de Comunicação suportam determinados sistemas operacionais e navegadores. Saiba mais sobre os sistemas operacionais e navegadores que os SDKs de chamada suportam na documentação conceitual de chamada.

Próximos passos

Os seguintes artigos podem ser do seu interesse: