Topologías de flujos de llamadas

En este artículo se describen las topologías de flujo de llamadas de Azure Communication Services y se detalla cómo se cifra la llamada al tráfico. Para obtener una introducción a los flujos de llamadas de Azure Communication Services, consulte Llamadas internas de redes.

Contexto

Conceptos de red

Antes de revisar las topologías de flujo de llamadas, resulta útil comprender los términos que usa este artículo.

Una red de clientes contiene los segmentos de red que administre. La red del cliente puede incluir redes cableadas e inalámbricas dentro de su oficina o entre oficinas, centros de datos y proveedores de servicios de Internet.

Normalmente, una red de clientes 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 lograr el rendimiento óptimo y la calidad de la solución de comunicación.

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

Tipos de tráfico

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

Los medios en tiempo real se transmiten a través de Real-Time Protocolo de transporte (RTP). Este protocolo admite la transmisión de datos de audio, vídeo y uso compartido de pantalla. Estos datos son sensibles a los problemas de latencia de red. Aunque es posible transmitir elementos multimedia en tiempo real mediante TCP o HTTP, se recomienda usar el Protocolo de datagramas de usuario (UDP) como protocolo de capa de transporte para admitir experiencias de usuario de alto rendimiento. Las cargas multimedia transmitidas a través de RTP se protegen a través de RTP seguro (SRTP).

Los usuarios de la solución de Azure Communication Services se conectan a los servicios desde sus dispositivos cliente. La señalización controla la comunicación entre estos dispositivos y los servidores. Por ejemplo, la señalización entre dispositivos y el servicio admite el inicio de llamadas y el chat en tiempo real. La mayoría del tráfico de señalización usa REST HTTPS. En algunos escenarios, puede usar el Protocolo de inicio de sesión (SIP) como protocolo de 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 una experiencia de usuario final agradable.

Cifrado de medios

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

El tráfico multimedia se cifra y fluye entre el autor de la llamada y el destinatario mediante SRTP, un perfil de 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 de cliente a cliente se negocia a través de la señalización de conexión de cliente a servidor y se cifra a través de SRTP al pasar directamente del cliente al cliente.

Las instancias de Azure Communication Services que llaman a los clientes del SDK usan la seguridad de la capa de transporte de datagramas (DTLS) para derivar una clave de cifrado. Una vez realizado el protocolo de enlace DTLS, el medio comienza a fluir a través de esta clave de cifrado negociada por DTLS a través de SRTP.

Las instancias de Azure Communication Services que llaman al SDK y a los clientes de Teams 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 seguro de seguridad de la capa de transporte (TLS).

El tráfico multimedia que va 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 un canal UDP/TCP cifrado TLS 1.2 y AES-256 (en modo GCM).

Principios de 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 Azure Communication Services determina la región en la que se hospeda la llamada. Hay excepciones a esta regla en algunas topologías, que puede encontrar más adelante en este artículo.

• El punto de conexión multimedia que se usa para admitir una llamada de Azure 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 podría usar un punto de conexión multimedia en la nube para procesar medios para la transcripción o la grabación. Es posible que una llamada con dos participantes 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 en la que se hospeda la llamada. El tráfico multimedia enviado desde un cliente al punto de conexión multimedia se puede enrutar directamente. O bien, podría usar una retransmisión de transporte en Azure si las restricciones de firewall de red del cliente lo requieren.

• El tráfico multimedia de las llamadas punto a punto toma la ruta más directa que está disponible, suponiendo que la llamada no necesita un punto de conexión multimedia en la nube.

  La ruta preferida es directa al par remoto (cliente). Si una ruta directa no está disponible, uno o varios relés de transporte reenvían el tráfico. El tráfico multimedia no debe atravesar servidores que actúen como formadores de paquetes o servidores de red privada virtual (VPN) ni cumplir otras funciones que podrían retrasar el procesamiento y degradar la experiencia del usuario final.

• La señalización del tráfico siempre va al servidor más cercano al usuario.

Para obtener más información sobre las rutas de acceso multimedia, consulte documentación conceptual de flujos de llamadas.

Flujos de llamadas en varias topologías

Azure Communication Services (Internet)

En este ejemplo de topología de flujo de llamadas se muestran los clientes que usan Azure Communication Services desde la nube sin ninguna implementación local, como el enrutamiento directo de Azure. En esta topología, el tráfico hacia y desde Azure Communication Services fluye a través de Internet.

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

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 Azure Communication Services del usuario. Entre los ejemplos de estos flujos se incluyen dns y transmisión multimedia punto a punto.
• Flow 2': representa un flujo iniciado por un usuario de Azure Communication Services móvil remoto con VPN a la red del cliente.
• Flow 3: representa un flujo iniciado por un usuario remoto de Azure Communication Services móvil a los puntos de conexión de Azure Communication Services.
• Flujo 4: representa un flujo iniciado por un usuario en la red del cliente a Azure Communication Services.
• Flujo 5: representa un flujo multimedia punto a punto entre un usuario de Azure Communication Services y otro dentro de la red del cliente.
• Flujo 6: representa un flujo multimedia punto a punto entre un usuario de Azure Communication Services móvil remoto y otro usuario de Azure Communication Services móvil remoto 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, el SDK de llamada obtiene un conjunto de candidatos que consta de direcciones IP y puertos. Este conjunto incluye candidatos locales, relés y reflexivos (la dirección IP pública del cliente, tal como lo ve la retransmisión). El SDK que llama envía estos candidatos al partido llamado. El partido llamado recibe un conjunto similar de candidatos y los envía al autor de la llamada.

El sistema usa mensajes de comprobación de conectividad de STUN para buscar qué rutas de acceso de llamada o llamadas de medios de entidad funcionan y, a continuación, selecciona la mejor ruta de acceso de trabajo. Una vez que el sistema establece la ruta de acceso de conexión, realiza un protocolo de enlace DTLS a través de la conexión para garantizar la seguridad. Después del protocolo de enlace DTLS, el sistema deriva las claves SRTP del proceso de protocolo de enlace DTLS. Los medios (paquetes RTP/RTCP protegidos a través de SRTP) se envían a través del par candidato seleccionado. El relé de transporte está disponible como parte de los Servicios de Comunicación de Azure.

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 si usa una NAT) para los medios. Si los dos clientes están en la red del cliente, se debe seleccionar la ruta de acceso directa. Esta selección requiere conectividad UDP directa dentro de la red del cliente. Si los clientes son usuarios de la nube nomadic, dependiendo de NAT/firewall, los medios podrían usar la conectividad directa.

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, puede usar uno de los candidatos de retransmisión de transporte de cualquier cliente. Por ejemplo, el cliente interno obtuvo un candidato de retransmisión de la retransmisión de transporte en Azure y el cliente externo debe poder enviar paquetes STUN/RTP/RTCP a la retransmisión de transporte. Otra opción es que el cliente interno envíe al candidato de retransmisión obtenido por el cliente en la nube móvil. Aunque se recomienda encarecidamente la conectividad UDP para medios, se admite TCP.

Pasos a nivel macro

1. El usuario de Azure Communication Services A resuelve el nombre de dominio de dirección URL (DNS) mediante Flow 2.

2. El usuario A asigna un puerto de retransmisión multimedia en la retransmisión de transporte de Teams mediante Flow 4.

3. El usuario A envía una invitación con candidatos de establecimiento de conectividad interactiva (ICE) mediante Flow 4 a Azure Communication Services.

4. Azure Communication Services notifica al usuario B mediante Flow 4.

5. El usuario B asigna un puerto de retransmisión multimedia en la retransmisión de transporte de Teams mediante Flow 4.

6. El usuario B envía una respuesta con candidatos ICE mediante Flow 4, que se reenvía al usuario A mediante Flow 4.

7. El usuario A y el usuario B invocan pruebas de conectividad ICE y se selecciona la mejor ruta de acceso multimedia disponible. Revise los diagramas siguientes para ver varios casos de uso.

8. Ambos usuarios envían telemetría a Azure Communication Services mediante Flow 4.

Red del cliente (intranet)

En el paso 7, se selecciona Flujo de medios punto a punto 5.

Esta transmisión de medios es bidireccional. La dirección de Flow 5 indica que un lado inicia la comunicación desde una perspectiva de conectividad. En este caso, no importa qué dirección se usa, ya que ambos puntos de conexión están dentro de la red del cliente.

Red del cliente al usuario externo (medios retransmitidos por la retransmisión de transporte de Teams)

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

La retransmisión de transporte de Teams controla estos flujos dentro de Azure.

Esta transmisión de medios 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 medios, y usan diferentes protocolos y direcciones de transporte.

Red del cliente a usuario externo (elementos multimedia directos)

En el paso 7, se selecciona Flow 2 (de la red del cliente al mismo nivel del cliente 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 de medios es bidireccional. La dirección de Flow 2 al usuario móvil remoto indica que un lado inicia la comunicación desde una perspectiva de conectividad.

Usuario vpn al usuario interno (medios retransmitidos por la retransmisión de transporte de Teams)

La señalización entre la VPN a la red del cliente usa Flow 2'. La señalización entre la red del cliente y Azure usa Flow 4. Sin embargo, los medios omiten la VPN y se enrutan a través de flujos 3 y 4 a través de Azure Media Relay.

Usuario de VPN a usuario interno (elementos multimedia directos)

La señalización entre la VPN a la red del cliente usa Flow 2'. La señalización entre la red del cliente y Azure usa Flow 4. Sin embargo, los medios omiten la VPN y se enrutan a través de Flow 2 desde la red del cliente a Internet.

Esta transmisión de medios es bidireccional. La dirección de Flow 2 al usuario móvil remoto indica que un lado inicia la comunicación desde una perspectiva de conectividad.

Usuario de VPN a usuario externo (elementos multimedia directos)

La señalización entre el usuario VPN a la red del cliente usa Flow 2' y Flow 4 a Azure. Sin embargo, los medios omiten la VPN y se enrutan a través de Flow 6.

Esta transmisión de medios es bidireccional. La dirección de Flow 6 al usuario móvil remoto indica que un lado inicia la comunicación desde una perspectiva de conectividad.

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

Azure Communication Services permite realizar y recibir llamadas desde la red telefónica conmutada (RTC). Si el tronco RTC está conectado a través de números de teléfono proporcionados por Azure Communication Services, no hay ningún requisito de conectividad especial para este caso de uso. Si quiere conectar su propio tronco RTC local a Azure Communication Services, puede usar el enrutamiento directo 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 Azure Communication Services

El servicio que proporciona audio, vídeo y uso compartido de pantalla forma parte de Azure Communication Services. Tiene una dirección IP pública que debe ser accesible tanto desde la red del cliente como desde un cliente en la nube nomadic. Cada cliente y punto 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 porque 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.

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: un SBC en el límite con RTN debe finalizar la secuencia RTP/RTCP, protegida a través de 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 SIP de señalización de Azure Communication Services con un SBC de terceros o una puerta de enlace podría atravesar servidores proxy SIP nativos de Microsoft (al igual que Teams). No se admite la interoperabilidad con servidores proxy SIP de terceros.

• B2BUA (o SBC) de terceros: un SBC de terceros finaliza estos flujos multimedia de Azure Communication Services hacia y desde la RTC. No se admite la interoperabilidad con un CLS de terceros dentro de la red de Azure Communication Services (en la que un SBC de terceros media dos puntos de conexión de Azure Communication Services).

Tecnologías no admitidas

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

  Nota:

  Aunque el título indica Lync, se aplica a Azure Communication Services y Teams.

• Conformadores de paquetes: los dispositivos de creación de paquetes, inspección de paquetes o modelado de paquetes no se admiten y pueden degradar significativamente la calidad.

Paso siguiente

Contenido relacionado

• Obtenga más información sobre los tipos de llamadas.
• Obtenga información sobre la arquitectura de cliente-servidor.