Compartir a través de

Canal de datos

  • Artículo

Nota:

En este documento se profundiza en la característica Canal de datos presente en el SDK de llamadas de Azure Communication Services. Aunque Canal de datos en este contexto tenga cierta similitud con el elemento Canal de datos de WebRTC, es fundamental reconocer las diferencias sutiles de sus detalles. En este documento, usamos los términos API de Canal de datos o API para hacer referencia a la API de Canal de datos del SDK. Para hacer referencia a la API de Canal de datos de WebRTC, usamos explícitamente el término API de Canal de datos de WebRTC para mayor claridad y precisión.

La API de Canal de datos permite la mensajería en tiempo real durante las llamadas de audio y vídeo. Con esta API, ahora puede integrar fácilmente las funcionalidades de intercambio de datos en las aplicaciones, lo que proporcionará una experiencia de comunicación perfecta para los usuarios. Entre las características principales se incluyen:

  • Mensajería en tiempo real: la API de Canal de datos permite a los usuarios enviar y recibir mensajes al instante durante una llamada de audio o vídeo, lo que promueve una comunicación fluida y eficaz. En escenarios de llamadas grupales, los mensajes se pueden enviar a un solo participante, a un conjunto específico de participantes o a todos los participantes de la llamada. Esta flexibilidad mejora la comunicación y la colaboración entre los usuarios durante las interacciones grupales.
  • Comunicación unidireccional: a diferencia de la comunicación bidireccional, la API de Canal de datos está diseñada para la comunicación unidireccional. Emplea objetos distintos para enviar y recibir mensajes: el objeto DataChannelSender para enviar y el objeto DataChannelReceiver para recibir. Esta separación simplifica la administración de mensajes en las llamadas grupales, lo que conduce a una experiencia de usuario más simplificada.
  • Compatibilidad con datos binarios: la API admite el envío y la recepción de datos binarios, lo que permite el intercambio de diversos tipos de datos, como texto, imágenes y archivos. Los mensajes de texto se deben serializar en un búfer de bytes para que se puedan transmitir.
  • Opciones de emisor: la API del Canal de datos proporciona tres opciones configurables al crear un objeto emisor, que corresponden a la confiabilidad, la prioridad y la velocidad de bits. Estas opciones permiten que la configuración de un canal satisfaga necesidades específicas para distintos casos de uso.
  • Seguridad: todos los mensajes intercambiados entre un cliente y el otro punto de conexión se cifran, lo que garantiza la privacidad y la seguridad de los datos de los usuarios.

Casos de uso comunes

La característica Canal de datos se puede usar en muchos escenarios diferentes. Estos son dos ejemplos comunes de casos de uso:

Mensajería entre participantes de una llamada

La API de Canal de datos permite la transmisión de mensajes de tipo binario entre los participantes de la llamada. Con la serialización adecuada en la aplicación, puede entregar varios tipos de mensajes con distintos fines. También hay otras bibliotecas o servicios que proporcionan las funcionalidades de mensajería. Cada método tiene sus ventajas e inconvenientes. Debe elegir el adecuado para su escenario de uso. Por ejemplo, la API de Canal de datos ofrece la ventaja de la comunicación de baja latencia y simplifica la administración de usuarios, ya que no es necesario mantener una lista de participantes independiente. Sin embargo, la característica Canal de datos no proporciona persistencia de mensajes y no garantiza que el mensaje no se pierda de un extremo a otro. Si necesita la mensajería con estado o la entrega garantizada, puede considerar soluciones alternativas.

Uso compartido de archivos

El uso compartido de archivos representa otros casos de uso comunes de la API de Canal de datos. En un escenario de llamada de punto a punto, la conexión de Canal de datos funciona de punto a punto. Esta configuración ofrece un método eficaz para la transferencia de archivos, y aprovecha al máximo la conexión directa de punto a punto para mejorar la velocidad y reducir la latencia.

En un escenario de llamada grupal, los archivos se pueden compartir igualmente entre los participantes. Sin embargo, hay mejores formas, como Azure Storage o Azure Files. Además, la difusión del contenido del archivo a todos los participantes de una llamada se puede lograr estableciendo una lista de participantes vacía. Sin embargo, es importante tener en cuenta que, además de las limitaciones de ancho de banda, hay más restricciones impuestas durante una llamada grupal a la hora de difundir mensajes, como la velocidad de paquetes y la contrapresión de la velocidad de bits de recepción.

Conceptos clave

Comunicación unidireccional

La API de Canal de datos está diseñada para la comunicación unidireccional, a diferencia de la comunicación bidireccional de Canal de datos de WebRTC. Emplea objetos independientes para enviar y recibir mensajes: el objeto DataChannelSender es el responsable de enviar mensajes y el objeto DataChannelReceiver, de recibirlos.

El desacoplamiento de los objetos del emisor y del receptor simplifica el manejo de mensajes en escenarios de llamadas grupales, lo que ofrece una experiencia más ágil y sencilla.

Canal

Cada mensaje de Canal de datos está asociado a un canal específico identificado por channelId. Es importante aclarar que este objeto channelId no está relacionado con la propiedad id de Canal de datos de WebRTC. Este objeto channelId se puede usar para diferenciar varios usos de aplicaciones, como usar 1000 para los mensajes de control y 1001 para las transferencias de imágenes.

El objeto channelId se asigna durante la creación de un objeto DataChannelSender y lo puede especificar el usuario o determinarlo el SDK si no se especifica.

El intervalo válido de un objeto channelId se encuentra entre 1 y 65535. Si se proporciona un objeto channelId 0 o si no se proporciona ninguno, el SDK asignará uno disponible en el intervalo válido.

Confiabilidad

Tras la creación, se puede configurar un canal para que sea una de las dos opciones de confiabilidad: lossy o durable.

Un canal de lossy significa que no se garantiza el orden de los mensajes y se puede quitar un mensaje silenciosamente cuando se produzca un error en el envío. Por lo general, ofrece una velocidad de transferencia de datos más rápida.

Un canal de durable significa que el SDK garantiza una entrega de mensajes sin pérdida y ordenada. En los casos en los que no se pueda entregar un mensaje, el SDK producirá una excepción. En el SDK web, la durabilidad del canal se garantiza a través de una conexión SCTP confiable. Sin embargo, no implica que el mensaje no se pierda de un extremo a otro. En el contexto de una llamada grupal, significa la prevención de la pérdida de mensajes entre el emisor y el servidor. En una llamada de punto a punto, denota una transmisión confiable entre el emisor y el punto de conexión remoto.

Nota:

En la implementación actual del SDK web, la transmisión de datos se realiza a través de una conexión confiable de Canal de datos de WebRTC para los canales lossy y durable.

Prioridad

Tras la creación, se puede configurar un canal para que sea una de las dos opciones de prioridad: normal o high.

Para el SDK web, la configuración de prioridad solo se compara entre los canales del lado emisor. Los canales con una prioridad high tienen mayor prioridad para la transmisión en comparación con los que tienen una prioridad normal.

Bitrate

Al crear un canal, se puede especificar una velocidad de bits deseable para la asignación de ancho de banda.

Esta propiedad Bitrate sirve para notificar al SDK el requisito de ancho de banda esperado para un caso de uso particular. Aunque el SDK generalmente no pueda coincidir con la velocidad de bits exacta, intenta dar cabida a la solicitud.

Sesión

La API de Data Channel presenta el concepto de una sesión, que se adhiere a la semántica de apertura y cierre. En el SDK, la sesión está asociada al objeto emisor o receptor.

Al crear un objeto emisor con un nuevo elemento channelId, el objeto emisor se encuentra en estado abierto. Si se invoca la API close() en el objeto emisor, la sesión se cierra y ya no puede facilitar el envío de mensajes. Al mismo tiempo, el objeto emisor notifica a todos los participantes de la llamada que se cierra la sesión.

Si se crea un objeto emisor con un elemento channelId ya existente, se cerrará el objeto emisor existente asociado al channelId y se reconocerán los mensajes enviados desde el objeto emisor recién creado como parte de la nueva sesión.

Desde la perspectiva del receptor, los mensajes procedentes de diferentes sesiones del lado del emisor se dirigen a distintos objetos receptores. Si el SDK identifica una nueva sesión asociada a un channelId existente en el lado del receptor, creará un objeto receptor. El SDK no cierra el objeto receptor anterior; dicho cierre tiene lugar 1) cuando el objeto receptor recibe una notificación de cierre del emisor o 2) si la sesión no ha recibido ningún mensaje del emisor durante más de dos minutos.

En instancias en las que se cierre la sesión de un objeto receptor y no existe ninguna nueva sesión para el mismo channelId en el lado del receptor, el SDK creará un nuevo objeto receptor tras recibir un mensaje de la misma sesión más adelante. Sin embargo, si existe una nueva sesión para el mismo channelId en el lado del receptor, el SDK descartará los mensajes entrantes de la sesión anterior.

Teniendo en cuenta que el objeto receptor se cierra si no recibe mensajes durante más de dos minutos, se recomienda que la aplicación envíe periódicamente mensajes de mantenimiento desde el lado del emisor para mantener el estado activo del objeto receptor.

Número de secuencia

El número de secuencia es un entero de 32 bits sin signo incluido en el mensaje de Canal de datos para indicar el orden de los mensajes dentro de un canal. Es importante tener en cuenta que este número se genera desde la perspectiva del emisor. Por lo tanto, un receptor puede observar un hueco en los números de secuencia si el emisor modifica los destinatarios durante el envío de mensajes.

Por ejemplo, considere un escenario en el que un emisor envía tres mensajes. Inicialmente, los destinatarios son Participante A y Participante B. Después del primer mensaje, el emisor cambia el destinatario al participante B y, antes del tercer mensaje, el destinatario se cambia al participante A. En este caso, el participante A recibirá dos mensajes con números de secuencia 1 y 3. Sin embargo, esto no significa una pérdida de mensajes, sino que solo refleja el cambio en los destinatarios por el emisor.

Limitaciones

Tamaño del mensaje

El tamaño máximo permitido para un solo mensaje es de 32 KB. Si necesita enviar datos mayores que el límite, deberá dividir los datos en varios mensajes.

Lista de participantes

El número máximo de participantes de una lista está limitado a 64. Si quiere especificar más participantes, deberá administrar la lista de participantes por su cuenta. Por ejemplo, si quiere enviar un mensaje a 50 participantes, puede crear dos canales diferentes, cada uno con 25 participantes en sus listas de destinatarios. Al calcular el límite, se contarán dos puntos de conexión con el mismo identificador de participante como entidades independientes. Como alternativa, podría optar por difundir mensajes. Sin embargo, se aplican ciertas restricciones a la hora de difundir mensajes.

Limitación de frecuencia

Actualmente, el SDK de llamada tiene una limitación de velocidad implementada, lo que impide que los usuarios envíen datos a una velocidad más alta incluso aunque su red lo permita. Los máximos de velocidad de ancho de banda actuales para el canal de datos son los siguientes:

  • Canal confiable (duradero): 64 kbps
  • Canal no confiable (con pérdida): 512 kbps
  • Canal de prioridad alta no confiable: 200 kbps

Sin embargo, al difundir mensajes, el límite de velocidad de bits de envío es dinámico y depende de la velocidad de bits de recepción. En la implementación actual, el límite de velocidad de bits de envío es el resultado de la velocidad de bits de envío máxima menos el 80 % de la velocidad de bits de recepción.

Además, también aplicamos una restricción de velocidad de paquetes al enviar mensajes de difusión. El límite actual se establece en 80 paquetes por segundo, donde cada 1200 bytes en un mensaje se cuentan como un paquete. Estas medidas existen para evitar inundaciones de red cuando haya un número significativo de participantes en una llamada grupal transmitiendo mensajes.

Pasos siguientes

Para más información, consulte los siguientes artículos.