Meilleures pratiques en matière de tests avant appel

Ce guide décrit une expérience de pré-appel pour les Applications Video API qui souhaitent réduire les échecs de jointure et protéger l'expérience de la session en direct. Il traite des salles d'attente, des autorisations et de la configuration des appareils, des tests de réseau, de l'interprétation des résultats et de la décision de connexion.

Un test avant appel permet d'estimer la qualité de l'appel à un moment donné. Il permet de détecter les problèmes de configuration avant le début de la session, mais il ne peut pas prédire ce qui se passera plus tard au cours de l'appel. Continuez à surveiller après que l'utilisateur a rejoint la session avec Observabilité du clientLe système de gestion de la qualité de l'information est un outil de gestion de la qualité, des événements de qualité et des fonctions d'adaptation à l'exécution.

Flux recommandé avant l'appel

  1. Utiliser une salle d'attente avant que l'utilisateur ne rejoigne l'appel.
  2. Vérifier les autorisations de l'appareil photo et du microphone et afficher un aperçu local.
  3. Permettre à l'utilisateur de choisir des appareils et lui montrer quelle caméra et quel microphone sont actuellement sélectionnés.
  4. Exécutez le test de pré-appel avec des justificatifs d'essai distincts et une session de test distincte. La session d'appel et les données de l'inspecteur sont ainsi séparées des connexions et des flux de test.
  5. Exécuter NetworkTest.testConnectivity() d'abord, puis NetworkTest.testQuality().
  6. Utilisez les résultats documentés pour définir le statut d'une salle d'attente. Un modèle simple est Pass, Warnou Fail.
  7. Rejoignez la session une fois que les autorisations, la configuration de l'appareil et les vérifications préalables à l'appel sont terminées. Pour les WarnDans ce cas, une option consiste à laisser l'utilisateur continuer en l'avertissant clairement.

Si vous utilisez la bibliothèque network-test, créez un fichier séparé de acheminé session de test. Ne pas réutiliser l'identifiant de la session de communication pour la session de test. Si l'implémentation du test accepte les audioSource et videoSource utiliser la caméra et le microphone sélectionnés dans la salle d'attente.

Salles d'attente

Une salle d'attente donne aux utilisateurs le temps de vérifier les autorisations de la caméra et du microphone et de choisir les appareils avant d'entamer l'appel. Elle permet d'appliquer les paramètres de publication recommandés et d'effectuer un test avant le début de la session. Cela permet de séparer la configuration de la session en direct et de réduire les perturbations lorsque les participants se joignent à la session. L'outil Application de référence Web comprend une salle d'attente pour la prévisualisation des appareils et la prise en charge de l'installation avant l'adhésion.

Salle d'attente UI

La salle d'attente peut comprendre les éléments suivants

  • Prévisualisation de la caméra locale,
  • Indicateur d'activité du microphone,
  • Sélecteurs de caméra et de microphone,
  • Effacer les messages relatifs à l'état de permission et à l'état de refus,
  • Indicateur d'état ou de progression du test préalable à l'appel,
  • Un état visible de préparation à la jonction,
  • Action de réessai pour le test de pré-appel.

Exécutez à nouveau le test si l'une des situations suivantes se produit :

  • L'utilisateur change de caméra ou de microphone,
  • Le réseau de l'utilisateur change,
  • L'autorisation d'utiliser une caméra ou un microphone est à nouveau accordée après avoir été refusée,
  • L'utilisateur demande explicitement de réessayer,
  • Il s'écoule beaucoup de temps entre l'achèvement du test et l'adhésion.

Modèles d'hôtes ou de modérateurs

Si votre produit a un rôle d'hôte, de modérateur ou de présentateur, les participants peuvent rester dans la salle d'attente jusqu'à ce que l'hôte soit prêt à démarrer la session en direct. Dans certaines applications en petits groupes ou avec modérateur, les participants peuvent rejoindre la session avant que l'hôte ne publie et rester connectés mais sans publier jusqu'à ce que l'hôte soit prêt. Considérez cette approche de connexion mais de non-publication comme un modèle optionnel au niveau de l'application avec des compromis d'échelle, et non comme une recommandation générale ou une exigence de la plate-forme Video API. Pour les audiences plus importantes, la préconnexion de nombreux participants peut créer une vague d'abonnements lorsque l'hôte commence à publier. L'approche de la salle d'attente exemple d'application article présente un exemple de mise en œuvre.

Exécuter des tests de réseau

Utilisez la bibliothèque de test du réseau vidéo de Vonage pour vérifier si un client peut prendre en charge la publication audio et vidéo avant que les utilisateurs ne se joignent à une session.

Si votre application utilise des paramètres TURN ou proxy IP configurables, passez le paramètre correspondant iceConfig ou proxyServerUrl dans le test de réseau.

Contrôles de connectivité

Exécuter NetworkTest.testConnectivity() avant le test de qualité.

Ce contrôle permet de vérifier si le client peut accéder aux services requis pour une session Video API :

  • API la joignabilité,
  • Messagerie / signalisation WebSocket la joignabilité,
  • Routeur média la joignabilité,
  • Serveur de journalisation la joignabilité.

Interprétez ces résultats en fonction du mode de session utilisé par votre application :

  • Si le api ou messaging échoue, le client ne peut pas établir les connexions de session requises.
  • Si le media échoue, une session acheminée n'aboutira pas. Une session relayée peut quand même réussir, bien qu'elle puisse échouer si TURN est nécessaire.
  • Si le logging échoue, le client peut toujours se connecter, mais Vonage ne recueillera pas les données de journalisation habituelles utilisées par des outils tels que Inspector.

Contrôles de qualité

Si les résultats de la connectivité sont acceptables pour votre cas d'utilisation, lancez l'opération suivante NetworkTest.testQuality()à tester :

  • Support audio,
  • Support vidéo,
  • Débit binaire audio et vidéo,
  • Taux de perte de paquets audio et vidéo,
  • Résolution de publication recommandée,
  • Taux de rafraîchissement recommandé pour la publication,
  • qualityLimitationReason avec des valeurs bandwidth, cpuou null.

Remarque : Le test se déroule en mode audio-vidéo par défaut et peut se poursuivre en mode audio uniquement si nécessaire.

Tests de délai d'attente

Les timeout option pour les testQuality() accepte les valeurs supérieures à 5000 ms et moins de 30000 ms. Si vous ne le définissez pas, le test s'exécute pendant une durée approximative :

  • 30 secondes pour un test audio-vidéo,
  • 10 secondes pour un test audio uniquement.

Des délais plus courts réduisent la précision des résultats.

Support des navigateurs

testQuality() n'est pas pris en charge par Firefox. Dans ce cas, utilisez la salle d'attente pour les autorisations et la configuration de l'appareil, et faites confiance à testConnectivity() si vous souhaitez toujours une vérification avant appel de la connectivité uniquement.

Réseaux restreints

Sur les réseaux restreints, il convient de respecter les exigences documentées du réseau :

  • Préférer un environnement où UDP 3478 et TCP 443 sont disponibles.
  • Pour optimiser le temps d'installation et la qualité du média, autorisez également le protocole UDP sortant. 1025-65535 pour media ICE et SRTP.
  • Si seulement TCP 443 est disponible, la session peut toujours se connecter, mais il est plus probable que l'installation soit plus lente et que la qualité du média soit moindre.
  • Si un proxy est présent, il doit être transparent ou configuré pour les connexions HTTPS.

Sur les réseaux d'entreprise ou les réseaux restreints, vérifiez les mêmes ports et protocoles requis, puis ré-exécutez le test de connectivité avant que l'utilisateur ne se joigne au réseau.

Pour des environnements plus restrictifs, voir :

Statuts recommandés avant l'appel

Statut L'utiliser quand Que faire ensuite ?
Pass La connectivité réussit pour le mode de session que votre application utilise, les médias requis sont pris en charge, la perte de paquets est inférieure à 3 %, le débit binaire dépasse les seuils minimaux (≥150 kbps vidéo, ≥25 kbps audio), et les paramètres de publication recommandés sont acceptables pour l'appel. Laissez l'utilisateur s'inscrire. Appliquer la résolution de publication et la fréquence d'images recommandées lors de l'initialisation de l'éditeur.
Warn logging est le seul contrôle de connectivité qui a échoué, la perte de paquets est de 3 à 5 %, le débit binaire est faible mais récupérable, la résolution d'édition ou la fréquence d'images recommandée est réduite, ou qualityLimitationReason est bandwidth ou cpu. Montrez la raison dans la salle d'attente, laissez l'utilisateur réessayer et appliquez les paramètres de publication recommandés. Si nécessaire, permettez à l'utilisateur de continuer en l'avertissant clairement.
Fail api ou messaging ne fonctionne pas, media échoue pour le mode de session dont votre application a besoin, l'audio ou la vidéo requis n'est pas pris en charge, les autorisations ou l'acquisition du périphérique sont incomplètes, la perte de paquets dépasse 5 % ou le débit binaire tombe en dessous des seuils critiques (<150 kbps pour la vidéo, <25 kbps pour l'audio). Ne laissez pas l'utilisateur s'inscrire pour l'instant. Montrez le problème dans la salle d'attente et invitez l'utilisateur à réessayer après l'avoir résolu. Si l'audio est pris en charge mais que la vidéo ne l'est pas, vous pouvez proposer une participation audio uniquement.

Lorsque l'état est Warn ou FailLe signal de déclenchement est utilisé pour décider de la marche à suivre :

  • Si la question est bandwidthLe cas échéant, demandez à l'utilisateur de réessayer sur un réseau plus puissant ou moins restreint, ou continuez avec des paramètres de publication réduits.
  • Si la question est cpuLe cas échéant, l'utilisateur est invité à fermer les applications exigeantes, à désactiver les effets coûteux et à réessayer.
  • Si la question est logging l'utilisateur peut toujours se connecter, mais les données normales de l'inspecteur seront réduites.
  • Si le navigateur est Firefox, utilisez la salle d'attente pour les autorisations et la configuration de l'appareil, et utilisez testConnectivity() si vous avez besoin d'un contrôle préalable de la connectivité uniquement.

Interprétation des résultats des tests de réseau

Lors de l'établissement d'un statut de pré-appel, vérifiez :

  • Soutien ou non soutien,
  • Résultat de la connectivité,
  • Taux de perte de paquets (un taux inférieur à 3 % est acceptable ; un taux de 3 à 5 % justifie la prudence ; un taux supérieur à 5 % indique une défaillance),
  • Niveaux de débit (vidéo ≥150 kbps et audio ≥25 kbps sont des seuils minimums acceptables),
  • Résolution de publication et fréquence d'images recommandées,
  • qualityLimitationReason.

Si vous avez besoin de diagnostics de niveau inférieur, tels que le temps d'aller-retour, le nombre de blocages ou les statistiques RTC brutes, utilisez Client Observability ou le rapport de statistiques WebRTC brutes.

Signaux de qualité sur appel

Après l'adhésion de l'utilisateur :

  • Utilisation qualityScoreChanged pour suivre la qualité de l'abonné sur l'intégrateur d'appel 1-5 échelle,
  • Utilisation cpuPerformanceChanged pour réagir à la pression exercée par l'appareil sur les clients web,
  • Utilisez les événements de qualité de l'éditeur et de l'abonné de Client Observability lorsque vous avez besoin de plus de détails que ceux fournis par les contrôles de base avant appel.

Pour des conseils détaillés sur le web, voir Observabilité du client : Web.

Continuer après l'adhésion

Après l'adhésion de l'utilisateur, continuez avec :

Le repli audio de l'abonné nécessite une session acheminée. Le repli audio de l'éditeur est disponible à la fois dans les sessions routées et relayées.