Prepare sua rede para transmissões ao vivo e reuniões no Meet

Atualize os firewalls para permitir que o tráfego de mídia passe pela organização:

• Para áudio e vídeo, limite as portas UDP de saída à porta 3478 e ao intervalo 19302–19309.
  • Para limitar o número de portas WebRTC do Chrome em uso, use as especificadas em Portas UDP WebRTC.
  • Você também pode limitar essas portas com o firewall.
• Para tráfego da Web e autenticação do usuário, use a porta de saída UDP e TCP 443.

As portas são permitidas sem qualquer limite de IP. Se as portas UDP estiverem bloqueadas, o TCP vai ser usado. O uso de TCP ou TCP com proxy pode diminuir a qualidade geral da reunião.

O Meet precisa ter acesso total à rede.

1. Se houver restrições ou políticas de filtragem para usuários na sua rede, conceda acesso de rede aos padrões de URI abaixo nesta página usando a porta 443.
2. Se você estiver usando um hardware do Google Meet, leia os requisitos de rede do ChromeOS em Configurar inspeção TLS (ou SSL) nos dispositivos Chrome.

Domínios para recursos estáticos

• clients2.google.com
• clients4.google.com
• clients6.google.com
• www.gstatic.com
• fonts.gstatic.com
• lh3.googleusercontent.com
• meetings.clients6.google.com

Domínios para conectividade de endpoints de API

• accounts.google.com
• apis.google.com
• meetings.googleapis.com
• hangouts.googleapis.com
• meet.google.com
• apps.google.com
• docs.google.com

Domínios para transmissões ao vivo

• meet.google.com
• stream.meet.google.com

Domínios para uploads de logs de eventos e feedback do usuário

• https://www.google.com/tools/feedback
• https://feedback.googleusercontent.com/resources/
• https://play.google.com/log

1. Caso sua organização precise permitir o tráfego no Meet pela porta 443, adicione o SNI do Meet à lista de permissões do firewall ou do proxy para autorizar o tráfego de áudio e vídeo pelo TLS. Esses endereços IP são diferentes dos URIs especificados na etapa 2.
2. Adicione intervalos de endereços IP do Google Workspace (para seus usuários). Use o seguinte conjunto de intervalos de IPs e SNI para permitir o acesso aos servidores de mídia do Meet:
   • IPv4: 74.125.250.0/24, 74.125.247.128/32
   • IPv6: 2001:4860:4864:5::0/64, 2001:4860:4864:4:8000::/128
   • SNI: workspace.turns.goog
3. Se sua organização usar transmissão ao vivo de baixa latência, o tráfego de mídia vai priorizar o protocolo UDP. Esse tráfego vai usar os intervalos de IP do Workspace (semelhante ao Meet) em vez dos IPs HTTP do YouTube.
4. Adicione intervalos de endereços IP do consumidor. Permita o acesso aos servidores de mídia do Meet usando o seguinte conjunto de intervalos de IP:
   • IPv4: 142.250.82.0/24
   • IPv6: 2001:4860:4864:6::/64
   • SNI: meet.turns.goog

Sua rede deve ter largura de banda suficiente para várias videochamadas em HD. Ela também precisa ter largura de banda extra para outras necessidades, como transmissão ao vivo. O número de participantes, o compartilhamento de tela e outros fatores também afetam o uso da largura de banda.

Se não houver largura de banda suficiente, o Meet vai reduzir a definição de vídeo. Caso sua rede não tenha largura de banda suficiente para vídeos, configure o Meet como "Somente áudio".

Para usar menos largura de banda, Hospede grandes transmissões ao vivo com menos largura de banda usando eCDN.

Calcular os requisitos mínimos de largura de banda do Meet

Para calcular a largura de banda mínima necessária na sua organização, multiplique a largura de banda média por participante pelo número máximo de participantes simultâneos.

O uso da largura de banda pode ser influenciado por vários elementos, como número de participantes, configurações de layout e compartilhamentos de tela. Se um compartilhamento de tela é estático, ele não consome mais largura de banda depois que é carregado.

*Dependendo da resolução enviada

Estimar o limite de participantes simultâneos

Se as reuniões forem de alta prioridade, estime que 20% das pessoas na sua organização vão usar o Meet simultaneamente. Se as reuniões do Meet forem de baixa prioridade, apenas 0,5% das pessoas poderão participar.

Requisitos de largura de banda por transmissão ao vivo

Se a organização transmite videochamadas ao vivo, a largura de banda ideal para cada feed é de 2,6 Mbps. As transmissões ao vivo têm opções de tamanho e layouts dinâmicos. Os recursos do dispositivo, como tamanho da janela e proporção, são otimizados. O Meet vai usar a configuração padrão de vídeo de alta qualidade se o participante tiver largura de banda individual suficiente.

Participantes sem largura de banda suficiente podem reduzir a qualidade do vídeo ou usar apenas áudio.

Bloco de vídeo único (taxa de bits em kilobits/s)

Bloco de compartilhamento de tela (taxa de bits em kilobit/s)

A qualidade da mídia transmitida ao vivo é afetada pela mídia original e pela forma de envio para o Meet. Para avaliar e comparar a qualidade, entre na chamada principal do Meet como participante regular da transmissão ao vivo.

1. No Google Admin Console, acesse Menu Apps Google Workspace Google Meet.

   Acesse o Google Meet

   Exige o privilégio de administrador "Configurações do serviço".

2. Clique em Configurações de vídeo do Meet.
3. À esquerda, selecione a unidade organizacional que você quer gerenciar. Para incluir todos os usuários, selecione a unidade organizacional de nível mais alto.
4. Selecione uma opção de qualidade do vídeo:
   • Ajustar automaticamente (padrão): a largura de banda é ajustada de acordo com as condições da rede e do sistema para oferecer a melhor qualidade possível.
   • Largura de banda de vídeo limitada: a largura de banda do uplink é restrita a 1 Mpbs.
   • Somente áudio: o vídeo é desativado por padrão. Os usuários podem clicar em para ativar a câmera na janela do navegador do Meet. O vídeo de uplink será limitado a 1 Mbps.
5. Aplique as configurações:
   1. Se a configuração for para a unidade organizacional de nível mais alto, clique em Salvar.
   2. Se a configuração for para uma unidade organizacional filha e for diferente da unidade organizacional mãe, clique em Substituir.

As recomendações a seguir são aplicáveis a ambientes de escritório comuns. Um engenheiro de redes sem fio precisa avaliar ambientes mais complexos, como:

• Pisos de fábrica
• Áreas com altos níveis de ruído de radiofrequência
• Espaços pouco cobertos

Leia com atenção as considerações a seguir durante o projeto, a implantação e a operação das redes sem fio usadas pelo Meet.

Bandas de radiofrequência 2,4 GHz e 5 GHz

Recomendamos que sua rede exija o uso da banda de RF de 5 GHz, se disponível.

Não implante nem opere o Meet na banda de 2,4 GHz de redes sem fio, porque costumam ser muito usadas. A banda de 2, 4 GHz também é menos confiável devido à presença de 3 canais não sobrepostos, além de apresentar altos níveis de ruído e interferências.

Considerações sobre projeto e implantação

Na sua rede sem fio, priorize a capacidade em vez da cobertura.

• Gerencie o tamanho da célula: controle o tamanho da célula pela potência de transmissão do ponto de acesso (AP). Implemente células menores onde mais dispositivos são esperados, como salas de reunião e auditórios, para aumentar a capacidade. Use células maiores para oferecer cobertura geral em escritórios.
• Desative as taxas baixas para melhorar a eficiência do uso da radiofrequência. Force a transferência do cliente para o AP mais próximo ao se mover entre os APs.
• Gerencie sua rede centralmente: para permitir o uso de recursos avançados, como o roaming integrado entre APs e o gerenciamento de radiofrequência adequado, é necessário que a rede sem fio seja gerenciada e operada de forma centralizada. Ela não pode ser um conjunto de pontos de acesso independentes.
• Faça uma pesquisa sem fio após a implantação. Confirme se há cobertura sem fio nos espaços onde o Meet costuma ser usado.

Como usar o WMM

Para garantir uma comunicação adequada do Meet em redes sem fio, use extensões de multimídia sem fio (WMM, na sigla em inglês).

O tráfego do Meet precisa ser classificado em um dos seguintes critérios:

• O controlador sem fio ou AP baseado nos protocolos e nas portas do Meet
• O valor do campo Differentiated Services Code Point (DSCP) definido por outro equipamento de rede. (que pode ser usado se você tiver confiança suficiente na rede)

O suporte total a WMM é necessário para oferecer a Qualidade de Serviço bidirecional. No entanto, é possível configurá-lo no nível da rede para ter benefícios significativos. O tráfego do Meet deve ser atribuído à fila de áudio ou vídeo no ponto de acesso ou controlador sem fio. O tráfego do Meet deve ter preferência em relação a outras classes de tráfego.

Os ambientes de VDI criam uma camada extra entre o Meet e a Internet. Isso pode deixar o Meet mais lento e diminuir a qualidade da experiência. Os efeitos do plano de fundo são limitados, e a visualização da sala não está disponível.

Para reduzir o impacto do uso da VDI no Meet, você pode seguir estas etapas:

• Ative a política da API Enterprise Hardware Platform no Chrome. Assim, o Meet consegue detectar que está sendo executado em uma máquina virtual (VM). Saiba mais em Definir políticas do Chrome para usuários ou navegadores e na página da API.
• Aloque pelo menos quatro CPUs virtuais para cada instância de VM.
• Uma GPU não é necessária para efeitos de segundo plano, mas as instâncias de VM ativadas para GPU aumentam a confiabilidade.
• Garanta largura de banda suficiente e baixa latência entre clientes, áreas de trabalho virtuais e servidores de mídia do Meet. Veja os requisitos de largura de banda entre as VMs e os servidores de mídia do Meet na Etapa 4 (acima). Consulte o provedor de VDI para encontrar a largura de banda necessária para conectar clientes de VDI com VMs.

A prática recomendada é não usar servidores proxy para o tráfego do Meet. Proxies de tráfego aumentam a latência, o que pode reduzir a qualidade dos vídeos.

Se for necessário usar servidores proxy na sua rede

Se você precisar usar um proxy, entenda que os servidores proxy podem afetar gravemente o desempenho e certifique-se de:

• Permitir o acesso ao tráfego do Meet na configuração do proxy.
• Confirmar que o Meet usa as configurações de proxy do Chrome.
• A rede ignora o proxy para o endereço IP e o SNI do Meet.

O protocolo de Internet Socket Secure (SOCKS5) ainda não é compatível.

É prática recomendada não usar a Qualidade de Serviço (QoS) para o Meet na sua rede. Use a QoS apenas se:

• Você tiver um motivo convincente, como uma rede congestionada
• puder implantar e manter um modelo de QoS de ponta a ponta na sua rede.

Se for necessário usar o recurso

É prática recomendada não usar VPNs para o tráfego do Meet. As VPNs aumentam a latência e podem reduzir a qualidade do vídeo e do áudio no Meet.

Se você precisar usar uma VPN:

• Ative o encapsulamento dividido para sua VPN
• Encaminhe os domínios da Etapa 2 fora da VPN usando o DNS ou o SNI (é recomendável usar SNI)
• Faça o roteamento dos intervalos de IP da Etapa 3 fora da VPN pela correspondência de prefixo