xAssist se puede configurar para usar WebRTC como protocolo de comunicación para permitir la comunicación en tiempo real a través de conexiones punto a punto. WebRTC es un dominio bastante complejo y utiliza el protocolo de transporte en tiempo real para transmitir audio y vídeo. Asegúrese de que su infraestructura de red no bloquee las comunicaciones WebRTC y permita el tráfico saliente con tráfico de retorno en respuesta.
Para obtener la mejor experiencia de usuario, recomendamos utilizar la última versión del navegador Google Chrome o Microsoft Edge (basado en Chromium). Asegúrese de que el navegador web pueda acceder a la cámara web, el micrófono y los altavoces de la computadora, de lo contrario, xAssist no funcionará correctamente.
En entornos de Microsoft Active Directory, las directivas de grupo pueden denegar el acceso a la cámara web y al micrófono del equipo. Asegúrese de tener acceso a su cámara web.
xAssist se adapta continuamente al ancho de banda disponible. Si el ancho de banda disponible es bajo, la calidad de la transmisión se reduce automáticamente. Esto se aplica principalmente a la calidad del vídeo, pero incluso si se interrumpe la transmisión de vídeo, el audio debería poder transmitirse.
En general, xAssist depende de una variedad de factores diferentes para determinar cuánto ancho de banda se requiere para usar xAssist. En general, se aplican los siguientes requisitos de ancho de banda:
La latencia también es un factor importante cuando se utiliza xAssist.
Nota: Una latencia baja es mejor que una latencia alta.
Se prefiere UDP a TCP porque reduce la latencia de transferencia de paquetes causada por las diferencias entre los dos protocolos.
Ningún navegador es compatible con UDP sobre proxies, lo que significa que los datos deben omitir el proxy si desea utilizar UDP. La inspección de paquetes se produce a costa de una mayor latencia. A menudo, la latencia cuando se utiliza la inspección de paquetes es tan alta que impide que se establezcan videollamadas.
Un servidor STUN hace un trabajo muy simple, le dice al cliente cuál es su dirección IP pública real y su puerto detrás de un servicio de traducción de direcciones de red (NAT). Mediante el uso de un servidor STUN, podemos inferir si el cliente está aceptando conexiones punto a punto de otros clientes en Internet.
Un servidor TURN proporciona una solución de reserva para los clientes que no pueden establecer una conexión punto a punto, actuando como un proxy de servidor multimedia entre los dos pares.
La señalización se utiliza para iniciar las transmisiones de vídeo y audio entre clientes. En xAssist, la señalización se realiza a través del Centro de Comando de Primera Línea para llamadas normales y a través de la Unidad de Desvío Selectivo para llamadas de conferencia.
WebRTC utiliza ICE para tratar de encontrar la mejor manera para que los clientes (web y gafas inteligentes) se comuniquen entre sí en una llamada: Peer-to-peer, peer-to-peer con traducción de direcciones de red (NAT) entre los clientes (usando un servidor STUN), o retransmitido usando un servidor TURN.
Para las llamadas normales (no las conferencias), la primera opción para los clientes (Smart Glass y Expert a través de la interfaz de usuario web) es una conexión directa de igual a igual. Esta opción se denomina HOST.
La siguiente opción es establecer una conexión punto a punto con traducción de direcciones de red (NAT) entre los clientes. Esta opción se llama REFLEXIVA. Esto significa que el servidor STUN intentará encontrar una IP pública y un puerto para los clientes que permita la comunicación peer-to-peer entre sus diferentes redes locales.
La última opción es utilizar un servidor TURN que retransmita las secuencias de vídeo y audio. Esta opción se denomina RELAYED.
Si la opción HOST o REFLEXIVE está disponible, entonces las transmisiones de video y audio son punto a punto (con cifrado de extremo a extremo) y debería haber habido una comunicación muy limitada con el servidor STUN/TURN para reunir los diversos candidatos para las tres opciones.
Si ninguna de las dos primeras opciones está disponible (debido a NAT simétrica, firewall u otros problemas), los clientes utilizarán la comunicación RELAYED a través del servidor TURN (aún con cifrado de extremo a extremo en su lugar).
En el caso de una conferencia telefónica, cada cliente se comunica con la SFU en lugar de con los demás clientes. A continuación, la SFU envía las secuencias a todos los demás clientes de la llamada. Al igual que con una llamada normal de 1 a 1, la opción de comunicación con la SFU será HOST, REFLEXIVE o RELAYED, y las transmisiones de video y audio entre cada cliente y la SFU estarán cifradas de extremo a extremo. Esto significa que la SFU descifrará las secuencias entrantes y enviará nuevas secuencias cifradas a los clientes. Por lo tanto, el cifrado entre los clientes no es de extremo a extremo, sino salto a salto.
Para las reglas mencionadas, su NAT debe permitir que los clientes (Smart Glasses y Experts a través de la interfaz de usuario web) tengan tráfico saliente con tráfico de retorno en respuesta si su NAT está configurada para realizar una asignación independiente del punto de conexión y, preferiblemente, un filtrado dependiente de la dirección o un filtrado independiente del punto de conexión.
Si no se pueden implementar todas las reglas mencionadas en las siguientes secciones (por ejemplo, debido a políticas de TI), WebRTC elegirá automáticamente la mejor opción posible como se describe en la sección Establecimiento de conectividad interactiva (ICE).
|Host/IP | Tipo | Protocolo | Puerto | TCP/UDP | |-----------------------------------|--------------------|-------------|------|---------| | frontlineworker.com/[tu dominio] | Servidor de aplicaciones | HTTPS/WSS | 443 | TCP |
Se debe permitir el tráfico UDP entrante y saliente. Los intervalos de puertos se pueden configurar a través de la directiva de grupo para el explorador web.
|Propósito | IP de destino| Protocolo | Puerto(s) | |------------------------|--------------------|----------|---------------| | Conexión de pares WebRTC | IP del par remoto| UDP | De 1025 a 65535 |
TeamViewer proporciona una red global de servidores STUN/TURN distribuidos, que incluye un mecanismo de equilibrio de carga que asigna automáticamente a los usuarios de xAssist al servidor STUN/TURN óptimo para su región.
|Región| Rango de IP|Propósito| IP de destino|Protocolo| Puerto(s) | |------|------------------|-------|-----------------------------------------|--------|------------------| |GLOBAL| * | TURN | turn.svc.frontlineworker.com | TCP |8080 | |GLOBAL| * | ATURDIR | 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 | ATURDIMIENTO | eu-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 | |Estados Unidos | 20.84.226.80/29 | TURN | us-{0..10}.turn.svc.frontlineworker.com | TCP |8080 | |Estados Unidos | 20.84.226.80/29 | ATURDIR | 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 | ATURDIR | 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 | ATURDIR | 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 | ATURDIR | in-{0..10}.turn.svc.frontlineworker.com | UDP |8080, 40000-45000 |
* Dependiendo de la región/DNS, se resuelve una de las siguientes
Nota: También se requiere acceso HTTPS/TCP 443 a webrtc.svc.frontlineworker.com para obtener las credenciales del servidor TURN.
TeamViewer proporciona una red global de SFU distribuidas, incluido un mecanismo de equilibrio de carga que asigna automáticamente la SFU óptima a los usuarios de xAssist en función de su región.
Para habilitar las llamadas de conferencia, webrtc.svc.frontlineworker.com debe ser accesible a través de HTTPS / TCP 443 para fines de señalización.
|Región| Rango de IP| Anfitrión | Tipo |Protocolo | Puerto(s) |TCP/UDP| |------|----------------|--------------------------------------|---------------------------------|---------|-----------|-------| |GLOBAL|* |webrtc.svc.frontlineworker.com |Señalización de puerta de enlace de llamadas múltiples |HTTPS/WSS|443 | TCP | |UE |20.54.230.192/29|eu-webrtc.svc.frontlineworker.com |Señalización de puerta de enlace de llamadas múltiples |HTTPS/WSS|443 | TCP | |EU |20.54.230.192/29|eu-{0..10}.sfu.svc.frontlineworker.com|Puerta de enlace multillamada Vídeo/Audio/RTP| RTP |40000-45000| UDP | |Estados Unidos |20.84.226.80/29 |us-webrtc.svc.frontlineworker.com |Señalización de puerta de enlace de llamadas múltiples |HTTPS/WSS|443 | TCP | |Estados Unidos |20.84.226.80/29 |Estados Unidos-{0..10}.sfu.svc.frontlineworker.com|Puerta de enlace multillamada Vídeo/Audio/RTP| RTP |40000-45000| UDP | |SA |20.201.68.120/29|sa-webrtc.svc.frontlineworker.com |Señalización de puerta de enlace de llamadas múltiples |HTTPS/WSS|443 | TCP | |SA |20.201.68.120/29|sa-{0..10}.sfu.svc.frontlineworker.com|Puerta de enlace multillamada Vídeo/Audio/RTP| RTP |40000-45000| UDP | |JP |20.210.56.40/29 |jp-webrtc.svc.frontlineworker.com |Señalización de puerta de enlace de llamadas múltiples |HTTPS/WSS|443 | TCP | |JP |20.210.56.40/29 |jp-{0..10}.sfu.svc.frontlineworker.com|Puerta de enlace multillamada Vídeo/Audio/RTP| RTP |40000-45000| UDP | |IN |52.140.81.48/29 |in-webrtc.svc.frontlineworker.com |Señalización de puerta de enlace de llamadas múltiples |HTTPS/WSS|443 | TCP | |IN |52.140.81.48/29 |in-{0..10}.sfu.svc.frontlineworker.com|Puerta de enlace multillamada Vídeo/Audio/RTP| RTP |40000-45000| UDP |
* Dependiendo de la región/DNS, se resuelve una de las siguientes
Nota: También se requiere acceso HTTPS/TCP 443 a webrtc.svc.frontlineworker.com para autenticarse en las SFU.
El marco WebRTC subyacente obliga a DTLS y SRTP en todas las conexiones, lo que significa que el vídeo y el audio están cifrados de extremo a extremo.
Incluso con Turn, los paquetes solo son descifrados por el destinatario, nunca por el servidor de Turn.
Cifrado forzado de extremo a extremo mediante DTLS/SRTP desde el mismo nivel a SFU. SFU descifra y vuelve a cifrar los medios para enviarlos al destinatario. Ningún medio del mismo nivel se almacena en un almacenamiento persistente.
El conjunto de cifrado utilizado es TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.