WebRTC e Unidade de Encaminhamento Seletivo
O xAssist pode ser configurado para usar WebRTC como o protocolo de comunicação para permitir a comunicação em tempo real através de conexões ponto a ponto. WebRTC é um domínio bastante complexo e usa o Real-time Transport Protocol para transmitir áudio e vídeo. Certifique-se de que sua infraestrutura de rede não bloqueie as comunicações WebRTC e permita o tráfego de saída com tráfego de retorno em resposta.
Para obter a melhor experiência do usuário, recomendamos usar o navegador Google Chrome ou Microsoft Edge (baseado no Chromium) mais recente. Certifique-se de que o navegador da Web possa acessar a webcam, o microfone e os alto-falantes do computador, caso contrário, o xAssist não funcionará corretamente.
Políticas de grupo
Em ambientes do Microsoft Active Directory, as diretivas de grupo podem negar acesso à webcam e ao microfone do computador. Certifique-se de que tem acesso à sua webcam.
- Google.Policies.Chrome::VideoCaptureAllowed
- Google.Policies.Chrome::AudioCaptureAllowed
Largura de banda necessária
O xAssist adapta-se continuamente à largura de banda disponível. Se a largura de banda disponível for baixa, a qualidade do streaming será automaticamente reduzida. Isso se aplica principalmente à qualidade do vídeo, mas mesmo se o feed de vídeo for interrompido, o áudio ainda poderá ser transmitido.
No geral, o xAssist depende de uma variedade de fatores diferentes para determinar quanta largura de banda é necessária para usar o xAssist. Em geral, os seguintes requisitos de largura de banda se aplicam:
Latência
A latência também é um fator importante ao usar o xAssist.
Nota: Baixa latência é melhor do que alta latência.
Informações gerais
UDP é preferido em relação ao TCP
O UDP é preferido em relação ao TCP porque reduz a latência de transferência de pacotes causada pelas diferenças entre os dois protocolos.
Proxies e inspeção de pacotes
Nenhum navegador suporta UDP sobre proxies, o que significa que os dados devem ignorar o proxy se você quiser usar UDP. A inspeção de pacotes tem o custo de maior latência. Muitas vezes, a latência ao usar a inspeção de pacotes é tão alta que impede que chamadas de vídeo sejam estabelecidas.
Termos WebRTC
Servidor STUN
Um servidor STUN faz um trabalho muito simples, ele diz ao cliente qual é o seu endereço IP público real e porta está por trás de um serviço de conversão de endereços de rede (NAT). Usando um servidor STUN, podemos inferir se o cliente está aceitando conexões ponto a ponto de outros clientes na Internet.
Servidor TURN
Um servidor TURN fornece uma solução de fallback para clientes que não podem estabelecer uma conexão ponto a ponto, atuando como um proxy de servidor de mídia entre os dois pares.
Sinalização
A sinalização é usada para iniciar os fluxos de vídeo e áudio entre os clientes. No xAssist, a sinalização é feita através do Centro de Comando da Linha de Frente para chamadas normais e através da Unidade de Encaminhamento Seletivo para chamadas em conferência.
Estabelecimento de conectividade interativa (ICE)
O WebRTC usa o ICE para tentar encontrar a melhor maneira para os clientes (web e óculos inteligentes) se comunicarem uns com os outros em uma chamada: ponto a ponto, ponto a ponto com NAT (Network Address Translation) entre os clientes (usando um servidor STUN) ou retransmitido usando um servidor TURN.
Para chamadas normais (não conferências), a primeira opção para os clientes (Smart Glass e Expert via Web UI) é uma conexão direta ponto a ponto. Essa opção é chamada de HOST.
A próxima opção é estabelecer uma conexão ponto a ponto com NAT (Network Address Translation) entre os clientes. Essa opção é chamada de REFLEXIVA. Isso significa que o servidor STUN tentará encontrar um IP público e uma porta para os clientes que permitirão a comunicação ponto a ponto entre suas diferentes redes locais.
A última opção é usar um servidor TURN que retransmita os fluxos de vídeo e áudio. Essa opção é chamada de RELAYED.
Se a opção HOST ou REFLEXIVE estiver disponível, os fluxos de vídeo e áudio são peer-to-peer (com criptografia de ponta a ponta no lugar) e deveria ter havido uma comunicação muito limitada com o servidor STUN/TURN para reunir os vários candidatos para as três opções.
Se nenhuma das duas primeiras opções estiver disponível (devido a NAT simétrico, firewall ou outros problemas), os clientes usarão a comunicação RETRANSMITIDA através do servidor TURN (ainda com criptografia de ponta a ponta).
Unidade de Encaminhamento Seletivo (SFU)
No caso de uma chamada em conferência, cada cliente se comunica com o SFU em vez dos outros clientes. O SFU então envia os fluxos para todos os outros clientes na chamada. Como em uma chamada normal de 1 para 1, a opção de comunicação para o SFU será HOST, REFLEXIVE ou RELAYED, e os fluxos de vídeo e áudio entre cada cliente e o SFU serão criptografados de ponta a ponta. Isso significa que o SFU descriptografará os fluxos de entrada e enviará novos fluxos criptografados para os clientes. Portanto, a criptografia entre os clientes não é de ponta a ponta, mas de salto a salto.
Configuração de firewall para clientes xAssist
Para as regras mencionadas, seu NAT deve permitir que os Clientes (Smart Glasses e Experts via Web UI) tenham tráfego de saída com tráfego de retorno em resposta se seu NAT estiver configurado para fazer mapeamento independente de ponto de extremidade e, de preferência, filtragem dependente de endereço ou filtragem independente de ponto de extremidade.
Se nem todas as regras mencionadas nas seções a seguir puderem ser implementadas (por exemplo, devido a políticas de TI), o WebRTC escolherá automaticamente a melhor opção possível, conforme descrito na seção Estabelecimento de conectividade interativa (ICE).
|Host/IP | Tipo | Protocolo | Porto | TCP/UDP | |-----------------------------------|--------------------|-------------|------|---------| | frontlineworker.com/[Seu domínio] | Servidor de Aplicativos | HTTPS/WSS | 443 |TCP |
Comunicação host-to-host
O tráfego UDP de entrada e saída deve ser permitido. Os intervalos de portas podem ser configurados por meio da Diretiva de Grupo para o navegador da Web.
|Finalidade | IP de destino | Protocolo | Porta(s) | |------------------------|--------------------|----------|---------------| | Conexão de peer WebRTC | IP do par remoto | UDP | 1025 a 65535 |
Servidor STUN e TURN Frontline
O TeamViewer fornece uma rede global de servidores STUN/TURN distribuídos, incluindo um mecanismo de balanceamento de carga que atribui automaticamente os usuários do xAssist ao servidor STUN/TURN ideal para sua região.
|Região| Intervalo de IP |Finalidade| IP de destino |Protocolo| Porta(s) |
|------|------------------|-------|-----------------------------------------|--------|------------------|
|GLOBAL| * | TURN | turn.svc.frontlineworker.com | TCP |8080 |
|GLOBAL| * | STUN | turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|UE | 20.54.230.192/29 | TURN | eu-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|UE | 20.54.230.192/29 | STUN | eu-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|EUA | 20.84.226.80/29 | TURN | EUA-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|EUA | 20.84.226.80/29 | STUN | EUA-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|SA | 20.201.68.120/29 | TURN | sa-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|SA | 20.201.68.120/29 | STUN | sa-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|JP | 20.210.56.40/29 | TURN | jp-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|JP | 20.210.56.40/29 | STUN | jp-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|EM | 52.140.81.48/29 | TURN | em-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|EM | 52.140.81.48/29 | STUN | em-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
*Dependendo da região/DNS resolvendo um dos itens abaixo
Nota: O acesso HTTPS/TCP 443 ao webrtc.svc.frontlineworker.com também é necessário para obter credenciais de servidor TURN.
Servidores de Conferência de Linha de Frente (SFU)
O TeamViewer fornece uma rede global de SFUs distribuídas, incluindo um mecanismo de balanceamento de carga que atribui automaticamente o SFU ideal aos usuários do xAssist com base em sua região.
Para habilitar chamadas em conferência, webrtc.svc.frontlineworker.com deve ser acessível via HTTPS / TCP 443 para fins de sinalização.
|Região| Intervalo de IP | Anfitrião | Tipo |Protocolo | Porta(s) |TCP/UDP|
|------|----------------|--------------------------------------|---------------------------------|---------|-----------|-------|
|GLOBAL|* |webrtc.svc.frontlineworker.com |Sinalização de gateway de várias chamadas |HTTPS/WSS|443 | TCP |
|EU |20.54.230.192/29|eu-webrtc.svc.frontlineworker.com |Sinalização de gateway de várias chamadas |HTTPS/WSS|443 | TCP |
|EU |20.54.230.192/29|eu-{0..10}.sfu.svc.frontlineworker.com|Vídeo/Áudio/RTP de Gateway de Multichamada | RTP |40000-45000| UDP |
|EUA |20.84.226.80/29 |us-webrtc.svc.frontlineworker.com |Sinalização de gateway de várias chamadas |HTTPS/WSS|443 | TCP |
|EUA |20.84.226.80/29 |us-{0..10}.sfu.svc.frontlineworker.com|Vídeo/Áudio/RTP de Gateway de Multichamada | RTP |40000-45000| UDP |
|SA |20.201.68.120/29|sa-webrtc.svc.frontlineworker.com |Sinalização de gateway de várias chamadas |HTTPS/WSS|443 | TCP |
|SA |20.201.68.120/29|sa-{0..10}.sfu.svc.frontlineworker.com|Vídeo/Áudio/RTP de Gateway de Multichamada | RTP |40000-45000| UDP |
|JP |20.210.56.40/29 |jp-webrtc.svc.frontlineworker.com |Sinalização de gateway de várias chamadas |HTTPS/WSS|443 | TCP |
|JP |20.210.56.40/29 |jp-{0..10}.sfu.svc.frontlineworker.com|Vídeo/Áudio/RTP de Gateway de Multichamada | RTP |40000-45000| UDP |
|EM |52.140.81.48/29 |in-webrtc.svc.frontlineworker.com |Sinalização de gateway de várias chamadas |HTTPS/WSS|443 | TCP |
|IN |52.140.81.48/29 |em-{0..10}.sfu.svc.frontlineworker.com|Vídeo/Áudio/RTP de Gateway de Multichamada | RTP |40000-45000| UDP |
*Dependendo da região/DNS resolvendo um dos itens abaixo
Nota: O acesso HTTPS/TCP 443 ao webrtc.svc.frontlineworker.com também é necessário para autenticar nas SFUs.
Informações de segurança do xAssist
xAssist ponto a ponto (1 a 1 chamada)
A estrutura WebRTC subjacente força o DTLS e o SRTP em todas as conexões, o que significa que o vídeo e o áudio são criptografados de ponta a ponta.
Mesmo com o Turn, os pacotes são descriptografados apenas pelo destinatário, nunca pelo servidor Turn.
Conferências xAssist
Criptografia forçada de ponta a ponta usando DTLS/SRTP de ponto a ponto para SFU. O SFU descriptografa e criptografa novamente a mídia para enviá-la ao destinatário. Nenhuma mídia de peer é armazenada em armazenamento persistente.
O conjunto de cifras usado é TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.