Problèmes connus dans les kits SDK et les API

  • Article

Ces articles contiennent des informations sur les limitations et les problèmes connus liés aux kits de développement logiciel (SDK) d’Appel d’Azure Communication Services et aux API d’Automatisation des appels de Communication Services.

Important

Plusieurs facteurs peuvent affecter la qualité de votre expérience d’appel. Pour en savoir plus sur la configuration du réseau et les meilleures pratiques en matière de tests pour Communication Services, consultez Recommandations réseau.

Kit de développement logiciel (SDK) web pour les appels

Les sections suivantes fournissent des informations sur les problèmes connus associés aux kits de développement logiciel (SDK) JavaScript pour les appels audio et vidéo Azure Communication Services.

Chrome M115 - régression

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.

  • Cette régression est un problème connu introduit sur Chromium
  • À titre de solution à court terme, demandez aux utilisateurs d’utiliser Microsoft Edge ou Firefox sur Android, ou d’éviter d’utiliser Google Chrome 115/116 sur Android

Problèmes connus de Firefox

La prise en charge du navigateur de bureau Firefox est désormais disponible en préversion publique. Les problèmes connus sont les suivants :

  • L’énumération des haut-parleurs n’est pas disponible : si vous utilisez Firefox, votre application ne pourra pas énumérer ou sélectionner les haut-parleurs via le gestionnaire de périphériques Communication Services. Dans ce scénario, vous devez sélectionner les appareils via le système d’exploitation.
  • Les caméras virtuelles ne sont actuellement pas prises en charge lors d’appels audio/vidéo effectués à partir de Firefox sur un ordinateur de bureau.

Problèmes connus liés à Chrome pour iOS

La prise en charge du navigateur Chrome pour iOS est désormais disponible en préversion publique. Les problèmes connus sont les suivants :

  • Absence d’audio sortant et entrant lors du basculement du navigateur vers l’arrière-plan ou du verrouillage de l’appareil. Ce problème a été résolu dans iOS versions 16.4 et ultérieures.
  • Absence d’audio entrant/sortant en provenance du casque Bluetooth. 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. Nous avons constaté ce problème sur des versions plus anciennes d’iOS (15.6, 15.7), et il n’est pas reproductible sur iOS 16.

Safari sous iOS affiche l’aperçu de la caméra dans une résolution incorrecte

Ce bug se produit sur iOS 16.7 ou sur les versions d’iOS 17 antérieures à la version 17.4, lorsque les utilisateurs font pivoter leur téléphone ou activent/désactivent la vidéo pendant l’appel. L’aperçu de la caméra s’affiche brièvement dans une résolution incorrecte avant de revenir à la normale. Ce problème n’est pas reproductible sur iOS 17.4 bêta. Bug lié à WebKit ici.

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

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. Apple a conscience de ce problème et cherche à le corriger de son côté. 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 :

  • Munissez-vous d’un iPhone exécutant iOS 16.
  • Rejoindre l’appel Azure Communication Services (avec audio uniquement ou avec audio et vidéo) à partir du navigateur mobile Safari iOS
  • Si, pendant l’appel, quelqu’un met le navigateur Safari en arrière-plan et affiche YouTube OU reçoit un appel FaceTime/téléphonique alors qu’il est connecté via un périphérique Bluetooth

Résultats :

  • 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.

Chrome M98 - régression

Chrome version 98 a introduit une régression avec génération anormale d’images clés vidéo qui affecte négativement la résolution d’un flux vidéo envoyé pour la plupart (+ de 70 %) des utilisateurs.

  • Cette régression est un problème connu introduit sur Chromium

Lors d’un appel RTC, l’utilisateur peut encore entendre l’audio émanant de l’appel ACS

Ce problème se produit lorsqu’un utilisateur Android Chrome reçoit un appel RTC. Lorsque ce dernier répond à l’appel RTC, le microphone de l’appel ACS se désactive. L’audio sortant de l’appel ACS est coupé, de sorte que les autres participants ne peuvent pas entendre l’utilisateur qui est en train de passer 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.

Aucun audio entrant pendant un appel

Il peut arriver qu’un utilisateur participant à un appel Azure Communication Services ne puisse pas entendre le son des participants distants. Il existe un bug Chromium associé qui provoque ce problème, qui peut être résolu en reconnectant la PeerConnection. Nous avons ajouté cette solution à partir du kit de développement logiciel (SDK) 1.9.1 (version stable) et du kit de développement logiciel (SDK) 1.10.0 (version bêta).

Sur Android Chrome, si un utilisateur rejoint un appel Azure Communication Services plusieurs fois, l’audio entrant peut également être perdu. L’utilisateur n’est pas en mesure d’entendre le son des autres participants tant que la page n’est pas actualisée. Nous avons corrigé ce problème dans le kit de développement logiciel (SDK) 1.10.1-beta.1 et nous avons amélioré l’utilisation des ressources audio.

Certains appareils Android échouent dans les scénarios d’appel, à l’exception des appels de groupe.

De nombreux appareils Android spécifiques ne parviennent pas à initier ou à accepter 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.

  • Cette régression est un problème connu introduit sur Chromium.

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

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. Bugs liés à chromium ici et ici

Un utilisateur mobile (iOS et Android) a quitté l’appel mais figure toujours dans la liste des participants.

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.

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

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.

Utilisateurs d’iOS 15.1 qui rejoignent des appels de groupe ou des réunions Microsoft Teams.

  • Parfois, lors de la réception d’un appel RTC entrant, l’onglet contenant l’appel ou la réunion se fige. Bugs liés à WebKit ici et ici.

Le microphone ou l’appareil photo local se coupe lorsque certaines interruptions se produisent sur iOS Safari et Android Chrome.

Ce problème peut se produire si une autre application ou 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. Dans le cas d’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.

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.

iOS avec Safari se bloque et actualise la page si un utilisateur tente de basculer de la caméra avant vers la caméra arrière.

Azure Communication Services Calling SDK version 1.2.3-beta.1 contient un bogue qui affecte tous les appels émis à partir d’iOS Safari. Le problème se produit quand un utilisateur tente de basculer le flux vidéo de la caméra avant vers la caméra arrière. Le basculement entre les caméras a pour effet que le navigateur Safari se bloque et recharge la page.

Ce problème a été résolu dans Azure Communication Services Calling SDK version 1.3.1-beta.1+

  • Version de Safari d’iOS : 15.1

Partage d’écran dans Safari sous macOS Ventura (version 16.3 et inférieures)

Le partage d’écran ne fonctionne pas dans Safari sous macOS Ventura (version 16.3 et inférieures). Problème connu de Safari qui sera corrigé dans les versions 16.4 et ultérieures.

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

Si un utilisateur participant à un appel 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é.

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

Il s’agit d’une limitation connue. Pour en savoir plus, consultez Vue d’ensemble du kit SDK Appel.

L’énumération des appareils ne peut s’effectuer dans Safari lorsque l’application s’exécute sur iOS ou iPados

Les applications ne peuvent pas énumérer ou sélectionner des haut-parleurs (comme Bluetooth) via le navigateur Safari sur iOS ou iPadOS. Ce problème est une limitation connue de ces systèmes d’exploitation.

Si vous utilisez Safari sur macOS, votre application ne sera pas en mesure d’énumérer ou de sélectionner des haut-parleurs via le gestionnaire de périphériques de Communication Services. Dans ce scénario, vous devez sélectionner les appareils via le système d’exploitation. Si vous utilisez Chrome sur macOS, l’application peut énumérer ou sélectionner des appareils via le gestionnaire d’appareils de Communication Services.

  • Version de Safari d’iOS : 15.1

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

La commutation entre différents appareils vidéo peut entraîner la suspension de votre streaming vidéo pendant l’acquisition du flux à partir de l’appareil sélectionné. La commutation fréquente entre plusieurs appareils risque de détériorer les performances. Il est recommandé aux développeurs d’arrêter le streaming sur un appareil avant de le démarrer sur un autre.

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

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. Dans ce scénario, utilisez le système d’exploitation pour mettre à jour la sélection de votre appareil.

La rotation d’un appareil risque de détériorer fortement la qualité de la vidéo

Lorsque les utilisateurs font pivoter un appareil, ce mouvement peut dégrader la qualité de la vidéo en cours de streaming.

Ce problème se produit dans les environnements suivants :

  • Appareils affectés : Google Pixel 5, Google Pixel 3A, Apple iPad 8 et Apple iPad X
  • Bibliothèque de client : Appel (JavaScript)
  • Navigateurs : Safari, Chrome
  • Systèmes d’exploitation : iOS, Android

La commutation d’appareil photo gèle l’affichage sur l’écran

Lorsqu’un utilisateur Communication Services rejoint un appel à l’aide du kit SDK pour les appels JavaScript, puis sélectionne le bouton du bouton de commutation de la caméra, l’interface utilisateur peut se bloquer. L’utilisateur doit alors actualiser l’application ou envoyer (push) le navigateur en arrière-plan.

Ce problème se produit dans les environnements suivants :

  • Appareils affectés : Google Pixel 4a
  • Bibliothèque de client : Appel (JavaScript)
  • Navigateur : Chrome
  • Systèmes d’exploitation : iOS, Android

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

Si un utilisateur active et désactive rapidement la vidéo pendant 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.

Accès aux appareils ou énumération de ces appareils pour Safari sur macOS et iOS

Dans certains environnements, vous remarquerez peut-être que les autorisations de l’appareil 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.

Ce problème se produit dans les environnements suivants :

  • Appareil affecté : iPhone
  • Bibliothèque de client : Appel (JavaScript)
  • Navigateur : Safari
  • Système d'exploitation : iOS

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

Pendant un appel de groupe en cours, 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. Pour plus d’informations, consultez Recommandations réseau.

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

Si vous utilisez getUserMedia séparément dans l’application, le flux audio est 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 se produit dans les environnements suivants :

  • Navigateur : Safari
  • Système d'exploitation : iOS

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.

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

À 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.

API d’automatisation des appels

Les limitations suivantes sont des problèmes connus dans les API d’Automatisation des appels de Communication Services :

  • La seule authentification actuellement prise en charge pour les applications serveur consiste à utiliser une chaîne de connexion.

  • Effectuez des appels uniquement entre des entités de la même ressource Communication Services. La communication entre les ressources est bloquée.

  • Les appels entre les utilisateurs locataires de Microsoft Teams et des entités d’application serveur ou des utilisateurs Communication Services ne sont pas autorisés.

  • Si une application se connecte à deux identités RTC ou plus, puis quitte l’appel, l’appel entre les autres entités RTC est abandonné.

Les sections suivantes fournissent des informations sur les problèmes connus associés au kit de développement logiciel (SDK) natif pour les appels Azure Communication Services et au kit de développement logiciel (SDK) natif pour l’interface utilisateur.

Émulateurs d’API Android

Lors de l’utilisation d’émulateurs d’API Android sur Android 5.0 (niveau API 21) et Android 5.1 (niveau API 22), certains dysfonctionnements sont à prévoir.

Conflit de module Trouter Android

Lorsque le chat Android et du kit de développement logiciel (SDK) pour les appels sont utilisés conjointement dans la même application, la fonctionnalité de notifications en temps réel du kit de développement logiciel (SDK) du chat ne fonctionne pas. Vous risquez d’obtenir un problème de résolution de dépendance.

Pendant que nous travaillons à une solution, vous pouvez désactiver la fonctionnalité de notifications en temps réel en ajoutant les informations de dépendance suivantes dans le fichier build.gradle de l’application et en interrogeant plutôt l’API GetMessages pour présenter les messages entrants aux utilisateurs.

Java

 implementation ("com.azure.android:azure-communication-chat:1.0.0") {
     exclude group: 'com.microsoft', module: 'trouter-client-android'
 }
 implementation 'com.azure.android:azure-communication-calling:1.0.0'

Remarque : si l’application tente d’agir sur les API de notification comme chatAsyncClient.startRealtimeNotifications() ou chatAsyncClient.addEventHandler(), une erreur d’exécution se produit.

Image dans l’image (PiP) : vidéo en cours sur iOS

La vidéo entrante est interrompue lorsque l’application passe en arrière-plan. Si l’application est au premier plan, la vidéo s’affiche correctement.

Bibliothèque d’interface utilisateur

Vous pouvez consulter la page wiki des problèmes connus dans les référentiels GitHub.