Llamadas internas de red

En el artículo se describen los flujos de llamadas en Azure Communication Services. La señalización y los flujos multimedia dependen de los tipos de llamadas que realizan los usuarios. Entre los ejemplos de tipos de llamadas se incluyen VoIP uno a uno, una red telefónica conmutada (RTC) pública y llamadas grupales que contienen una combinación de participantes conectados a VoIP y RTC. Para obtener más información, consulte Tipos de llamadas.

Señalización y protocolos multimedia

Cuando se establece una llamada punto a punto o de grupo, se usan dos protocolos en segundo plano: HTTPS (REST) para la señalización y el Protocolo de transporte seguro en tiempo real (SRTP) para los medios.

La señalización entre los SDK o entre los SDK y los controladores de señalización de Communication Services se controla con REST HTTPS (TLS). Azure Communication Services usa TLS 1.2. Para el tráfico multimedia en tiempo real (RTP), se recomienda el protocolo de datagramas de usuario (UDP). Si el firewall impide el uso de UDP, el SDK usa el protocolo de control de transmisión (TCP) para los medios.

Vamos a revisar los protocolos de señalización y multimedia en varios escenarios.

Casos de flujo de llamadas

Caso 1: VoIP con una conexión directa entre dos dispositivos

En llamadas VoIP o videollamadas uno a uno, el tráfico prefiere la ruta más directa. La ruta de acceso directa significa que si dos SDK pueden comunicarse entre sí directamente, establecen una conexión directa. La ruta de acceso directa es posible cuando dos SDK están en la misma subred (por ejemplo, en una subred 192.168.1.0/24) o dos cuando los dispositivos se encuentran en subredes que se pueden ver entre sí (los SDK de la subred 10.10.0.0/16 y 192.168.1.0/24 pueden ponerse en contacto entre sí).

Caso 2: VoIP en el que no es posible una conexión directa entre dispositivos, pero es posible una conexión entre dispositivos NAT

Si dos dispositivos se encuentran en subredes que no pueden comunicarse entre sí, pero la conexión entre los dispositivos de traducción de direcciones de red (NAT) es posible, los SDK del lado cliente establecen la conectividad a través de dispositivos NAT. Por ejemplo, si Alice trabaja desde una cafetería y Bob trabaja desde una oficina doméstica.

En el caso de Alice, es el dispositivo NAT de la cafetería y, para Bob, es el de la oficina doméstica. El dispositivo de Alice envía la dirección externa de su NAT y Bob hace lo mismo. Los SDK aprenden las direcciones externas de una utilidad de recorrido de sesión para el servicio NAT (STUN) que Azure Communication Services proporciona de forma gratuita. La lógica que controla el protocolo de saludo entre Alice y Bob está integrada en los SDKs proporcionados por Azure Communication Services. No necesita ninguna configuración agregada.

Caso 3: VoIP en el que no es posible ni una conexión directa ni NAT

Si uno o ambos dispositivos cliente están detrás de una NAT simétrica, se requiere un servicio en la nube independiente para retransmitir el multimedia entre los dos SDK. Este servicio se denomina recorrido mediante relés alrededor de NAT (TURN) y también lo proporciona Azure Communication Services. El SDK de llamadas de Communication Services usa automáticamente los servicios TURN en función de las condiciones de red detectadas. Los cargos de TURN se incluyen en el precio de la llamada.

Caso 4: Llamadas de grupo con RTC

Tanto la señalización como los medios de comunicación para las llamadas de la red telefónica pública conmutada (RTPC) usan el recurso de telefonía de Azure Communication Services. Este recurso está interconectado con otros operadores.

El tráfico multimedia RTC fluye a través de un componente de procesador de multimedia.

Para las llamadas de grupo, los medios y la señalización siempre fluyen a través del back-end de Azure Communication Services. El audio o el vídeo de todos los participantes se mezclan en el procesador multimedia. Todos los miembros de una llamada de grupo envían sus secuencias de audio y vídeo al procesador multimedia, que devuelve secuencias multimedia mixtas.

El protocolo en tiempo real (RTP) predeterminado para las llamadas grupales es el protocolo de datagramas de usuario (UDP).

Si el SDK no puede usar UDP para medios debido a restricciones de firewall, intenta usar el protocolo de control de transmisión (TCP). El componente de procesador multimedia requiere UDP, por lo que, en este caso, el servicio TURN de Communication Services se agrega a la llamada de grupo para traducir TCP a UDP. Los cargos de TURN se incluyen en el precio de la llamada.

Caso 5: SDK de Communication Services y Microsoft Teams en una reunión de Teams programada

La señalización fluye a través del controlador de señalización. Los medios fluyen a través del procesador multimedia. El controlador de señalización y el procesador multimedia se comparten entre Communication Services y Microsoft Teams.

Caso 6: Medios tempranos

Hace referencia a medios que se intercambian, como audio y vídeo, antes de que el destinatario acepte la sesión. Para el flujo multimedia anticipado, el controlador de borde de sesión (SBC) debe enlazarse al primer punto de conexión que inicia la transmisión de medios; el flujo de medios puede comenzar antes de que se designen los candidatos. El SBC debe admitir el envío de multifrecuencia de doble tono (DTMF) durante esta fase para habilitar escenarios de correo de voz o IVR. El CLS debe usar la ruta de acceso de prioridad más alta en la que recibe comprobaciones, si no se completan las designaciones.

Pasos siguientes

Artículos relacionados

• Más información sobre los tipos de llamadas
• Más información sobre la arquitectura de cliente-servidor
• Más información sobre las topologías de flujo de llamadas