Partager via

Meilleures pratiques : Kit de développement logiciel (SDK) d’appel Azure Communication Services

  • Article

Cet article fournit des informations sur les bonnes pratiques relatives aux SDK d’appel Azure Communication Services.

Meilleures pratiques relatives au Kit de développement logiciel (SDK) web d’appel Azure Communication Services

Cette section fournit des informations sur les meilleures pratiques associées au SDK web d’appel Azure Communication Services (JavaScript) pour les appels audio et vidéo.

Brancher un micro ou l’activer à partir du Gestionnaire de périphériques lorsqu’un appel est en cours

Si aucun micro n’est disponible au début d’un appel Azure Communication Services, puis qu’un micro devient disponible, ce changement déclenche un événement de diagnostic noMicrophoneDevicesEnumerated. Lorsque cet événement se produit, votre application doit appeler askDevicePermission pour obtenir le consentement de l’utilisateur afin d’énumérer les périphériques. L’utilisateur peut ensuite désactiver ou activer le son du micro.

Supprimer VideoStreamRendererView

Les applications Communication Services doivent supprimer VideoStreamRendererView, ou son instance parente VideoStreamRenderer, lorsqu’elles n’en ont plus besoin.

Raccrocher l’appel lors d’un événement onbeforeunload

Votre application doit appeler call.hangup lorsque l'événement onbeforeunload est émis.

Gérer plusieurs appels sur plusieurs onglets

Votre application ne doit pas se connecter simultanément aux appels provenant de plusieurs onglets de navigateur sur des appareils mobiles. Cette situation peut entraîner un comportement non défini en raison de l’allocation des ressources pour le micro et la caméra sur un appareil. Nous encourageons les développeurs à toujours raccrocher un appel quand celui-ci est effectué en arrière-plan avant d’en démarrer un nouveau.

Gérer la désactivation du son d’un appel par le système d’exploitation lorsqu’un appel téléphonique est reçu

Pendant un appel Azure Communication Services (pour iOS et Android), si un appel téléphonique est reçu ou que l’assistant vocal est activé, le système d’exploitation désactive automatiquement le son du micro et de la caméra de l’utilisateur. Sur Android, l’appel est automatiquement activé et la vidéo redémarre une fois l’appel téléphonique terminé. Sur iOS, l’activation du son et le redémarrage de la vidéo nécessitent une action de l’utilisateur.

Vous pouvez utiliser l’événement de qualité de microphoneMuteUnexpectedly pour écouter la notification indiquant que le son du micro a été désactivé de manière inattendue. Gardez à l’esprit que pour rejoindre correctement un appel, vous devez utiliser le SDK 1.2.3-beta.1 ou version ultérieure.

const latestMediaDiagnostic = call.api(SDK.Features.Diagnostics).media.getLatest();
const isIosSafari = (getOS() === OSName.ios) && (getPlatformName() === BrowserName.safari);
if (isIosSafari && latestMediaDiagnostic.microphoneMuteUnexpectedly && latestMediaDiagnostic.microphoneMuteUnexpectedly.value) {
  // received a QualityEvent on iOS that the microphone was unexpectedly muted - notify user to unmute their microphone and to start their video stream
}

Votre application doit appeler call.startVideo(localVideoStream); pour démarrer un flux vidéo et utiliser this.currentCall.unmute(); pour activer le son.

Gérer des unités

Vous pouvez utiliser le Kit de développement logiciel (SDK) Azure Communication Services pour gérer vos appareils et vos opérations multimédias.

Votre application ne doit pas utiliser les API de navigateur natives comme getUserMedia ou getDisplayMedia pour acquérir des flux en dehors du SDK. Si vous le faites, vous devez supprimer manuellement vos flux multimédias avant d’utiliser DeviceManager ou d’autres API de gestion des périphériques via le SDK Communication Services.

Demander des autorisations d’appareil

Vous pouvez demander des autorisations d’appareil à l’aide du SDK. Votre application doit utiliser DeviceManager.askDevicePermission pour demander l’accès à des périphériques audio et/ou vidéo.

Si l’utilisateur refuse l’accès, DeviceManager.askDevicePermission retourne false pour un type de périphérique donné (audio ou vidéo) lors des appels suivants, même après l’actualisation de la page. Dans ce scénario, votre application doit :

  1. Détecter que l’utilisateur a précédemment refusé l’accès.
  2. Demander à l’utilisateur de réinitialiser manuellement ou de permettre d’accéder explicitement à un type de périphérique particulier.

Gérer le comportement d’une caméra utilisée par un autre processus

  • Sur Windows Chrome et Windows Microsoft Edge : si vous démarrez, joignez ou acceptez un appel avec la vidéo activée et qu’un processus (autre que le navigateur sur lequel s’exécute le SDK web) utilise la caméra, l’appel démarre avec l’audio uniquement et pas la vidéo. Un indicateur cameraStartFailed de Diagnostics accessibles à l’utilisateur est déclenché, car la caméra n’a pas pu démarrer.

    La même situation s’applique à l’activation de la vidéo au milieu d’un appel. Vous pouvez désactiver la caméra dans l’autre processus afin que ce processus libère la caméra, puis redémarrer la vidéo à partir de l’appel. La vidéo s’active alors pour l’appel, et les participants distants commencent à voir la vidéo.

    Ce problème n’existe pas dans macOS Chrome ni dans macOS Safari, car le système d’exploitation permet aux processus et aux threads de partager la caméra.

  • Sur les appareils mobiles : si un Processus A demande la caméra alors que le Processus B l’utilise, le Processus A s’approprie la caméra et le Processus B cesse de l’utiliser.

  • Sur iOS Safari : vous ne pouvez pas activer la caméra pour plusieurs clients d’appel sous le même onglet ou sous différents onglets. Quand un client d’appel utilise la caméra, il l’accapare et elle cesse d’être disponible pour tout client d’appel précédent qui l’utilisait. Le client d’appel précédent obtient un indicateur cameraStoppedUnexpectedly de Diagnostics accessibles à l’utilisateur.

Gérer le partage d’écran

La fermeture d’une application n’empêche pas son partage

Prenons l’exemple suivant : vous partagez l’écran de l’application Microsoft Teams à partir de Chromium. Vous cliquez ensuite sur le bouton X de l’application Teams pour la fermer. Bien que la fenêtre soit fermée, l’application Teams continue de s’exécuter en arrière-plan. L’icône apparaît toujours dans la barre des tâches du Bureau. L’application Teams étant toujours en cours d’exécution, son écran est toujours partagé avec les participants distants.

Pour arrêter le partage d’écran de l’application, vous devez effectuer l’une des actions suivantes :

  • Cliquer avec le bouton droit sur l’icône de l’application dans la barre des tâches du Bureau, puis sélectionner Quitter.
  • Sélectionner le bouton Arrêter le partage dans le navigateur.
  • Appeler l’opération d’API Call.stopScreenSharing() du SDK.

Safari ne peut effectuer que le partage en plein écran

Safari autorise uniquement le partage d’écran pour l’écran entier. Ce comportement est différent de celui de Chromium, qui vous permet de partager à l’écran un plein écran, un programme de bureau spécifique ou un onglet de navigateur spécifique.

Vous pouvez accorder des autorisations de partage d’écran sur macOS

Pour partager l’écran dans macOS Safari ou macOS Chrome, accordez les autorisations nécessaires aux navigateurs dans le menu du système d’exploitation : Réglages système>Confidentialité et sécurité>Enregistrement de l’écran.

Meilleures pratiques relatives au Kit de développement logiciel (SDK) natif d’appel Azure Communication Services

Cette section fournit des informations sur les meilleures pratiques associées au SDK natif d’appel Azure Communication Services pour les appels audio et vidéo.

Plateformes prises en charge

Voici les exigences minimales de la plateforme du système d’exploitation pour garantir des fonctionnalités optimales du SDK natif d’appel.

  • Prise en charge d’iOS 10.0 et versions ultérieures au moment de la génération et d’iOS 12.0 et versions ultérieures au moment de l’exécution
  • XCode 12.0 et versions ultérieures
  • Prise en charge pour iPadOS 13.0+

Vérifier les autorisations des appareils pour les demandes d’application

Pour utiliser le SDK natif d’appel pour effectuer ou recevoir des appels, les consommateurs doivent autoriser chaque plateforme à accéder aux ressources de l’appareil. En tant que développeur, vous devez inviter l’utilisateur à y accéder et vous assurer que les autorisations sont activées. Le consommateur autorisant ces droits d’accès, vérifiez qu’il dispose actuellement des autorisations nécessaires.

  • NSMicrophoneUsageDescription pour l’accès au micro
  • NSCameraUsageDescription pour l’accès à la caméra

Configurer les journaux

L’implémentation la journalisation telle que décrite dans le tutoriel sur la récupération des fichiers journaux est plus importante que jamais. Les journaux détaillés aident à diagnostiquer les problèmes spécifiques aux modèles d’appareil ou aux versions de système d’exploitation qui répondent aux critères minimaux du SDK. Nous encourageons les développeurs à configurer les journaux à l’aide de l’API Logs. Sans journaux, l’équipe du support technique Microsoft ne peut pas vous aider à déboguer et à résoudre les problèmes liés aux appels.

Suivre CallID

CallID est l’ID unique d’un appel. Il identifie les événements corrélés de tous les participants et points de terminaison qui se connectent pendant un appel. Dans la plupart des cas, vous l’utilisez pour passer en revue les journaux. L’équipe du support technique Microsoft vous le demande pour vous aider à résoudre les problèmes liés aux appels.

Vous devez suivre la valeur CallID dans la télémétrie que vous configurez dans votre application. Pour comprendre comment récupérer la valeur pour chaque plateforme, suivez les instructions du guide de résolution des problèmes.

S’abonner aux Diagnostics accessibles à l’utilisateur et aux statistiques de qualité des médias

Vous pouvez utiliser ces fonctionnalités d’Azure Communication Services pour améliorer l’expérience utilisateur :

  • Diagnostics accessibles à l’utilisateur : examinez les propriétés d’un appel pour déterminer la cause des problèmes qui affectent vos clients.
  • Statistiques de qualité des médias : examinez les métriques de qualité audio, vidéo et de partage d’écran de bas niveau pour les métriques des appels entrants et sortants. Nous vous recommandons de collecter les données et de les envoyer à votre ingestion de pipeline après la fin d’un appel.

Gérer les erreurs

En cas d’erreur pendant l’appel ou l’implémentation, les méthodes retournent des objets d’erreur contenant des codes d’erreur. Il est essentiel d’utiliser ces objets d’erreur pour une gestion des erreurs appropriée et pour afficher les alertes. Les états d’appel retournent également des codes d’erreur pour identifier les raisons des échecs d’appel. Vous pouvez vous référer au guide de résolution des problèmes pour résoudre tout type de problème.

Gérer les flux vidéo

Veillez à supprimer VideoStreamRendererView lorsque l’interface utilisateur n’affiche plus la vidéo. Utilisez VideoStreamType pour déterminer le type du flux.

Effectuer une gestion générale de la mémoire

Préallouer les ressources. Initialisez votre client d’appel et toutes les ressources nécessaires pendant la phase de démarrage de votre application plutôt que à la demande. Cette approche réduit la latence au démarrage d’un appel.

Supprimer correctement. Supprimez tous les objets d’appel après leur utilisation pour libérer les ressources système et éviter les fuites de mémoire. Veillez à vous désabonner des événements susceptibles de provoquer des fuites de mémoire.

Réfléchir à la façon dont les processus accèdent à la caméra ou au micro

Sur les appareils mobiles, si plusieurs processus tentent d’accéder à la caméra ou au micro en même temps, le premier processus à demander l’accès prend le contrôle de l’appareil. Le deuxième processus perd donc immédiatement l’accès à celui-ci.

Optimiser la taille des bibliothèques

Il est crucial d’optimiser la taille des bibliothèques dans le développement de logiciels pour les raisons suivantes, en particulier à mesure que les applications deviennent plus complexes et plus gourmandes en ressources :

  • Niveau de performance de l’application : des bibliothèques plus petites réduisent la quantité de code qu’une application doit charger, analyser et exécuter. Cette réduction peut améliorer considérablement le temps de démarrage et le niveau de performance global de votre application, en particulier sur les appareils disposant de ressources limitées.

  • Utilisation de la mémoire : en réduisant la taille des bibliothèques, vous pouvez réduire l’empreinte mémoire du runtime d’une application. Cela est important pour les appareils mobiles dont la mémoire est souvent limitée. Une utilisation moins importante de la mémoire peut entraîner moins de blocages système et de meilleures performances multitâche.

Pour plus d’informations, consultez l’article suivant :

Contenu connexe