Partager via

Problèmes connus des kits de développement logiciel (SDK) d’appel WebJS dans Azure Communication Services

  • Article

Cet article présente les problèmes connus liés à l’utilisation du Kit de développement logiciel (SDK) d’appel WebJS dans Azure Communication Services.

Tous les navigateurs d’ordinateurs de bureau

Il n’est pas possible d’afficher plusieurs préversions à partir de plusieurs appareils sur le Web

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : il n’est pas possible d’afficher plusieurs préversions à partir de plusieurs appareils sur le Web. Il s’agit d’une limitation connue.
Référence du problème connu : pour plus d’informations, consultez la rubrique Vue d’ensemble du SDK d’appel.

La commutation répétée entre différents appareils vidéo peut entraîner l’arrêt temporaire du streaming vidéo

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : la commutation entre différents périphériques vidéo peut entraîner une interruption de votre flux vidéo pendant la récupération de ce dernier à partir du périphérique sélectionné. La commutation fréquente entre plusieurs appareils risque de détériorer les performances.
Solution recommandée : les développeurs doivent veiller à interrompre le flux d’un appareil avant d’en lancer un autre afin de limiter les pertes de performances lors du passage d’un périphérique vidéo à un autre.

Problème de signal vidéo lorsque l’appel est en état Connexion en cours

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : si un utilisateur active et désactive rapidement la vidéo alors que l’appel est en cours de connexion, cela peut entraîner un problème avec le flux acquis pour l’appel. Il est conseillé aux développeurs de créer leurs applications d’une manière qui ne nécessite pas l’activation ou la désactivation de la vidéo pendant que l’appel est à l’état Connexion en cours. Des performances vidéo dégradées peuvent se produire dans les scénarios suivants :

  • Si l’utilisateur commence par l’audio, puis démarre et arrête la vidéo pendant que l’appel est à l’état Connexion en cours.
  • Si l’utilisateur commence par l’audio, puis démarre et arrête la vidéo pendant que l’appel est à l’état Salle d’attente.

Délai de rendu de la vidéo des participants à distance

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : pendant un appel de groupe, supposons que l’utilisateur A envoie du contenu vidéo, puis que l’utilisateur B rejoint l’appel. Parfois, l’utilisateur B ne voit pas la vidéo de l’utilisateur A, ou le rendu de la vidéo de l’utilisateur A ne commence qu’après un long délai. Un problème de configuration de l’environnement réseau peut être à l’origine de ce délai.
Référence du problème connu : pour plus d’informations, consultez la rubrique Recommandations de réseau.

L’utilisation excessive de certaines API, telles que désactiver le micro/réactiver le micro, entraîne une limitation sur l’infrastructure Azure Communication Services

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : à la suite de l’appel de l’API désactiver le micro/réactiver le micro, l’infrastructure Azure Communication Services informe les autres participants à l’appel de l’état audio du participant local qui a déclenché désactiver le micro/réactiver le micro, afin que les participants de l’appel sachent qui a son micro désactivé/activé.

L’utilisation excessive de la fonction désactiver le micro/réactiver le micro est bloquée dans l’infrastructure Azure Communication Services. La limitation se produit si le participant (ou l’application au nom du participant) tente de désactiver/réactiver le micro en continu, toutes les secondes, plus de 15 fois dans une fenêtre mobile de 30 secondes.

L’activation de Siri pendant un appel WebRTC ne coupe pas automatiquement le microphone sur macOS

Système d’exploitation (OS) : macOS.
Navigateurs : Tous les navigateurs et versions.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Services : Tout.
Description : Appel WebRTC n’est pas automatiquement désactivé lorsqu’un utilisateur commence à parler avec Siri au milieu de l’appel. Dans ces cas-là, les autres participants peuvent entendre soit l’utilisateur donner des ordres à Siri, soit l’ordre donné et la réponse de Siri.
Référence de problème connu : il s’agit d’un problème connu sur macOS.
Solution recommandée : Aucune solution n’est actuellement disponible. Les utilisateurs doivent couper manuellement leur microphone lorsqu’ils activent Siri pendant un appel.

Chevauchement de l’audio dans les appels ACS WebJS et FaceTime sur macOS

Système d’exploitation (OS) : macOS.
Navigateurs : Tous les navigateurs et versions.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Services : Tout.
Description : Lorsqu’un utilisateur macOS engagé dans un appel ACS WebJS reçoit un appel FaceTime et l’accepte, les parties audio de l’appel WebJS ACS et de l’appel FaceTime sont transmises et reçues simultanément. Cela entraîne le chevauchement des flux audio, et l’utilisateur peut entendre et être entendu sur les deux appels en même temps.
Référence de problème connu : il s’agit d’un problème connu sur macOS.
Solution recommandée : Aucune solution n’est actuellement disponible. Les utilisateurs peuvent désactiver de manière proactive leur microphone dans l’appel WebRTC ou quitter l’appel WebRTC avant de prendre l’appel FaceTime.

Tous les navigateurs mobiles

Il n’est pas possible d’afficher plusieurs préversions à partir de plusieurs appareils sur le Web

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : il n’est pas possible d’afficher plusieurs préversions à partir de plusieurs appareils sur le Web. Il s’agit d’une limitation connue.
Référence du problème connu : pour plus d’informations, consultez la rubrique Vue d’ensemble du SDK d’appel.

La commutation répétée entre différents appareils vidéo peut entraîner l’arrêt temporaire du streaming vidéo

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : la commutation entre différents périphériques vidéo peut entraîner une interruption de votre flux vidéo pendant la récupération de ce dernier à partir du périphérique sélectionné. La commutation fréquente entre plusieurs appareils risque de détériorer les performances.
Solution recommandée : les développeurs doivent veiller à interrompre le flux d’un appareil avant d’en lancer un autre afin de limiter les pertes de performances lors du passage d’un périphérique vidéo à un autre.

Problème de signal vidéo lorsque l’appel est en état Connexion en cours

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : si un utilisateur active et désactive rapidement la vidéo alors que l’appel est en cours de connexion, cela peut entraîner un problème avec le flux acquis pour l’appel. Il est conseillé aux développeurs de créer leurs applications d’une manière qui ne nécessite pas l’activation ou la désactivation de la vidéo pendant que l’appel est à l’état Connexion en cours. Des performances vidéo dégradées peuvent se produire dans les scénarios suivants :

  • Si l’utilisateur commence par l’audio, puis démarre et arrête la vidéo pendant que l’appel est à l’état Connexion en cours.
  • Si l’utilisateur commence par l’audio, puis démarre et arrête la vidéo pendant que l’appel est à l’état Salle d’attente.

Délai de rendu de la vidéo des participants à distance

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : pendant un appel de groupe, supposons que l’utilisateur A envoie du contenu vidéo, puis que l’utilisateur B rejoint l’appel. Parfois, l’utilisateur B ne voit pas la vidéo de l’utilisateur A, ou le rendu de la vidéo de l’utilisateur A ne commence qu’après un long délai. Un problème de configuration de l’environnement réseau peut être à l’origine de ce délai.
Référence du problème connu : pour plus d’informations, consultez la rubrique Recommandations de réseau.

L’utilisation excessive de certaines API, telles que désactiver le micro/réactiver le micro, entraîne une limitation sur l’infrastructure Azure Communication Services

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes
Description : à la suite de l’appel de l’API désactiver le micro/réactiver le micro, l’infrastructure Azure Communication Services informe les autres participants à l’appel de l’état audio du participant local qui a déclenché désactiver le micro/réactiver le micro, afin que les participants de l’appel sachent qui a son micro désactivé/activé.

L’utilisation excessive de la fonction désactiver le micro/réactiver le micro est bloquée dans l’infrastructure Azure Communication Services. La limitation se produit si le participant (ou l’application au nom du participant) tente de désactiver/réactiver le micro en continu, toutes les secondes, plus de 15 fois dans une fenêtre mobile de 30 secondes.

L’actualisation d’une page ne retire pas immédiatement l’utilisateur de l’appel

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : si un utilisateur participe à un appel et décide d’actualiser la page, le service multimédia de Communication Services ne retire pas immédiatement cet utilisateur de l’appel. Il attend que l’utilisateur rejoigne l’appel. L’utilisateur sera retiré de l’appel après l’expiration du délai d’attente du service multimédia.

Si un utilisateur participe à un appel et décide d’actualiser la page, le service multimédia de Communication Services ne retire pas cet utilisateur immédiatement de l’appel. Il attend que l’utilisateur rejoigne l’appel. L’utilisateur sera retiré de l’appel après l’expiration du délai d’attente du service multimédia.

Il est préférable de créer des expériences utilisateur qui ne nécessitent pas que les utilisateurs finaux actualisent la page de votre application pendant un appel. Si un utilisateur actualise la page, réutilisez le même ID utilisateur de Communication Services lorsque cet utilisateur retourne à l’application. En se joignant avec le même ID utilisateur, l’utilisateur est représenté comme le même objet existant dans la collection remoteParticipants. Du point de vue des autres participants à l’appel, l’utilisateur reste connecté à l’appel pendant le temps nécessaire à l’actualisation de la page, jusqu’à une minute ou deux.

Si l’utilisateur était en train d’envoyer une vidéo avant l’actualisation de la page, la collection videoStreams conserve les informations de flux précédentes jusqu’à ce que le service expire et le retire de l’appel. Dans ce scénario, l’application peut décider d’observer les nouveaux flux ajoutés à la collection et d’en afficher une avec l’id le plus élevé.

Safari sur ordinateurs de bureau

Sur macOS Safari 18 et ultérieur, l’utilisateur ne peut pas partager l’écran pendant environ 1 minute après l’annulation de l’action dans un appel. Pendant ce temps, certaines des options ne fonctionnent pas pendant la récupération du partage d’écran.

Version du navigateur : Safari 18 et ultérieur.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : après l’annulation d’une tentative de partage d’écran, l’utilisateur ne peut pas recommencer à partager l’écran pendant environ 1 minute. Pendant cette période, certaines options ne répondent pas, comme la possibilité d’activer/désactiver la caméra. Après environ 1 minute, l’utilisateur peut démarrer le partage d’écran et utiliser à nouveau toutes les options disponibles dans l’appel.
Référence du problème connu : cette régression est un problème connu qui a été constaté sur Safari.
Solution de contournement recommandée : il est recommandé d’éviter d’utiliser l’option « Annuler » pendant le “partage d’écran pour éviter des délais d’attente lors du redémarrage du partage d’écran. Si le partage doit être arrêté, il est recommandé de mettre fin à l’action de partage ou d’attendre la fin du temps de récupération avant de réessayer.

Sur macOS Safari 17 et versions ultérieures, l’audio peut être interrompu si les utilisateurs macOS connectent des écouteurs Bluetooth pendant un appel

Version du navigateur : Safari 17 et versions ultérieures.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : lorsque les utilisateurs macOS connectent des écouteurs Bluetooth à un MacBook pendant un appel sur Safari, ils peuvent rencontrer des problèmes avec l’audio. Dans les deux cas d’usage où les utilisateurs connectent des écouteurs Bluetooth avant ou pendant l’appel, l’audio entrant et sortant peut être indisponible ou interrompu. Il est noté que l’attente d’au moins 30 secondes peut résoudre le problème audio entrant, mais la récupération de l’audio sortant échoue souvent.
Référence du problème connu : cette régression est un problème connu qui a été constaté sur Safari.
Solution de contournement recommandée : comme solution temporaire, les utilisateurs peuvent avoir besoin de reconnecter leur appareil Bluetooth ou d’actualiser l’appel pour tenter la récupération de l’audio. La mise à niveau vers la dernière version de macOS et Safari peut également aider, car elle peut inclure des correctifs potentiels pour ces problèmes.

Sur macOS Safari 17 et les versions plus récentes, les effets d’arrière-plan vidéo peuvent provoquer un flash de la vidéo, tant sur l’aperçu local que sur la partie distante

Version du navigateur : Safari 17 et versions ultérieures.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : un bug a été détecté dans l’une des mises à jour de macOS Safari 17. Il provoque un saut d’images dans l’implémentation des effets d'arrière-plan de la capture d’images et peut donc provoquer un flash de la vidéo tant sur l’aperçu local que sur la partie distante.

  • Un correctif est disponible à partir de Safari version 17.5 (macOS Sonoma 14.5).

Solution de contournement recommandée : les utilisateurs sont invités à effectuer une mise à jour vers la dernière version de macOS et de Safari (au moins v.17.5) dans lesquelles ce problème a été résolu.

La vidéo entrante et sortante clignote sur macOS Sonoma avec les versions de Safari allant jusqu’à 17.1

Version du navigateur : Safari v17.0, v17.1 (macOS Sonoma 14).
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : les utilisateurs sur macOS Sonoma 14.0 rencontrent un problème de clignotement vidéo dans les versions 17.0 et 17.1 de Safari lorsqu’ils rejoignent un appel avec la vidéo activée. La vidéo entrante clignote lorsqu’un utilisateur de Safari rejoint un appel, affectant ce qui est reçu d’autres participants à l’appel. En outre, la vidéo sortante de l’utilisateur de Safari clignote pour les participants distants déjà dans l’appel. Ce problème impacte la qualité visuelle de l’appel.

  • Un correctif est disponible à partir de Safari version 17.2.

Solution de contournement recommandée : les utilisateurs sont invités à effectuer une mise à jour vers la dernière version de macOS et de Safari (au moins v17.2) dans lesquelles ce problème a été résolu.

L’autre participant à l’appel ne peut pas démarrer le partage d’écran simultanément avec un utilisateur de macOS Safari dans les appels vidéo 1:1 Azure Communication Services

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : Dans les appels vidéo 1:1 Azure Communication Services, lorsqu’un utilisateur de macOS Safari partage son écran, un autre participant utilisant un autre navigateur ne peut pas démarrer le partage d’écran tant que le premier participant n’a pas arrêté son partage d’écran. Cette limitation est observée dans différentes combinaisons de navigateurs et de systèmes d’exploitation, mais elle est propre aux appels 1:1. Le problème ne se produit pas dans les appels où les deux participants utilisent Safari sur macOS.
Référence du problème connu : cette régression est un problème connu qui a été constaté sur Safari.
Solution de contournement recommandée : Une solution de contournement temporaire consiste à s’assurer qu’un seul participant à la fois partage son écran dans les appels vidéo 1:1 Azure Communication Services, lorsque l’un des participants utilise macOS Safari.

Le partage d’écran ne fonctionne pas sur macOS Ventura avec les versions de Safari allant jusqu’à 16.3

Version du navigateur : Safari v16.1, v16.2, v16.3 (macOS Ventura 13.0).
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : le problème a été introduit dans macOS Ventura 13.0 lors de l’utilisation du navigateur Safari (v16.1, v16.2 et v16.3), et un correctif est disponible depuis la version 16.4 de Safari.
Référence du problème connu : cette régression est un problème connu qui a été constaté sur Safari.
Solution de contournement recommandée : les utilisateurs sont invités à effectuer une mise à jour vers la dernière version de macOS et de Safari (au moins v16.4) dans lesquelles ce problème a été résolu.

Participants aux appels web entendant l’audio d’appel RTC lorsqu’ils répondent sur macOS avec l’intégration d’iPhone

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : lorsqu'un utilisateur macOS, qui participe à un appel ACS actif à l'aide d'un navigateur, accepte un appel RTC entrant sur son MacBook lié à son iPhone (à l'aide du même compte iCloud), l'audio de l'appel RTC est partagé entre les participants à l'appel web. Cela a pour conséquence que les participants à l’appel entendent l’audio de l’appel RTC.
Référence de problème connu : il s’agit d’un problème connu sur macOS.
Solution de contournement recommandée : actuellement, aucune solution de contournement directe n’est disponible. Les utilisateurs sont invités à utiliser des appareils distincts pour les appels RTC et les appels web afin d’empêcher ce contenu audio partagé avec d’autres participants dans un appel distinct.

Safari sur appareils mobiles iOS

Problèmes de récupération vidéo sur iOS 17+ lorsqu’un utilisateur iOS reçoit un appel entrant RTC ou d’application tierce ou active Siri pendant un appel web ACS

Version iOS : versions iOS 17 et ultérieures.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : lorsqu’un utilisateur iOS dans un appel web reçoit un appel RTC/d’application tierce et le refuse ou l’accepte, l’utilisateur rencontre des problèmes vidéo. La vidéo entrante peut apparaître figée ou aucune vidéo entrante ne s’affiche. Cela nécessite une réactivation de la caméra par l’utilisateur. De même, l’aperçu vidéo et la vidéo sortante ne parviennent pas à être récupérés à moins que l’utilisateur ne réactive sa caméra.

Problèmes vidéo sur iOS 17+ lorsqu’un utilisateur iOS tente d’utiliser Siri pendant un appel

Version iOS : versions iOS 17 et ultérieures.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : lorsqu’un utilisateur iOS tente d’activer Siri au milieu d’un appel mobile web, la vidéo entrante peut devenir figée et prendre quelques secondes avant d’être récupérée.

Problème de résolution de l’aperçu de la caméra dans les appels web lors de l’utilisation d’iOS 16.3 à 17.3.1

Version iOS : versions iOS comprises entre 16.3 et 17.3.1.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : les utilisateurs peuvent rencontrer un problème où l’aperçu de la caméra s’affiche dans une résolution incorrecte et apparaît rogné lorsque l’utilisateur iOS rejoint un appel à l’aide d’iOS Safari mobile avec la caméra activée. Le problème n’est plus observé si l’utilisateur réactive la caméra pendant l’appel. Le problème a été résolu avec iOS 17.4+.
Solution de contournement recommandée : les utilisateurs sont invités à effectuer une mise à jour vers la dernière version de iOS et de Safari (au moins iOS 17.4) dans lesquelles ce problème a été résolu.

Données de télémétrie pour audioInputLevel et frameRateInput manquantes dans les appels vidéo sur iOS 16 jusqu’à iOS 17.4

Version d’iOS : versions d’iOS de 16.0 à 17.4.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : les données de télémétrie audioInputLevel et frameRateInput ne sont pas capturées pendant les appels vidéo sur les versions 16 à 17.4 d’iOS, ce qui affecte la possibilité de surveiller et d’optimiser les paramètres audio et vidéo en temps réel. Ce problème a été résolu avec iOS 17.5+.
Solution de contournement recommandée : les utilisateurs sont invités à effectuer une mise à jour vers la dernière version d’iOS et de Safari (au moins iOS 17.5), où ce problème a été résolu.

Problème de récupération de l’audio et de la vidéo sur iOS 16 à 16.3.1 pendant les appels web avec des appels tiers ou RTC entrants

Version iOS : versions iOS 16 jusqu’à 16.3.1.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : lorsqu’un utilisateur iOS dans un appel web reçoit un appel RTC/d’application tierce, l’audio entrant et sortant et la vidéo sortante ne récupèrent pas automatiquement l’appel une fois l’appel téléphonique terminé. L’utilisateur iOS doit réactiver le son de l’appel sur le web. L’utilisateur final doit à nouveau désactiver et activer le bouton « Microphone » pour pouvoir obtenir l’audio et la vidéo.
Référence du problème connu : bogue lié à WebKit ici.
Solution de contournement recommandée : les utilisateurs sont invités à effectuer une mise à jour vers la dernière version de iOS et de Safari (au moins iOS 16.4) dans lesquelles ce problème a été résolu.

iOS 16 introduisait des bogues quand il mettait le navigateur en arrière-plan pendant un appel

Version iOS : versions iOS 16 à 16.1.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : la version iOS 16 a introduit un bug susceptible d’interrompre l’appel audio-vidéo d’Azure Communication Services lors de l’utilisation du navigateur mobile Safari. Il se peut qu’un appel Azure Communication Services cesse de fonctionner et que la seule solution pour le rétablir soit de demander au client final de redémarrer son téléphone. Pour reproduire ce bogue :

  • Assurez-vous que l’utilisateur dispose d’un iPhone exécutant iOS 16.
  • Rejoignez l’appel Azure Communication Services (avec audio uniquement ou avec audio et vidéo) à partir du navigateur mobile Safari iOS. Si, au cours d’un appel, une personne met le navigateur Safari en arrière-plan et consulte YouTube OU reçoit un appel téléphonique/FaceTime tout en étant connectée via un appareil Bluetooth, alors :
  • Après quelques minutes, le signal vidéo entrant et sortant peut cesser de fonctionner.
  • La seule façon de rétablir l’appel Azure Communication Services est de demander à l’utilisateur final de redémarrer son téléphone. Ce bug a été résolu avec iOS 16.2.

Référence du problème connu : bugs liés à WebKit ici et ici.
Solution recommandée : envisagez d’effectuer une mise à jour vers la dernière version d’iOS.

Problèmes vidéo et audio sur iPhone X, survenant lorsque l’utilisateur est en appel pendant plus de 30 minutes avec la caméra allumée

Appareils affectés : iPhone X (iOS 16.7.x).
Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : pendant les appels Azure Communication Service sur iPhone X avec iOS 16.7.x, les utilisateurs constatent la disparition de leur aperçu vidéo local et de la vidéo entrante après plus de 30 minutes d’appel avec la vidéo activée, qui peut apparaître vierge ou vide pour l’utilisateur. Pour les autres utilisateurs, la vidéo de l’utilisateur iPhone X apparaît figée au moment où elle est perdue sur l’appareil iPhone X. En plus de la disparition de la vidéo, un écho prononcé peut se produire. La vidéo se restaure lorsque l’utilisateur iPhone X éteint puis rallume la caméra.

  • Ce problème a été observé uniquement sur l’appareil iPhone X avec les versions iOS 16.7.5 et 16.7.7.

Le microphone du casque Bluetooth n’est pas détecté ou audible lors d’un appel via Safari sur iOS

Version iOS : toutes
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : les casques Bluetooth ne sont pas pris en charge par Safari sur iOS. Votre appareil Bluetooth ne figurera pas dans les options de microphone disponibles et les autres participants ne seront pas en mesure de vous entendre si vous essayez d’utiliser le Bluetooth sur Safari. Cette régression est une limitation connue du système d’exploitation. Avec Safari sur macOS et iOS/iPadOS, il n’est pas possible d’énumérer ou de sélectionner des haut-parleurs via le gestionnaire d’appareils de Communication Services. En effet, Safari ne prend pas en charge l’énumération ou la sélection de haut-parleurs.
Solution recommandée : dans ce cas de figure, utilisez le système d’exploitation pour mettre à jour la sélection de votre appareil.

L’utilisation de bibliothèques tierces pendant l’appel peut entraîner une perte audio

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : si vous utilisez getUserMedia séparément au sein de l’application, le flux audio sera perdu. Le flux audio est perdu car une bibliothèque tierce se substitue à la bibliothèque Azure Communication Services pour accéder aux périphériques.

  • N’utilisez pas de bibliothèques tierces qui utilisent l’API getUserMedia en interne pendant l’appel.
  • Si vous avez toujours besoin d’utiliser une bibliothèque tierce, la seule façon de récupérer le flux audio est de changer l’appareil sélectionné (si l’utilisateur en possède plusieurs) ou de redémarrer l’appel. Ce problème peut s’expliquer par le fait que l’acquisition de votre propre flux à partir du même périphérique a pour effet secondaire de créer une condition de concurrence. L’acquisition de flux à partir d’autres périphériques peut conduire à une bande passante d’E/S USB insuffisante, et le taux sourceUnavailableError montera en flèche.

Énumération ou accès aux périphériques pour Safari sur iOS

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : dans certains environnements, vous remarquerez peut-être que les autorisations du périphérique sont réinitialisées après un certain temps. Sur macOS et iOS, Safari ne conserve pas les autorisations pendant une longue période, à moins qu’un flux ne soit acquis. La façon la plus simple de contourner cette limitation consiste à appeler l’API DeviceManager.askDevicePermission() avant d’appeler les API d’énumération des périphériques du gestionnaire de périphériques. Ces API d’énumération incluent DeviceManager.getCameras(), DeviceManager.getSpeakers() et DeviceManager.getMicrophones(). Si les autorisations sont définies, l’utilisateur ne voit rien. Si les autorisations ne sont pas définies, l’utilisateur est à nouveau invité à demander les autorisations.

Le micro ou la caméra locale se coupe lorsque certaines interruptions se produisent sur Safari iOS

Description : ce problème peut se produire si une autre application ou si le système d’exploitation prend le contrôle du microphone ou de la caméra. Voici quelques exemples qui peuvent se produire alors qu’un utilisateur participe à un appel :

  • Un appel entrant est reçu via RTC (réseau téléphonique commuté) et il capture l’accès à l’appareil de catégorie micro.
  • Un utilisateur visionne une vidéo YouTube, par exemple, ou démarre un appel FaceTime. Le basculement vers une autre application native peut capturer l’accès au microphone ou à la caméra.
  • L’utilisateur active Siri, ce qui lui donne accès au microphone.

Sur iOS, par exemple, lors d’un appel Azure Communication Services, si un appel RTC est reçu, un UFD incorrect intitulé microphoneMutedUnenexepectedly est émis et l’audio cesse de fonctionner dans l’appel Azure Communication Services, qui est alors marqué comme étant en mode silencieux. Une fois l’appel RTC terminé, l’utilisateur doit réactiver le micro de l’appel Azure Communication Services pour que l’audio soit rétabli dans l’appel Azure Communication Services.

Si la caméra est activée et qu’une interruption se produit, l’appel Azure Communication Services peut ou non perdre la liaison avec la caméra. Si la liaison est perdue, la caméra est marquée comme désactivée et l’utilisateur doit aller la réactiver lorsque l’interruption est terminée et que la caméra est de nouveau opérationnelle.

Il arrive que les microphones ou les caméras ne soient pas remis à disposition en temps utile, ce qui peut entraîner des problèmes dans l’appel initial. Par exemple, si l’utilisateur tente de rétablir le son tout en regardant une vidéo YouTube, ou si un appel RTC est actif simultanément.

  • Le rendu des flux vidéo entrants n’est pas interrompu si l’utilisateur utilise iOS 15.2+ et le SDK version 1.4.1-beta.1+, les étapes de réactivation du micro/démarrage de la vidéo sont toujours nécessaires pour redémarrer l’audio et la vidéo sortants.
  • Pour iOS 15.4+, la récupération automatique de l’audio et de la vidéo doit être possible dans la plupart des cas. Dans certains cas particuliers, pour rétablir le son, l’application doit appeler une API permettant de « rétablir le son » (cela peut résulter d’une action de l’utilisateur) afin de restaurer l’audio sortant.

Safari sous iOS rafraîchit la page si l’utilisateur ouvre une autre application et revient au navigateur

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : le problème peut se produire si un utilisateur participant à un appel Azure Communication Services avec Safari sous iOS bascule vers une autre application pendant un certain temps. Lorsque l’utilisateur revient au navigateur, la page du navigateur est susceptible de s’actualiser. Cela est dû au fait que le système d’exploitation supprime le navigateur. Pour contourner ce problème, il est possible de conserver certains états et de les récupérer après l’actualisation de la page.

Un utilisateur mobile iOS a quitté l’appel mais figure toujours dans la liste des participants

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : le problème peut se produire si un utilisateur mobile quitte l’appel de groupe Azure Communication Services sans utiliser l’API Call.hangUp(). Lorsqu’un utilisateur mobile ferme le navigateur ou actualise la page web sans raccrocher, les autres participants à l’appel de groupe peuvent toujours voir cet utilisateur mobile dans la liste des participants pendant environ 60 secondes.

Problème de blocage de Safari sous iOS 15

Version du navigateur : versions iOS 15 à 15.1.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : les utilisateurs peuvent être confrontés à un blocage de Safari lorsqu’ils naviguent sur YouTube, lorsqu’ils activent Siri, lorsqu’ils reçoivent des appels RTC entrants ou lors d’autres scénarios d’interruption au cours d’un appel web. Il s’agit d’un problème connu introduit avec iOS 15 et observé dans les versions iOS 15.0, 15.0.2 et 15.1.

  • Il a été corrigé avec iOS 15.2+.

Référence du problème connu : bugs liés à WebKit ici et ici.
Solution recommandée : envisagez d’effectuer une mise à jour vers la dernière version d’iOS.

Safari sur tablettes iPadOS

La rotation d’un appareil peut entraîner une mauvaise qualité vidéo : iPad 8 Apple et iPad X Apple

Appareils affectés : iPad 8 Apple et iPad X Apple.
Description : lorsque les utilisateurs font pivoter un appareil, ce mouvement peut dégrader la qualité de la vidéo en cours de diffusion.

Chrome sur ordinateurs de bureau

Problèmes de déconnexion d’appel sur macOS 15.0, build : 24A335

Version du système d’exploitation : macOS 15.0, build : 24A335.
Version du navigateur : Google Chrome – toutes les versions.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : lors du lancement d’un appel 1:1 sur macOS 15.0, si l’appelé accepte l’appel, il se déconnecte parfois automatiquement après quelques secondes. Des délais supplémentaires dans la réception et la jonction à des appels sont observés, ce qui peut également entraîner des déconnexions. La désactivation du pare-feu résout temporairement ces problèmes, ce qui suggère que l’interférence des paramètres de pare-feu de macOS est la cause racine. Ce problème a été résolu dans macOS 15.0.1, qui améliore la compatibilité avec les logiciels de sécurité de tiers, comme détaillé ici dans les notes de publication de macOS 15.0.1.
Solution de contournement recommandée : les utilisateurs qui rencontrent ce problème doivent envisager de désactiver temporairement le pare-feu ou d’effectuer une mise à jour vers macOS 15.0.1 pour résoudre définitivement ces problèmes de connectivité des appels.

Chrome M98 : régression qui dégrade la résolution vidéo et augmente la génération d’images clés pour les appareils n’ayant pas de carte NVIDIA

Version du navigateur : Google Chrome version 98 (février 2022)
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : Chrome version 98 a introduit une régression avec génération anormale d’images clés vidéo qui affecte de façon négative la résolution d’un flux vidéo envoyé pour la plupart (+ de 70 %) des utilisateurs.
Référence du problème connu : cette régression est un problème connu introduit sur Chromium.
Solution recommandée : mettre à jour Google Chrome vers la dernière version.

Chrome sur appareils mobiles Android

Chrome M125 : Aucune vidéo sortante dans les appels de groupe et les appels Azure Communication Services-Microsoft Teams sur certains appareils Android

Version du navigateur : Google Chrome version 125 (mai 2024) installée sur les appareils Android.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : Chrome version 125 pour Android a introduit une régression lors des appels vidéo. En conséquence, lorsqu’un utilisateur passe un appel sur Azure Communication Services avec cette version de Chrome, les appels de groupe et les appels Azure Communication Services-Microsoft Teams n’ont pas de vidéo sortante. Ce comportement est observé sur les appareils Huawei, OnePlus, Poco et Xiaomi. Le comportement n’est pas observé sur les appareils Android Samsung, Google Pixel et Motorola.

  • Un correctif est disponible à partir de Google Chrome version 125.0.6422.146/147.

Appareils affectés :

  • Huawei P30 Lite
  • OnePlus Nord N10
  • OnePlus 7T
  • Poco X3 Pro
  • Xiaomi Redmi 8T et éventuellement d’autres modèles/appareils similaires.

Solution de contournement recommandée : les utilisateurs sont invités à effectuer une mise à jour vers Google Chrome version 125.0.6422.146/147 ou ultérieure, où ce problème a été résolu.

Problème d’audio sortant sur Android 14 lorsque le navigateur fonctionne en arrière-plan ou que l’écran de l’appareil est verrouillé

Version Android : Android 14.
Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : sur Android 14, lorsque le navigateur fonctionne en arrière-plan ou que l’écran de l’appareil est verrouillé, l’audio sortant disparaît après environ 5 secondes. Ce problème impacte l’expérience utilisateur lorsqu’il interrompt la transmission audio pendant les appels. Le problème n’est pas observé sur Android 13 ou d’autres versions d’Android.
Solution de contournement recommandée : les utilisateurs sont invités à maintenir le navigateur actif au premier plan lors des appels.

Problème d’audio entrant et sortant sur Android lorsque le navigateur fonctionne en arrière-plan ou que l’écran de l’appareil est verrouillé avec le mode Économie d’énergie activé

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : sur les téléphones mobiles Android avec le mode Économie d’énergie activé, l’audio entrant et sortant s’arrête immédiatement lorsque le navigateur hébergeant l’appel ACS est mis en arrière-plan ou lorsque l’écran d’appareil est verrouillé. En outre, par suite de la mise en arrière-plan du navigateur sous le mode Économie d’énergie, l’utilisateur est déconnecté et supprimé de l’appel après environ une minute après le verrouillage de l’appareil ou la mise en arrière-plan du navigateur.
Référence de problème connu : il s’agit d’un problème connu sur Chromium.
Solution de contournement recommandée : pour éviter ce problème, nous conseillons aux utilisateurs de conserver le navigateur actif au premier plan pendant les appels ou de désactiver le mode Économie d’énergie pendant des appels WebRTC.

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : Lorsque plus de trois utilisateurs sont dans un appel vidéo avec un utilisateur disposant d’un appareil Android, l’utilisateur Android peut parfois observer que la vidéo entrante clignote ou s’affiche en même temps qu’une autre vidéo entrante. Un autre comportement que les utilisateurs observent parfois dans le même cas d’usage est que la vidéo entrante peut apparaître avec une teinte verte ou une superposition verte pendant un court instant, ou parfois pendant plus longtemps. Ce comportement est particulièrement visible lorsqu’un autre utilisateur réactive sa caméra ou rejoint l’appel avec sa vidéo activée. Ce comportement est observé sur Samsung Galaxy S10, S20, S21 et Google Pixel 6, 8.
Appareils affectés :

  • Samsung Galaxy S10
  • Samsung Galaxy S20
  • Samsung Galaxy S21
  • Google Pixel 6
  • Google Pixel 8

Référence du problème connu : Cette régression est un problème connu sur Chromium.

Chrome M115 : aucune vidéo sortante dans les appels de groupe et les appels Azure Communication Services-Microsoft Teams

Version du navigateur : Google Chrome version 115 (juillet 2023) installée sur les appareils Android.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : Chrome version 115 pour Android a introduit une régression lors des appels vidéo. En conséquence, lorsqu’un utilisateur passe un appel sur Azure Communication Services avec cette version de Chrome, les appels de groupe et les appels Azure Communication Services-Microsoft Teams n’ont pas de vidéo sortante.
Référence du problème connu : cette régression est un problème connu introduit sur Chromium.
Solution recommandée : à court terme, demandez aux utilisateurs d’utiliser Microsoft Edge ou Firefox sur Android, ou d’éviter d’utiliser Google Chrome 115/116 sur Android.

L’utilisateur Android peut néanmoins entendre le son de l’appel « Azure Communication Services » lors des appels RTC

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : ce problème survient lorsqu’un utilisateur d’Android Chrome reçoit un appel RTC. Après avoir répondu à l’appel RTC, le microphone de l’appel « Azure Communication Services » se désactive. L’audio sortant de l’appel « Azure Communication Services » est désactivé. Les autres participants ne peuvent donc pas entendre l’utilisateur qui participe à l’appel RTC. Il est important de noter que l’audio entrant de l’utilisateur n’est pas désactivé et que ce comportement est inhérent au navigateur.
Solution recommandée : attendez une prochaine mise à jour ou un correctif de Google.

L’audio entrant est sensiblement plus silencieux dans l’appel Azure Communication Services après l’appel d’application tiers sur les appareils Android

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : les utilisateurs bénéficient d’un audio entrant sensiblement plus silencieux après avoir reçu et accepté un appel d’une application tierce (par exemple, WhatsApp, Viber) pendant un appel Azure Communication Services. Ce problème se produit sur les appareils Android utilisant le navigateur mobile. En outre, les contrôles de volume indiquent des niveaux maximum, bien que l’audio reste plus silencieux qu’avant l’appel tiers.
Référence de problème connu : il s’agit d’un problème connu sur Chromium.
Solution de contournement recommandée : les utilisateurs sont invités à rejoindre l’appel Azure Communication Services ou à gérer séparément les appels d’application tiers.

Android Chrome désactive le son de l’appel lorsque le navigateur passe en arrière-plan pendant une minute

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : sur Android Chrome, un utilisateur participe à un appel Azure Communication Services et place le navigateur en arrière-plan pendant une minute. Le microphone se désactive alors et les autres participants de l’appel ne peuvent pas entendre l’audio de l’utilisateur. Dès que l’utilisateur ramène le navigateur au premier plan, le microphone redevient disponible.
Référence du problème connu : bugs liés à chromium ici et ici.

Le microphone ou la caméra en local se coupe lorsque certaines interruptions se produisent sur Android Chrome

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : ce problème peut se produire si une autre application ou si le système d’exploitation prend le contrôle du microphone ou de la caméra. Voici quelques exemples qui peuvent se produire alors qu’un utilisateur participe à un appel :

  • Un appel entrant est reçu via RTC (réseau téléphonique commuté) et il capture l’accès à l’appareil de catégorie micro.
  • Un utilisateur regarde une vidéo sur YouTube, par exemple, ou initie un appel via une app tierce. Le basculement vers une autre application native peut capturer l’accès au microphone ou à la caméra.

Sur Android Chrome, lorsqu’un appel RTC est reçu, l’audio est interrompu dans l’appel Azure Communication Services mais ce dernier n’est pas marqué comme silencieux. Dans ce cas, il n’existe aucun événement UFD microphoneMutedUnexepectedly. Une fois l’appel RTC terminé, Android Chrome récupère automatiquement l’audio et le son est rétabli correctement dans l’appel Azure Communication Services.

Si la caméra est activée et qu’une interruption se produit, l’appel Azure Communication Services peut ou non perdre la liaison avec la caméra. Si la liaison est perdue, la caméra est marquée comme désactivée et l’utilisateur doit aller la réactiver lorsque l’interruption est terminée et que la caméra est de nouveau opérationnelle.

Il arrive que les microphones ou les caméras ne soient pas remis à disposition en temps utile, ce qui peut entraîner des problèmes dans l’appel initial. Par exemple, si l’utilisateur tente de rétablir le son tout en regardant une vidéo YouTube, ou si un appel RTC est actif simultanément.

La sélection automatique du microphone échoue avec l’utilisation d’écouteurs filaires dans les appels WebRTC sur les appareils Android

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : lorsque les utilisateurs connectent des écouteurs filaires à leur appareil Android et rejoignent un appel WebRTC, l’option de microphone ne correspond pas par défaut aux écouteurs filaires. Ce problème est systématiquement reproductible sur différents appareils Android et les versions de Google Chrome. Un comportement similaire a été noté dans d’autres services tels que Twilio et l’exemple WebRTC de Google.
Référence de problème connu : il s’agit d’un problème connu sur Chromium.
Solution de contournement recommandée : les utilisateurs doivent sélectionner manuellement les écouteurs filaires comme option de microphone dans les paramètres d’appel après avoir rejoint l’appel WebRTC.

Un utilisateur Android mobile a quitté l’appel, mais figure toujours dans la liste des participants

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : le problème peut se produire si un utilisateur mobile quitte l’appel de groupe Azure Communication Services sans utiliser l’API Call.hangUp(). Lorsqu’un utilisateur mobile ferme le navigateur ou actualise la page web sans raccrocher, les autres participants à l’appel de groupe peuvent toujours voir cet utilisateur mobile dans la liste des participants pendant environ 60 secondes.

Certains appareils Android (A326U, A125U et A215U) échouent dans les scénarios d’appel, sauf pour les appels de groupe

Appareils affectés :

  • Samsung Galaxy A32 (modèle A326U)
  • Samsung Galaxy A12 (modèle A125U)
  • Samsung Galaxy A21 (modèle A215U)

Description : un certain nombre d’appareils Android spécifiques ne parviennent pas à initier ou à décrocher des appels et des réunions. Les appareils qui rencontrent ce problème ne peuvent pas le résoudre et échouent à chaque tentative. Il s’agit principalement des appareils de modèle A Samsung, en particulier des modèles A326U, A125U et A215U.

La rotation d’un appareil peut entraîner une mauvaise qualité vidéo : Google Pixel 3a, Google Pixel 5

Appareils affectés : Google Pixel 3a, Google Pixel 5.
Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : lorsque les utilisateurs font pivoter un appareil, ce mouvement peut dégrader la qualité de la vidéo en cours de diffusion.

Le changement de caméra fige l’écran : Google Pixel 4a

Appareils affectés : Google Pixel 4a.
Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : lorsqu’un utilisateur Communication Services rejoint un appel à l’aide du kit SDK d’appels JavaScript, puis sélectionne le bouton de commutation de la caméra, l’interface utilisateur risque de ne plus répondre. L’utilisateur doit alors actualiser l’application ou envoyer (push) le navigateur en arrière-plan.

Chrome sur appareils mobiles iOS

Absence d’audio sortant et entrant lors du basculement du navigateur vers l’arrière-plan ou du verrouillage de l’appareil : résolu dans iOS version 16.4+

Version iOS : toutes les versions iOS jusqu’à iOS 16.3.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : l’absence d’audio sortant ou entrant lors du basculement du navigateur en arrière-plan ou du verrouillage de l’appareil était un problème présent jusqu’à la version 16.3 d’iOS incluse, et a été corrigé à partir de la version 16.4 d’iOS.
Référence du problème connu : bug lié à WebKit.
Solution recommandée : envisagez d’effectuer une mise à jour vers la dernière version d’iOS.

Absence d’audio entrant/sortant en provenance du casque Bluetooth : iOS 15

Version iOS : nous avons constaté ce problème sur les versions d’iOS 15.6 et 15.7.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : lorsqu’un utilisateur connecte un casque Bluetooth au cours d’un appel Azure Communication Services, le son continue à être émis par le haut-parleur jusqu’à ce que l’utilisateur verrouille et déverrouille son téléphone. Le problème n’est pas reproductible sur iOS 16.
Solution recommandée : envisagez d’effectuer une mise à jour vers la dernière version d’iOS.

Un utilisateur mobile iOS a quitté l’appel mais figure toujours dans la liste des participants

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : le problème peut se produire si un utilisateur mobile quitte l’appel de groupe Azure Communication Services sans utiliser l’API Call.hangUp(). Lorsqu’un utilisateur mobile ferme le navigateur ou actualise la page web sans raccrocher, les autres participants à l’appel de groupe peuvent toujours voir cet utilisateur mobile dans la liste des participants pendant environ 60 secondes.

Firefox sur les ordinateurs de bureau

L’énumération et la sélection des haut-parleurs ne sont pas disponibles dans Firefox via le gestionnaire de périphériques de Communication Services

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : si vous utilisez Firefox, votre application ne peut pas énumérer ou sélectionner des haut-parleurs via le gestionnaire de périphériques de Communication Services.
Solution : dans ce cas, vous devez sélectionner les périphériques via le système d’exploitation.

Les caméras virtuelles ne sont pas prises en charge actuellement

Version du navigateur : toutes.
Version du Kit de développement logiciel (SDK) d’appel Azure Communication Service : toutes.
Description : les caméras virtuelles ne sont pas prises en charge actuellement lors des appels audio/vidéo effectués à partir de Firefox sur un ordinateur de bureau.