Topologías de flujos de llamadas

En este artículo se describen las topologías de flujo de llamadas de Azure Communication Services. En este artículo, obtendrá información detallada sobre los conceptos de red de Azure Communication Services, cómo se cifra la llamada al tráfico y para obtener una introducción a los flujos de llamadas de Communication Services, visite la documentación conceptual de flujos de llamadas.

Fondo

Conceptos de red

Antes de revisar las topologías de flujo de llamadas, definimos algunos términos a los que se hace referencia en todo el documento.

Una red de cliente contiene los segmentos de red que usted administra. Podría incluir redes cableadas e inalámbricas en su oficina o entre oficinas, centros de datos y proveedores de servicios de Internet.

Normalmente, una red de cliente tiene varios perímetros de red con firewalls o servidores proxy que aplican las directivas de seguridad de la organización. Se recomienda realizar una evaluación de red completa para garantizar el rendimiento y la calidad óptimos de la solución de comunicación.

La red de Communication Services es la red que admite Azure Communication Services. Microsoft administra esta red y se distribuye en todo el mundo con centros de datos propiedad de Microsoft más cercanos a los clientes finales. Esta red es la responsable del relé de transporte, el procesamiento de los elementos multimedia para las llamadas grupales y otros componentes que admiten la comunicación multimedia enriquecida en tiempo real.

Tipos de tráfico

Communication Services se basa principalmente en dos tipos de tráfico: elementos multimedia en tiempo real y señalización.

Los elementos multimedia en tiempo real se transmiten mediante el protocolo de transporte en tiempo real (RTP). Este protocolo es compatible con la transmisión de datos de audio, vídeo y pantalla compartida. Estos datos pueden sufrir problemas de latencia de red. Aunque es posible transmitir elementos multimedia en tiempo real mediante TCP o HTTP, se recomienda el uso de UDP como protocolo de capa de transporte para admitir experiencias de usuario final de alto rendimiento. Las cargas de los elementos multimedia transmitidas a través de RTP se protegen mediante SRTP.

Los usuarios de la solución Communication Services se conectan a los servicios desde sus dispositivos cliente. La comunicación entre estos dispositivos y los servidores se controla con señalización. Por ejemplo, se permite iniciar una llamada y el chat en tiempo real mediante la señalización entre los dispositivos y el servicio. La mayoría del tráfico de señalización usa REST de HTTPS, aunque en algunos casos se puede usar SIP como protocolo para el tráfico de señalización. Aunque este tipo de tráfico es menos sensible a la latencia, la señalización de baja latencia proporciona a los usuarios de la solución una experiencia de usuario final agradable.

Cifrado de medios

Los flujos de llamadas en el SDK de llamadas de Azure Communication Services y los clientes de Teams se basan en el Protocolo de descripción de sesión (SDP) RFC 8866 modelo de oferta y respuesta a través de HTTPS. Una vez que el destinatario acepta una llamada entrante, el autor de la llamada y el destinatario acuerdan los parámetros de la sesión.

El tráfico multimedia se cifra y fluye entre el autor de la llamada y el destinatario mediante Secure RTP (SRTP), un perfil del Protocolo de transporte en tiempo real (RTP) que proporciona confidencialidad, autenticación y protección contra ataques de reproducción al tráfico RTP. En la mayoría de los casos, el tráfico multimedia del cliente al cliente se negocia a través de la señalización de conexión del cliente al servidor y se cifra mediante SRTP al pasar directamente del cliente al cliente.

El SDK de llamada de Azure Communication Services usa DTLS para derivar una clave de cifrado. Una vez realizado el protocolo de enlace DTLS, el medio comienza a fluir mediante esta clave de cifrado negociada por DTLS a través de SRTP.

Los clientes del SDK y los clientes de Teams de Azure Communication Services usan un token basado en credenciales para el acceso seguro a las retransmisiones multimedia a través de TURN. Las retransmisiones multimedia intercambian el token a través de un canal protegido por TLS.

El tráfico multimedia de Azure Communication Services entre dos puntos de conexión que participan en el uso compartido de audio, vídeo y vídeo de Azure Communication Services usa SRTP para cifrar la secuencia multimedia. Las claves criptográficas se negocian entre los dos puntos de conexión a través de un protocolo de señalización, que usa TLS 1.2 y AES-256 (en modo GCM) cifrado de canal UDP/TCP.

Principios del flujo de llamadas

Hay cuatro principios generales que respaldan los flujos de llamadas de Azure Communication Services:

• El primer participante de una llamada de grupo de Communication Services determina la región donde se hospeda la llamada. En algunas topologías existen excepciones a esta regla, que se describen a continuación.
• El punto de conexión multimedia usado para admitir una llamada de Communication Services se selecciona en función de las necesidades de procesamiento multimedia, y no se ve afectado por el número de participantes en una llamada. Por ejemplo, una llamada de punto a punto puede utilizar un punto de conexión multimedia en la nube para procesar elementos multimedia para la transcripción o la grabación, mientras que una llamada con dos participantes quizá no use ningún punto de conexión multimedia. Las llamadas grupales usan un punto de conexión multimedia con fines de combinación y enrutamiento. Este punto de conexión se selecciona en función de la región donde se hospeda la llamada. El tráfico multimedia enviado desde un cliente al punto de conexión multimedia se puede enrutar directamente, o bien, se puede usar un relé de transporte en Azure si las restricciones del firewall de red del cliente así lo requieren.
• El tráfico multimedia para las llamadas del mismo nivel toma la ruta más directa disponible, suponiendo que la llamada no necesita un punto de conexión multimedia en la nube. La ruta preferida es la directa al elemento remoto del mismo nivel (cliente). Si una ruta directa no está disponible, una o varias retransmisiones de transporte reenvía el tráfico. El tráfico multimedia no debe atravesar servidores que actúen como moldeadores de paquetes, servidores VPN u otras funciones que puedan retrasar el procesamiento y reducir la calidad de la experiencia del usuario final.
• El tráfico de señalización siempre se dirige al servidor más cercano al usuario.

Para más información sobre la ruta de acceso a los elementos multimedia elegida, consulte la documentación conceptual sobre los flujos de llamadas.

Flujos de llamadas en varias topologías

Communication Services (Internet)

Esta topología la usan los clientes que emplean Communication Services desde la nube sin implementación local, como enrutamiento directo de Azure. En esta topología, el tráfico hacia Communication Services y desde aquí fluye a través de Internet.

Figura 1. Topología Communication Services

La dirección de las flechas del diagrama anterior refleja la dirección de inicio de la comunicación que afecta a la conectividad en los perímetros empresariales. En el caso de UDP para medios, los primeros paquetes pueden fluir en la dirección inversa, pero estos paquetes pueden bloquearse hasta que los paquetes en la otra dirección fluyen.

Descripciones de flujo:

• Flujo 2: Representa un flujo iniciado por un usuario en la red del cliente a Internet como parte de la experiencia de Communication Services del usuario. Algunos ejemplos de estos flujos son la transmisión de elementos multimedia de DNS y del mismo nivel.
• Flow 2: Representa un flujo iniciado por un usuario remoto de Communication Services móvil, con VPN a la red del cliente.
• Flujo 3: representa un flujo iniciado por un usuario remoto de Communication Services móvil a puntos de conexión de Communication Services.
• Flujo 4: representa un flujo iniciado por un usuario en la red del cliente a Communication Services.
• Flujo 5: representa un flujo de elementos multimedia del mismo nivel entre un usuario de Communication Services y otro dentro de la red del cliente.
• Flujo 6: representa un flujo de elementos multimedia del mismo nivel entre un usuario remoto de Communication Services móvil y otro usuario remoto de Communication Services móvil a través de Internet.

Caso de uso: llamada uno a uno

Una llamada uno a uno significa que un usuario llama directamente a otro usuario. Para inicializar la llamada al SDK que realiza la llamada, obtenga un conjunto de candidatos que constan de direcciones IP y puertos, incluidos los candidatos locales, de retransmisión y reflexivos (dirección IP pública del cliente, tal como se ve en la retransmisión). El SDK del autor de la llamada envía estos candidatos al partido llamado; el partido llamado también obtiene un conjunto similar de candidatos y los envía al autor de la llamada. Los mensajes de comprobación de la conectividad de STUN se usan para encontrar las rutas de acceso a los elementos multimedia del autor o receptor de la llamada funcionan y se selecciona la ruta que mejor funciona. Una vez establecida la ruta de acceso de conexión, se realiza un protocolo de enlace DTLS a través de esta conexión para garantizar la seguridad. Después del protocolo de enlace DTLS, las claves SRTP se derivan del proceso de protocolo de enlace DTLS. Después, los elementos multimedia (es decir, los paquetes RTP/RTCP protegidos mediante SRTP) se envían mediante el par candidato seleccionado. La retransmisión de transporte está disponible como parte de Azure Communication Services.

Si la dirección IP local y los candidatos de puerto o los candidatos reflexivos tienen conectividad, se selecciona la ruta de acceso directa entre los clientes (o mediante una NAT) para los medios. Si los dos clientes están en la red del cliente, se debe seleccionar la ruta de acceso directa. Esto requiere conectividad UDP directa dentro de la red del cliente. Si los clientes son usuarios de la nube Nomadic, los elementos multimedia usarán conectividad directa en función de la NAT o el firewall.

Si un cliente es interno en la red del cliente y un cliente es externo (por ejemplo, un usuario de nube móvil), es poco probable que se habilite la conectividad directa entre los candidatos locales o reflexivos. En este caso, una opción es usar uno de los candidatos de relé de transporte de cualquier cliente (por ejemplo, el cliente interno obtuvo un candidato de relé del relé de transporte en Azure; el externo debe poder enviar paquetes STUN/RTP/RTCP al relé de transporte). Otra opción es que el cliente interno realice el envío al candidato de relé obtenido por el cliente de la nube móvil. Aunque para los elementos multimedia se recomienda encarecidamente la conectividad UDP, se admite TCP.

Pasos generales:

1. El usuario de Communication Services A resuelve el nombre de dominio de la dirección URL (DNS) con el flujo 2.
2. El usuario A asigna un puerto de relé multimedia en el relé de transporte de Teams mediante el flujo 4.
3. El usuario de Communication Services A envía una "invitación" con los candidatos ICE mediante el flujo 4 a Communication Services.
4. Communication Services notifica al usuario B mediante el flujo 4.
5. El usuario B asigna un puerto de relé multimedia en el relé de transporte de Teams mediante el flujo 4.
6. El usuario B envía una "respuesta" con los candidatos ICE mediante el flujo 4, que se reenvía de vuelta al usuario A mediante el flujo 4.
7. El usuario A y el usuario B invocan las pruebas de conectividad por ICE y se selecciona la mejor ruta de acceso a los elementos multimedia disponibles (consulte los diagramas siguientes para varios casos de uso).
8. Ambos usuarios envían telemetría a Communication Services mediante el flujo 4.

Red del cliente (intranet)

Figura 2. En la red del cliente

En el paso 7, se selecciona el flujo 5 de elementos multimedia del mismo nivel.

Esta transmisión multimedia es bidireccional. La dirección del flujo 5 indica que un lado inicia la comunicación desde una perspectiva de conectividad. En este caso no importa qué dirección se use, porque ambos puntos de conexión forman parte de la red del cliente.

Red del cliente a usuario externo (elementos multimedia retransmitidos por el relé de transporte de Teams)

Figura 3. Red del cliente a usuario externo (elementos multimedia retransmitidos por el relé de transporte de Azure)

En el paso 7, se seleccionan el flujo 4 (de la red del cliente a Communication Services) y el flujo 3 (de un usuario remoto de Communication Services móvil a Azure Communication Services).

Estos flujos los retransmite el relé de transporte de Teams en Azure.

Esta transmisión multimedia es bidireccional. La dirección indica qué lado inicia la comunicación desde una perspectiva de conectividad. En este caso, estos flujos se usan para la señalización y los elementos multimedia, con diferentes direcciones y protocolos de transporte.

Red del cliente a usuario externo (elementos multimedia directos)

Figura 4. Red del cliente a usuario externo (elementos multimedia directos)

En el paso 7 se selecciona el flujo 2 (desde la red del cliente al elemento del mismo nivel a través de Internet).

Los elementos multimedia directos con un usuario remoto móvil (no retransmitido mediante Azure) son opcionales. En otras palabras, puede bloquear esta ruta de acceso para aplicar una ruta de acceso a los elementos multimedia mediante un relé transporte en Azure.

Esta transmisión multimedia es bidireccional. La dirección del flujo 2 a un usuario remoto móvil indica que un lado inicia la comunicación desde una perspectiva de conectividad.

Usuario de VPN a usuario interno (elementos multimedia retransmitidos por el relé de transporte de Teams)

Figura 5. Usuario de VPN a usuario interno (elementos multimedia retransmitidos por Azure Relay)

La señalización entre la VPN y la red del cliente sigue el flujo 2*. La señalización entre la red del cliente y Azure sigue el flujo 4. Sin embargo, los elementos multimedia omiten la VPN y se enrutan mediante los flujos 3 y 4 mediante el relé multimedia de Azure.

Usuario de VPN a usuario interno (elementos multimedia directos)

Figura 6. Usuario de VPN a usuario interno (elementos multimedia directos)

La señalización entre la VPN y la red del cliente sigue el flujo 2'. La señalización entre la red del cliente y Azure sigue el flujo 4. Sin embargo, los elementos multimedia omiten la VPN y se enrutan mediante el flujo 2 desde la red del cliente a Internet.

Esta transmisión multimedia es bidireccional. La dirección del flujo 2 a un usuario remoto móvil indica que un lado inicia la comunicación desde una perspectiva de conectividad.

Usuario de VPN a usuario externo (elementos multimedia directos)

Figura 7. Usuario de VPN a usuario externo (elementos multimedia directos)

La señalización entre el usuario de VPN y la red del cliente sigue el flujo 2* y el flujo 4 a Azure. Sin embargo, los elementos multimedia omiten la VPN y se enrutan mediante el flujo 6.

Esta transmisión multimedia es bidireccional. La dirección del flujo 6 a un usuario remoto móvil indica que un lado inicia la comunicación desde una perspectiva de conectividad.

Caso de uso: cliente de Communication Services a RTC a través del tronco de Communication Services

Communication Services permite realizar llamadas desde la red telefónica conmutada (RTC) y recibirlas aquí. Si el tronco de RTC está conectado mediante números de teléfono proporcionados por Communication Services, no hay requisitos de conectividad especiales para este caso de uso. Si quiere conectar su propio tronco de RTC local a Azure Communication Services, puede usar el enrutamiento directo de Azure (disponible en CY2021).

Figura 8. Usuario de Communication Services a RTC mediante el tronco de Azure

En este caso, la señalización y los elementos multimedia de la red del cliente a Azure siguen el flujo 4.

Caso de uso: llamadas de grupo de Communication Services

El servicio de uso compartido de audio/vídeo/pantalla (VBSS) forma parte de Azure Communication Services. Tiene una dirección IP pública que debe ser accesible desde la red del cliente y desde un cliente de la nube Nomadic. Los clientes o puntos de conexión deben poder conectarse al servicio.

Los clientes internos obtienen candidatos locales, reflexivos y de retransmisión de la misma manera que se describen para las llamadas de uno a uno. Los clientes envían estos candidatos al servicio en una invitación. El servicio no usa una retransmisión, ya que tiene una dirección IP accesible públicamente, por lo que responde con su candidato de dirección IP local. El cliente y el servicio comprueban la conectividad de la misma manera que se describe para las llamadas uno a uno.

Figura 9. Llamadas grupales de Communication Services

Restricciones de interoperabilidad

Los medios que fluyen a través de Azure Communication Services están restringidos de la siguiente manera:

Controlador de borde de sesión (SBC) de terceros en el límite con RTC debe finalizar la secuencia RTP/RTCP, protegida mediante SRTP y no retransmitirla al próximo salto. Si retransmite el flujo al próximo salto, es posible que no se entienda.

Servidores proxy SIP de terceros. Un cuadro de diálogo de SIP de señalización de Communication Services con una puerta de enlace o SBC de terceros puede atravesar los servidores proxy SIP nativos de Microsoft (como Teams). No se admite la interoperabilidad con servidores proxy SIP de terceros.

B2BUA de terceros (o SBC). El flujo de los elementos multimedia de Communication Services hacia la RTC y desde aquí lo termina un SBC de terceros. No se admite la interoperabilidad con un SBC de terceros dentro de la red de Communication Services (donde un SBC de terceros media dos puntos de conexión de Communication Services).

Tecnologías no admitidas

Red VPN. Communication Services no admite la transmisión de medios a través de VPN. Si los usuarios utilizan clientes VPN, el cliente debe dividir y enrutar el tráfico multimedia a través de una conexión que no sea VPN, como se especifica en Permiso de los elementos multimedia de Lync para omitir un túnel VPN.

Nota:

Aunque el título indica Lync, es aplicable a Azure Communication Services y Teams.*

Moldeadores de paquetes. No se admiten dispositivos de recorte, inspección o moldeado de paquetes, ya que pueden degradar considerablemente la calidad.

Pasos siguientes

Introducción a las llamadas

Puede que los siguientes documentos le resulten interesantes:

• Más información sobre los tipos de llamada
• Información sobre la arquitectura de cliente y servidor