WebRTC e unidade de encaminhamento seletivo
O xAssist pode ser configurado para usar o WebRTC como protocolo de comunicação para permitir a comunicação em tempo real em conexões ponto a ponto. O 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 em 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 do grupo
Em ambientes do Microsoft Active Directory, as políticas de grupo podem negar o acesso à webcam e ao microfone do computador. Verifique se você tem acesso à webcam.
- Google.Policies.Chrome::VideoCaptureAllowed
- Google.Policies.Chrome::AudioCaptureAllowed
Largura de banda necessária
O xAssist se adapta 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 que o feed de vídeo seja interrompido, o áudio ainda poderá ser transmitido.
Em geral, o xAssist depende de uma variedade de fatores diferentes para determinar a largura de banda necessária para usar o xAssist. Em geral, aplicam-se os seguintes requisitos de largura de banda:
Latência
A latência também é um fator importante ao usar o xAssist.
Observação: a baixa latência é melhor do que a alta latência.
Informações gerais
O UDP é preferível ao TCP
O UDP é preferível ao TCP porque reduz a latência da transferência de pacotes causada pelas diferenças entre os dois protocolos.
Proxies e inspeção de pacotes
Nenhum navegador oferece suporte a UDP sobre proxies, o que significa que os dados devem contornar 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 o estabelecimento de chamadas de vídeo.
Termos de WebRTC
Servidor STUN
Um servidor STUN faz um trabalho muito simples: ele informa ao cliente qual é seu endereço IP público real e sua porta por trás de um serviço de NAT (Network Address Translation). Ao usar 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 conseguem 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 por meio do Frontline Command Center para chamadas normais e por meio da Selective Forwarding Unit para chamadas em conferência.
Estabelecimento de conectividade interativa (ICE)
O WebRTC usa o ICE para tentar encontrar a melhor maneira de os clientes (web e óculos inteligentes) se comunicarem entre si em uma chamada: Ponto a ponto, ponto a ponto com Network Address Translation (NAT) 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 Network Address Translation (NAT) entre os clientes. Essa opção é chamada de REFLEXIVE (REFLEXIVO). Isso significa que o servidor STUN tentará encontrar um IP e uma porta públicos para os clientes que permitam a comunicação ponto a ponto entre suas diferentes redes locais.
A última opção é usar um servidor TURN que retransmitiria os fluxos de vídeo e áudio. Essa opção é chamada de RELAYED.
Se a opção HOST ou REFLEXIVE estiver disponível, então os fluxos de vídeo e áudio são ponto a ponto (com criptografia de ponta a ponta) e deve 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 RELAYED por meio do servidor TURN (ainda com a criptografia de ponta a ponta em vigor).
Unidade de encaminhamento seletivo (SFU)
No caso de uma chamada em conferência, cada cliente se comunica com a SFU em vez de com os outros clientes. Em seguida, a SFU 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 com a SFU será HOST, REFLEXIVE ou RELAYED, e os fluxos de vídeo e áudio entre cada cliente e a SFU serão criptografados de ponta a ponta. Isso significa que a SFU descriptografará os fluxos de entrada e enviará novos fluxos criptografados aos clientes. Portanto, a criptografia entre os clientes não é de ponta a ponta, mas hop-by-hop.
Configuração do 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 final e, de preferência, filtragem dependente de endereço ou filtragem independente de ponto final.
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 | Type | Protocol | Port | TCP/UDP |
|-----------------------------------|--------------------|-------------|------|---------|
| frontlineworker.com/[your domain] | Application Server | HTTPS/WSS | 443 | TCP |
HostComunicação entrehost
O tráfego UDP de entrada e saída deve ser permitido. Os intervalos de portas podem ser configurados por meio da Política de Grupo para o navegador da Web.
| Purpose | Destination IP | Protocol | Port(s) |
|------------------------|--------------------|----------|---------------|
| WebRTC Peer Connection | remote peer's IP | UDP | 1025 to 65535 |
Frontline Servidor STUN e TURN
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.
|Region| IP Range |Purpose| Destination IP |Protocol| Port(s) |
|------|------------------|-------|-----------------------------------------|--------|------------------|
|GLOBAL| * | TURN | turn.svc.frontlineworker.com | TCP |8080 |
|GLOBAL| * | STUN | turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|EU | 20.54.230.192/29 | TURN | eu-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|EU | 20.54.230.192/29 | STUN | eu-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
|US | 20.84.226.80/29 | TURN | us-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|US | 20.84.226.80/29 | STUN | us-{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 |
|IN | 52.140.81.48/29 | TURN | in-{0..10}.turn.svc.frontlineworker.com | TCP |8080 |
|IN | 52.140.81.48/29 | STUN | in-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
*Dependendo da região/DNS, resolvendo um dos itens abaixo
Observação: o acesso HTTPS/TCP 443 a webrtc.svc.frontlineworker.com também é necessário para obter as credenciais do servidor TURN.
Frontline Servidores de conferência (SFU)
TeamViewer fornece uma rede global de SFUs distribuídas, incluindo um mecanismo de balanceamento de carga que atribui automaticamente a SFU ideal aos usuários do xAssist com base em sua região.
Para ativar as chamadas em conferência, o webrtc.svc.frontlineworker.com deve estar acessível via HTTPS / TCP 443 para fins de sinalização.
|Region| IP Range | Host | Type |Protocol | Port(s) |TCP/UDP|
|------|----------------|--------------------------------------|---------------------------------|---------|-----------|-------|
|GLOBAL|* |webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|EU |20.54.230.192/29|eu-webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|EU |20.54.230.192/29|eu-{0..10}.sfu.svc.frontlineworker.com|Multicall Gateway Video/Audio/RTP| RTP |40000-45000| UDP |
|US |20.84.226.80/29 |us-webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|US |20.84.226.80/29 |us-{0..10}.sfu.svc.frontlineworker.com|Multicall Gateway Video/Audio/RTP| RTP |40000-45000| UDP |
|SA |20.201.68.120/29|sa-webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|SA |20.201.68.120/29|sa-{0..10}.sfu.svc.frontlineworker.com|Multicall Gateway Video/Audio/RTP| RTP |40000-45000| UDP |
|JP |20.210.56.40/29 |jp-webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|JP |20.210.56.40/29 |jp-{0..10}.sfu.svc.frontlineworker.com|Multicall Gateway Video/Audio/RTP| RTP |40000-45000| UDP |
|IN |52.140.81.48/29 |in-webrtc.svc.frontlineworker.com |Multicall Gateway Signaling |HTTPS/WSS|443 | TCP |
|IN |52.140.81.48/29 |in-{0..10}.sfu.svc.frontlineworker.com|Multicall Gateway Video/Audio/RTP| RTP |40000-45000| UDP |
*Dependendo da região/DNS, resolvendo um dos itens abaixo
Observação: o acesso HTTPS/TCP 443 a webrtc.svc.frontlineworker.com também é necessário para autenticação nas SFUs.
Informações de segurança do xAssist
xAssist ponto a ponto (chamada 1 para 1)
A estrutura subjacente do WebRTC 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 do Turn.
Conferências xAssist
Criptografia forçada de ponta a ponta usando DTLS/SRTP do par para a SFU. A SFU descriptografa e criptografa novamente a mídia para enviá-la ao destinatário. Nenhuma mídia do par é armazenada em armazenamento persistente.
O pacote de criptografia usado é TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
Fontes externas
- https://webrtc-security.github.io/
- https://github.com/versatica/mediasoup