Canal de données

L’API De canal de données active la messagerie en temps réel pendant les appels audio et vidéo. Avec cette API, vous pouvez désormais facilement intégrer des fonctionnalités d’échange de données dans les applications, ce qui offre une expérience de communication transparente pour les utilisateurs. Les principales fonctionnalités incluent :

• Messagerie en temps réel : l'API Data Channel permet aux utilisateurs d'envoyer et de recevoir instantanément des messages lors d'un appel audio ou vidéo en cours, favorisant ainsi une communication fluide et efficace. Dans les scénarios d’appel de groupe, les messages peuvent être envoyés à un seul participant, à un ensemble spécifique de participants ou à tous les participants au sein de l’appel. Cette flexibilité améliore la communication et la collaboration entre les utilisateurs pendant les interactions de groupe.
• Communication unidirectionnelle : contrairement à la communication bidirectionnelle, l’API Data Channel est conçue pour la communication unidirectionnelle. Il utilise des objets distincts pour l’envoi et la réception de messages : l’objet DataChannelSender pour l’envoi et l’objet DataChannelReceiver pour la réception. Cette séparation simplifie la gestion des messages dans les appels de groupe, ce qui entraîne une expérience utilisateur plus simplifiée.
• Prise en charge des données binaires : l’API prend en charge l’envoi et la réception de données binaires, ce qui permet l’échange de différents types de données, tels que du texte, des images et des fichiers. Les messages texte doivent être sérialisés dans une mémoire tampon d’octets avant de pouvoir être transmis.
• Options de l’expéditeur : l’API de canal de données fournit trois options configurables lors de la création d’un objet expéditeur, notamment la fiabilité, la priorité et le débit binaire. Ces options permettent à la configuration d’un canal de répondre à des besoins spécifiques pour différents cas d’usage.
• Sécurité : tous les messages échangés entre un client et l’autre point de terminaison sont chiffrés, garantissant ainsi la confidentialité et la sécurité des données des utilisateurs.

Cas d’utilisation courants

Le canal de données peut être utilisé dans de nombreux scénarios différents. Deux exemples de cas d’usage courants sont les suivants :

Messagerie entre les participants à un appel

L’API De canal de données permet la transmission de messages de type binaire entre les participants aux appels. Avec la sérialisation appropriée dans l’application, elle peut fournir différents types de messages à des fins différentes. Il existe également d’autres bibliothèques ou services fournissant les fonctionnalités de messagerie. Chacun d’entre eux présente ses avantages et ses inconvénients. Vous devez choisir celui qui convient à votre scénario d’utilisation. Par exemple, l’API De canal de données offre l’avantage de la communication à faible latence et simplifie la gestion des utilisateurs, car il n’est pas nécessaire de conserver une liste de participants distincte. Toutefois, la fonctionnalité de canal de données ne fournit pas de persistance des messages et ne garantit pas que le message ne sera pas perdu de manière de bout en bout. Si vous avez besoin de la messagerie avec état ou de la remise garantie, vous pouvez envisager d’autres solutions.

Partage de fichiers

Le partage de fichiers représente un autre cas d’usage courant pour l’API De canal de données. Dans un scénario d'appel peer-to-peer, la connexion Data Channel fonctionne sur une base peer-to-peer. Cette configuration offre une méthode efficace de transfert de fichiers, tirant pleinement parti de la connexion directe peer-to-peer pour améliorer la vitesse et réduire la latence.

Dans un scénario d’appel de groupe, les fichiers peuvent toujours être partagés entre les participants. Toutefois, il existe de meilleures façons, telles que stockage Azure ou Azure Files. En outre, la diffusion du contenu du fichier à tous les participants d’un appel peut être effectuée en définissant une liste de participants vide. Toutefois, il est important de garder à l’esprit qu’en plus des limitations de bande passante, il existe d’autres restrictions imposées lors d’un appel de groupe lors de la diffusion de messages, tels que le débit de paquets et la pression arrière de la vitesse de réception.

Concepts clés

Communication unidirectionnelle

L’API Data Channel est conçue pour la communication unidirectionnelle, par opposition à la communication bidirectionnelle dans le canal de données WebRTC. Il utilise des objets distincts pour l’envoi et la réception de messages, avec l’objet DataChannelSender responsable de l’envoi de messages et de l’objet DataChannelReceiver pour la réception de messages.

Le découplage des objets expéditeur et récepteur simplifie la gestion des messages dans les scénarios d’appel de groupe, ce qui offre une expérience plus simplifiée et conviviale.

Canal

Chaque message de canal de données est associé à un canal spécifique identifié par channelId. Il est important de préciser que ce ChannelId n'est pas lié à la propriété id du canal de données WebRTC. Ce ChannelId peut être utilisé pour différencier diverses utilisations d'applications, telles que l'utilisation de 1000 pour les messages de contrôle et de 1001 pour les transferts d'images.

Le ChannelId est attribué lors de la création d'un objet DataChannelSender et peut être spécifié par l'utilisateur ou déterminé par le SDK s'il n'est pas spécifié.

La plage valide d’un ChannelId est comprise entre 1 et 65 535. Si un ChannelId 0 est fourni, ou si aucun ChannelId n'est fourni, le SDK attribue un ChannelId disponible dans la plage valide.

Fiabilité

Lors de la création, un canal peut être configuré pour être l’une des deux options de fiabilité : lossy ou durable.

Un canal lossy signifie que l’ordre des messages n’est pas garanti et qu’un message peut être supprimé en mode silencieux lors de l’envoi échoue. Il offre généralement une vitesse de transfert de données plus rapide.

Un canal durable signifie que le SDK garantit une remise de messages sans perte et ordonnée. Dans les cas où un message ne peut pas être remis, le Kit de développement logiciel (SDK) lève une exception. Dans le Kit de développement logiciel (SDK) Web, la durabilité du canal est assurée par le biais d’une connexion SCTP fiable. Toutefois, il n’implique pas que le message ne soit pas perdu de manière de bout en bout. Dans le contexte d’un appel de groupe, cela signifie la prévention de la perte de messages entre l’expéditeur et le serveur. Dans un appel peer-to-peer, cela désigne une transmission fiable entre l'expéditeur et le point final distant.

Priorité

Lors de la création, un canal peut être configuré pour être l’une des deux options prioritaires : normal ou high.

Pour le Kit de développement logiciel (SDK) Web, les paramètres de priorité ne sont comparés qu’entre les canaux côté expéditeur. Les canaux ayant une priorité high sont prioritaires pour la transmission par rapport à ceux dont la priorité est normal.

Bitrate

Lors de la création d’un canal, une vitesse de transmission souhaitable peut être spécifiée pour l’allocation de bande passante.

Cette propriété de vitesse de transmission est de notifier le Kit de développement logiciel (SDK) de l’exigence de bande passante attendue pour un cas d’usage particulier. Bien que le KIT de développement logiciel (SDK) ne corresponde généralement pas au débit binaire exact, il tente de prendre en charge la requête.

Session

L’API De canal de données introduit le concept d’une session, qui respecte la sémantique de fermeture ouverte. Dans le Kit de développement logiciel (SDK), la session est associée à l’expéditeur ou à l’objet récepteur.

Lors de la création d'un objet expéditeur avec un nouveau ChannelId, l'objet expéditeur est à l'état ouvert. Si l’API close() est appelée sur l’objet expéditeur, la session devient fermée et ne peut plus faciliter l’envoi de messages. En même temps, l’objet expéditeur avertit tous les participants de l’appel que la session est fermée.

Si un objet expéditeur est créé avec un ChannelId déjà existant, l'objet expéditeur existant associé au ChannelId sera fermé et tous les messages envoyés à partir de l'objet expéditeur nouvellement créé seront reconnus comme faisant partie de la nouvelle session.

Du point de vue du destinataire, les messages provenant de différentes sessions du côté de l’expéditeur sont dirigés vers des objets récepteur distincts. Si le SDK identifie une nouvelle session associée à un identifiant de canal existant du côté du récepteur, il crée un nouvel objet récepteur. Le SDK ne ferme pas l’ancien objet récepteur ; une telle fermeture a lieu 1) lorsque l'objet récepteur reçoit une notification de fermeture de l'expéditeur, ou 2) si la session n'a reçu aucun message de l'expéditeur depuis plus de deux minutes.

Dans les cas où la session d'un objet récepteur est fermée et qu'aucune nouvelle session pour le même identifiant de canal n'existe du côté du récepteur, le SDK crée un nouvel objet récepteur lors de la réception ultérieure d'un message de la même session. Toutefois, si une nouvelle session pour le même ChannelId existe du côté du destinataire, le SDK ignore tous les messages entrants de la session précédente.

Étant donné que l’objet récepteur se ferme s’il ne reçoit pas de messages pendant plus de deux minutes, nous vous suggérons que l’application envoie régulièrement des messages de conservation actif du côté de l’expéditeur pour conserver l’état actif de l’objet récepteur.

Numéro de séquence

Le numéro de séquence est un entier non signé 32 bits inclus dans le message du canal de données pour indiquer l’ordre des messages au sein d’un canal. Il est important de noter que ce nombre est généré du point de vue de l’expéditeur. Par conséquent, un destinataire peut remarquer un écart dans les numéros de séquence si l’expéditeur modifie les destinataires lors de l’envoi de messages.

Par exemple, envisagez un scénario dans lequel un expéditeur envoie trois messages. Initialement, les destinataires sont le participant A et le participant B. Après le premier message, l’expéditeur change le destinataire au participant B et avant le troisième message, le destinataire est redirigé vers le participant A. Dans ce cas, le participant A reçoit deux messages avec des numéros de séquence 1 et 3. Toutefois, cela ne signifie pas une perte de message, mais reflète uniquement la modification des destinataires par l’expéditeur.

Limites

Taille des messages

La taille maximale autorisée d’un message unique est de 32 Ko. Si vous devez envoyer des données supérieures à la limite, vous devez diviser les données en plusieurs messages.

Liste des participants

Le nombre maximal de participants dans une liste est limité à 64. Si vous souhaitez spécifier d’autres participants, vous devez gérer la liste des participants par vous-même. Par exemple, si vous souhaitez envoyer un message à 50 participants, vous pouvez créer deux canaux différents, chacun avec 25 participants dans leurs listes de destinataires. Lors du calcul de la limite, deux points de terminaison avec le même identificateur de participant sont comptabilisés comme entités distinctes. En guise d’alternative, vous pouvez choisir de diffuser des messages. Toutefois, certaines restrictions s’appliquent lors de la diffusion de messages.

Limitation du débit

Actuellement, le SDK appelant a une limitation de débit implémentée, ce qui empêche les utilisateurs d’envoyer des données à une vitesse plus élevée même si leur réseau l’autorise. Les débits de bande passante actuels pour le canal de données sont les suivants :

• Canal fiable (durable) : 64 Kbits/s
• Canal non fiable (perte) : 512 kbits/s
• Canal non fiable à priorité élevée : 200 kbit/s

Toutefois, lors de la diffusion de messages, la limite de vitesse de transmission est dynamique et dépend du débit de réception. Dans l’implémentation actuelle, la limite de débit d’envoi est calculée en tant que vitesse de transmission maximale moins 80 % du débit de réception.

En outre, nous appliquons également une restriction de débit de paquets lors de l’envoi de messages de diffusion. La limite actuelle est définie à 80 paquets par seconde, où tous les 1200 octets d’un message sont comptabilisés comme un paquet. Ces mesures sont en place pour prévenir les inondations lorsqu’un nombre important de participants à un appel de groupe diffusent des messages.

Étapes suivantes

Pour plus d’informations, consultez les articles suivants :

• En savoir plus sur QuickStart – Ajouter un canal de données à votre application d'appel
• En savoir plus sur les fonctionnalités du kit de développement logiciel (SDK) d’appel