Publier : Diagnostics

Ce guide explique comment obtenir des diagnostics pour les éditeurs et résoudre les problèmes les plus courants.

Obtenir des statistiques sur le flux d'un éditeur

Le SDK Video de Vonage expose des mesures détaillées de la qualité du flux par le biais d'une API de statistiques de haut niveau - recommandée pour la plupart des cas d'utilisation - qui fournit des statistiques audio, vidéo, réseau et côté expéditeur sous une forme unifiée et consciente de la session, qui reste stable lors des transitions de connexion entre pairs. Pour le débogage avancé, le SDK permet également d'accéder au rapport de statistiques WebRTC brut, qui reflète les données de connexion entre pairs non traitées.

Se référer à le guide du développeur de l'observabilité du client pour obtenir des informations détaillées.

Flux d'essai

Vous pouvez publier un flux de test et vérifier ses statistiques audio et vidéo afin de déterminer le type de flux (haute résolution ou audio uniquement) pris en charge par votre connexion.

Pour obtenir des statistiques sur un flux publié par le client local, vous devez utiliser une session qui utilise le routeur de médias (sessions dont le mode média est défini sur routé) et vous devez définir l'attribut testNetwork à la propriété true dans le options que vous passez dans l'objet Session.subscribe() méthode. Vous pouvez alors utiliser la méthode getStats() de l'objet Subscriber pour obtenir des statistiques audio et vidéo pour le flux que vous publiez.

Bonnes pratiques de publication

Cette section contient des conseils pour publier des flux avec succès.

Autoriser l'accès aux appareils

La meilleure pratique consiste à informer vos utilisateurs qu'ils devront autoriser l'accès à leur caméra et à leur microphone.

Nous constatons que le plus grand nombre d'échecs de publication est dû au fait que les utilisateurs ont cliqué sur le bouton "refuser" ou n'ont pas du tout cliqué sur le bouton "autoriser". Nous vous fournissons tous les événements dont vous avez besoin pour guider vos utilisateurs tout au long de ce processus :

publisher.on({
  accessDialogOpened: function (event) {
    // Show allow camera message
    pleaseAllowCamera.style.display = 'block';
  },
  accessDialogClosed: function (event) {
    // Hide allow camera message
    pleaseAllowCamera.style.display = 'none';
  }
});

C'est également une bonne idée d'utiliser le protocole SSL pour votre site web. En effet, Chrome ne demande aux utilisateurs de cliquer sur l'autorisation d'accès aux appareils qu'une seule fois par domaine si ce dernier est desservi par SSL. Cela signifie que vos utilisateurs (s'ils utilisent Chrome) n'ont pas à faire face à cette boîte de dialogue d'autorisation ou de refus à chaque fois qu'ils chargent la page.

Séparer OT.initPublisher() et Session.publish()

Nous recommandons également de diviser le OT.initPublisher() et Session.publish() étapes. Cela accélère le temps de connexion initial car vous vous connectez à la session en attendant que l'utilisateur clique sur le bouton d'autorisation. Ainsi, au lieu de :

session.connect(token, function (err) {
{... your error handling code ...}
if (!err) {
    var publisher = OT.initPublisher();
    session.publish(publisher);
  }
});

Déplacer le OT.initPublisher() avant de vous connecter, comme dans l'exemple suivant :

var publisher = OT.initPublisher();
session.connect(token, function (err) {
{... your error handling code ...}
  if (!err) {
    session.publish(publisher);
  }
});

Résolution et fréquence d'images

Vous pouvez définir la résolution et la fréquence d'images de l'éditeur lorsque vous l'initialisez :

OT.initPublisher(divId, {
  resolution: '320x240',
  frameRate: 15
});

Par défaut, la résolution d'un éditeur est de 640x480, mais vous pouvez également la régler sur 1920x1080, 1280x720 ou 320x240. Il est préférable d'essayer de faire correspondre la résolution à la taille d'affichage de la vidéo. Si vous n'affichez la vidéo qu'à 320x240 pixels, il est inutile de la diffuser à 1280x720 ou 1920x1080. La réduction de la résolution permet d'économiser de la bande passante et de réduire les encombrements et les interruptions de connexion.

Par défaut, la fréquence d'images de la vidéo est de 30 images par seconde, mais vous pouvez également la régler sur 15, 7 ou 1. La réduction de la fréquence d'images permet de réduire la bande passante requise. Les vidéos à faible résolution peuvent avoir une fréquence d'images plus faible sans que l'utilisateur perçoive une différence notable. Par conséquent, si vous utilisez une faible résolution, vous pouvez également envisager d'utiliser une faible fréquence d'images.

Dépannage

Suivez les conseils de cette section pour éviter les problèmes de connectivité lors de la publication. Pour des informations générales sur le dépannage, voir Débogage - Web.

Traitement des erreurs

Il existe des méthodes de rappel pour les deux Session.publish() et OT.initPublisher(). Nous recommandons de gérer les réponses d'erreur à ces deux méthodes. Comme nous l'avons déjà mentionné, il est préférable de séparer ces étapes et d'appeler OT.initPublisher() avant d'avoir commencé à vous connecter à votre session. Il est également plus facile de gérer les erreurs si vous n'appelez pas ces deux méthodes en même temps. En effet, les deux gestionnaires d'erreurs se déclenchent en cas de publication d'une erreur. Il est préférable d'attendre que OT.initPublisher() à compléter et Session.connect() et appeler ensuite Session.publish(). De cette façon, vous pouvez traiter tous les problèmes liés au matériel dans l'espace de travail. OT.initPublisher() et tous les problèmes liés au réseau dans le Session.publish() rappel.

var connected = false,
  publisherInitialized = false;

var publisher = OT.initPublisher(function(err) {
  if (err) {
    // handle error
  } else {
    publisherInitialized = true;
    publish();
  }
});

var publish = function() {
  if (connected && publisherInitialized) {
    session.publish(publisher);
  }
};

session.connect(token, function(err) {
  if (err) {
    // handle error
  } else {
    connected = true;
    publish();
  }
});

Accès refusé

Le plus grand nombre d'échecs de OT.initPublisher() sont dues au fait que l'utilisateur final refuse l'accès à la caméra et au microphone. Il est possible d'y remédier en écoutant le message accessDenied ou en écoutant une réponse d'erreur à la méthode OT.initPublisher() avec une valeur de code fixée à 1500 et un message avec la valeur "Publisher Access Denied :". Nous vous recommandons de traiter ce cas et d'envoyer un message à l'utilisateur pour lui indiquer qu'il doit réessayer de publier et autoriser l'accès à la caméra.

publisher.on({
  'accessDenied': function() {
    showMessage('Please allow access to the Camera and Microphone and try publishing again.');
  }
});

Accès au dispositif

Une autre raison pour OT.initPublisher() L'échec d'OpenTok est dû au fait qu'il ne peut pas accéder à une caméra ou à un microphone. Cela peut se produire s'il n'y a pas de caméra ou de microphone attaché à la machine, s'il y a un problème avec le pilote de la caméra ou du microphone, ou si une autre application utilise la caméra ou le microphone (cela ne se produit que sous Windows). Vous pouvez essayer de minimiser l'occurrence de ces problèmes en utilisant notre composant de configuration du matériel ou en appelant la fonction OT.getDevices() directement. Cependant, vous devez également gérer toute erreur lors de l'appel de la méthode OT.initPublisher() car un problème peut toujours survenir. Par exemple, l'utilisateur peut avoir refusé l'accès à la caméra ou au microphone. Dans ce cas, le error.name est fixée à "OT_USER_MEDIA_ACCESS_DENIED":

publisher = OT.initPublisher('publisher', {}, function (err) {
  if (err) {
    if (err.name === 'OT_USER_MEDIA_ACCESS_DENIED') {
      // Access denied can also be handled by the accessDenied event
      showMessage('Please allow access to the Camera and Microphone and try publishing again.');
    } else {
      showMessage('Failed to get access to your camera or microphone. Please check that your webcam'
        + ' is connected and not being used by another application and try again.');
    }
    publisher.destroy();
    publisher = null;
  }
});

Erreurs de réseau

Les autres raisons des échecs de publication sont généralement dues à une défaillance du réseau. Nous les gérons dans le rappel à Session.publish(). Si l'utilisateur n'est pas connecté au réseau, la fonction de rappel reçoit un objet d'erreur avec la valeur name est définie comme étant la propriété "OT_NOT_CONNECTED". Si l'utilisateur dispose d'une connexion réseau très restrictive qui n'autorise pas les connexions WebRTC, l'éditeur ne parvient pas à se connecter et l'élément Publisher affiche une roue qui tourne. Cette erreur a une name est définie comme étant la propriété "OT_CREATE_PEER_CONNECTION_FAILED". Dans ce cas, nous vous recommandons d'envoyer un message à l'utilisateur pour lui indiquer qu'il n'a pas réussi à publier et qu'il doit vérifier sa connexion réseau. La gestion de ces erreurs se fait de la manière suivante :

session.publish(publisher, function(err) {
  if (err) {
    switch (err.name) {
      case "OT_NOT_CONNECTED":
        showMessage("Publishing your video failed. You are not connected to the internet.");
        break;
      case "OT_CREATE_PEER_CONNECTION_FAILED":
        showMessage("Publishing your video failed. This could be due to a restrictive firewall.");
        break;
      default:
        showMessage("An unknown error occurred while trying to publish your video. Please try again later.");
    }
    publisher.destroy();
    publisher = null;
  }
});

Perte de connectivité

Votre éditeur peut également perdre sa connexion après avoir réussi à se connecter. Le plus souvent, la Session perd également sa connexion, mais ce n'est pas toujours le cas. Vous pouvez gérer la déconnexion de l'éditeur en écoutant la commande streamDestroyed avec un reason à "networkDisconnected" comme suit :

publisher.on({
  streamDestroyed: function (event) {
    if (event.reason === 'networkDisconnected') {
      showMessage('Your publisher lost its connection. Please check your internet connection and try publishing again.');
    }
  }
});

Mise en œuvre des tentatives de publication de session

Les échecs temporaires de publication constituent un phénomène connu et récurrent dans le SDK JS de la Video API, en particulier sur les navigateurs mobiles. Lorsque session.publish() En cas d'échec, le SDK renvoie une erreur via la fonction de rappel de son gestionnaire de fin d'exécution. Il est recommandé de mettre en place une logique de nouvelle tentative au niveau de l'application, en prévoyant un délai entre chaque tentative.

Comment session.publish() Œuvres

session.publish() peut être appelée de deux façons :

• Avec un éditeur pré-initialisé : session.publish(publisher, callback) — tu appelles OT.initPublisher() Tout d'abord, transmettez ensuite l'instance d'éditeur obtenue à session.publish(). Il s'agit du approche recommandée car cela permet de dissocier l'acquisition des médias de la création du flux, ce qui rend la gestion des erreurs plus claire.
• Sans instance d'éditeur : session.publish(targetElement, options, callback) — le SDK appelle en interne OT.initPublisher() pour vous. Dans ce cas, les erreurs d’acquisition de médias et les erreurs de création de flux apparaissent toutes deux via le même session.publish() rappel.

// Recommended: split initialization from publishing
let publisherReady = false;
let sessionConnected = false;

const publisher = OT.initPublisher('publisher-container', publisherOptions, (err) => {
  if (err) {
    handleInitPublisherError(err); // hardware/media errors — see OT.initPublisher() errors below
    return;
  }
  publisherReady = true;
  maybePublish();
});

session.connect(token, (err) => {
  if (err) { /* handle connection error */ return; }
  sessionConnected = true;
  maybePublish();
});

function maybePublish() {
  if (sessionConnected && publisherReady) {
    publishWithRetry(session, publisher);
  }
}

Pourquoi les échecs de publication se produisent-ils ?

Les causes principales les plus courantes des échecs de publication temporaires sont les suivantes :

• Dépassement du délai d'attente de StreamCreateRequest (erreur 1500) : L'éditeur n'a pas réussi à finaliser la création du flux dans un délai raisonnable — ce qui est généralement dû à des retards réseau lors de la négociation ICE/SDP.
• mediaStopped événements survenant au cours du processus de publication, où l'accès aux périphériques multimédias peut être interrompu.
• Réutilisation d'un objet « Publisher » sans nettoyage approprié — réutiliser une instance d'éditeur initialisée avec des contraintes différentes sans appeler unpublish et la réinitialisation.
• OT_NOT_CONNECTED — tentative de publication avant que la session ne soit entièrement établie.
• OT_PERMISSION_DENIED — Le jeton ne dispose pas du rôle « publish » (erreur irréversible).

Erreurs provenant de OT.initPublisher()

Lorsque vous pré-initialisez un éditeur avec OT.initPublisher(), toutes les erreurs matérielles et d'acquisition de données multimédia sont transmises à son gestionnaire de fin d'exécution — avant session.publish() est appelée. Traitez-les dans cette fonction de rappel à l'aide des actions spécifiques à chaque type d'erreur décrites ci-dessous : certaines nécessitent une intervention de l'utilisateur ou une correction du code, tandis que les erreurs temporaires liées aux médias peuvent être résolues en réinitialisant l'éditeur.

const publisher = OT.initPublisher('publisher-container', publisherOptions, (err) => {
  if (!err) {
    publisherReady = true;
    maybePublish();
    return;
  }

  // Hardware/media errors — handle before session.publish() is called
  switch (err.name) {
    case 'OT_REQUESTED_DEVICE_PERMISSION_DENIED':
      showMessage('Please allow access to your camera and microphone and try again.');
      break;
    case 'OT_HARDWARE_UNAVAILABLE':
    case 'OT_NO_DEVICES_FOUND':
      showMessage('Could not access your camera or microphone. Please check your devices.');
      break;
    case 'OT_SCREEN_SHARING_NOT_SUPPORTED':
    case 'OT_UNABLE_TO_CAPTURE_SCREEN':
    case 'OT_SCREEN_SHARING_EXTENSION_NOT_REGISTERED':
    case 'OT_SCREEN_SHARING_EXTENSION_NOT_INSTALLED':
      showMessage('Screen sharing is not available. Please check your browser settings.');
      break;
    default:
      showMessage('Could not initialize the publisher. Please try again.');
  }

  publisher.destroy();
});

Erreurs récupérables et non récupérables provenant de session.publish()

Pas tous session.publish() les erreurs ne se valent pas toutes. Avant de mettre en place une logique de réessai, il est essentiel de classer correctement les erreurs : tenter un réessai en cas d’erreur irrémédiable fait perdre du temps, nuit à l’expérience utilisateur et peut masquer de véritables défaillances qui nécessitent une réponse différente.

Erreurs irrémédiables — Ne pas réessayer

Ces erreurs sont dues à des erreurs de programmation, à des contraintes strictes en matière d'autorisations ou à un contexte d'appel non valide. Une nouvelle tentative ne permettra pas de les résoudre. Il convient plutôt d'afficher un message clair à l'utilisateur ou de corriger la logique de l'application.

Erreurs récupérables — On peut réessayer en toute sécurité

Ces erreurs sont généralement dues à des perturbations passagères du réseau, à des délais d'attente de signalisation ou à une indisponibilité temporaire de la plateforme. Elles constituent la cible principale de la logique de réessai.

Erreurs nécessitant une action différente (autre qu'une simple nouvelle tentative)

Certaines erreurs ne peuvent être ni simplement réessayées ni définitivement interrompues : elles nécessitent une action corrective spécifique avant toute nouvelle tentative.

Synthèse : modèle de nouvelle tentative recommandé avec classification des erreurs

async function publishWithRetry(session, publisher, attempt = 1) {
  const MAX_RETRIES = 3;
  const RETRY_DELAY_MS = 2000;

  const error = await new Promise((resolve) => {
    session.publish(publisher, resolve);
  });

  if (!error) {
    console.log('Publishing started successfully.');
    return;
  }

  // Non-recoverable: programmer error or hard permission constraint
  const nonRetryable = [
    'OT_NOT_CONNECTED',
    'OT_PERMISSION_DENIED',
    'OT_INVALID_PARAMETER',
    'OT_USER_MEDIA_ACCESS_DENIED',
    'OT_CHROME_MICROPHONE_ACQUISITION_ERROR',
    'OT_SCREEN_SHARING_NOT_SUPPORTED',
    'OT_SCREEN_SHARING_EXTENSION_NOT_REGISTERED',
    'OT_SCREEN_SHARING_EXTENSION_NOT_INSTALLED',
    'OT_CONSTRAINTS_NOT_SATISFIED',
    'OT_NO_VALID_CONSTRAINTS',
    'OT_NOT_SUPPORTED',
    'OT_STREAM_CREATE_FAILED',
    'OT_INVALID_AUDIO_OUTPUT_SOURCE',
    'OT_UNABLE_TO_CAPTURE_MEDIA',
  ];

  // Requires corrective action before retrying
  const requiresAction = [
    'OT_HARDWARE_UNAVAILABLE',
    'OT_NO_DEVICES_FOUND',
  ];

  if (nonRetryable.includes(error.name)) {
    console.error('Non-retryable error — user action or code fix required:', error.name);
    handleNonRecoverableError(error);
    return;
  }

  if (requiresAction.includes(error.name)) {
    console.warn('Device error — prompting user before retrying:', error.name);
    handleDeviceError(error);
    return;
  }

  // Recoverable: retry with backoff
  if (attempt < MAX_RETRIES) {
    console.warn(`Publish attempt ${attempt} failed (${error.name}), retrying...`);
    await delay(RETRY_DELAY_MS * attempt);
    await publishWithRetry(session, publisher, attempt + 1);
  } else {
    console.error('All publish attempts failed. Disconnecting user.');
    handlePublishFailure(session);
  }
}

function handleNonRecoverableError(error) {
  // Surface a meaningful message to the user based on error.name
  // e.g. for OT_USER_MEDIA_ACCESS_DENIED: "Please allow camera/mic access"
}

function handleDeviceError(error) {
  // Prompt the user to check their device, then allow them to retry manually
}

function handlePublishFailure(session) {
  session.disconnect();
}

Utilisation :

const publisher = OT.initPublisher('publisher-container', publisherOptions);

// Wait for session to be connected before publishing
session.connect(token, (err) => {
  if (err) { /* handle connection error */ return; }
  publishWithRetry(session, publisher);
});

Important : nettoyage de l'éditeur avant de réessayer

Dans la plupart des scénarios de défaillance — notamment OT_TIMEOUT / OT_ICE_WORKFLOW_FAILED — l'instance de l'éditeur peut être réutilisé directement pour le prochain session.publish() appel. Vous n'avez pas besoin de le réinitialiser.

Lorsqu'une tentative de publication échoue, le SDK interrompt le flux qu'il tentait de créer et génère un streamDestroyed événement sur l'éditeur avec reason: "reset". Il s'agit d'un nettoyage prévu qui pas vous obligent à réinitialiser l'éditeur — vous pouvez réessayer avec la même instance. Notez que "reset" Il s'agit d'un motif général indiquant que « le flux de l'éditeur a été interrompu » (il est également généré lorsque vous appelez publisher.destroy()), considérez-le donc comme un signal de nettoyage plutôt que comme un indicateur spécifique d'échec de publication ; utilisez la error.name de la session.publish() fonction de rappel permettant de décider s'il faut réessayer.

Le SDK permet de pas réessayer automatiquement session.publish() en votre nom — la logique de nouvelle tentative doit être mise en œuvre au niveau de l'application, comme indiqué ci-dessus.

Le seul cas où vous devez réinitialiser l'éditeur avec OT.initPublisher() Avant de réessayer, c'est lorsque l'éditeur lui-même destroyed L'événement se déclenche. Cet événement est définitif et indique que l'objet émetteur lui-même n'est plus utilisable.

publisher.on('destroyed', () => {
  // Publisher object is no longer usable — reinitialize before retrying
  publisher = OT.initPublisher('publisher-container', publisherOptions);
});

// A streamDestroyed event with reason 'reset' is emitted by the SDK when it tears
// down the stream (during a failed publish attempt, or when you call publisher.destroy()).
// A 'reset' during a failed publish does NOT require reinitializing the publisher.
publisher.on('streamDestroyed', (event) => {
  if (event.reason === 'reset') {
    // Expected cleanup — reuse the same publisher instance
    return;
  }
  // Handle other streamDestroyed reasons as appropriate for your application
});

Ce qu'il ne faut PAS faire

• Faire pas appel OT.initPublisher() deux fois sur le même objet « publisher » avec des contraintes différentes sans avoir effectué de nettoyage au préalable (session.unpublish() → attendre streamDestroyed → puis réinitialiser).
• Faire pas réessayer le OT_PERMISSION_DENIED (l'utilisateur a refusé l'accès à la caméra/au micro) — cela nécessite une intervention de l'utilisateur, et non une nouvelle tentative.
• Faire pas réessayer le OT_NOT_CONNECTED — assurez-vous que la session est bien connectée avant de publier.
• Faire pas réessayer indéfiniment — limiter à 3 tentatives et gérer l'échec de manière appropriée.

Gestion de la mediaStopped Événement

La lecture du fichier multimédia peut être interrompue en cours de publication. Surveillez cet événement et considérez-le comme un déclencheur pour relancer la publication :

publisher.on('mediaStopped', async () => {
  console.warn('Media stopped during publish — retrying...');
  // Unpublish if already publishing, then retry
  try { session.unpublish(publisher); } catch (e) { /* ignore */ }
  await delay(2000);
  publishWithRetry(session, publisher);
});

Résumé des paramètres recommandés

Résolution des problèmes liés à la capture audio : audioAcquisitionProblem et audioAcquisitionProblemResolved

Au-delà des tentatives de publication, il existe une autre catégorie de problèmes audio pouvant affecter un éditeur actif : le périphérique audio du client peut ne pas parvenir à transmettre les données audio, même après une publication réussie. Le SDK JS de la Video API propose deux événements spécialement conçus pour ce cas de figure.

Causes courantes

Les audioAcquisitionProblem Cet événement est déclenché lorsque le SDK détecte — via les statistiques de l'éditeur — que la piste audio a cessé d'envoyer des octets à la connexion entre pairs, même si getUserMedia L'opération a abouti et l'éditeur semble actif. Les causes principales les plus courantes sont les suivantes :

• Appareil audio Bluetooth connecté ou déconnecté en cours de session : Lorsqu'un utilisateur branche ou débranche des écouteurs, ou connecte un casque Bluetooth (par exemple, des AirPods) au cours d'une session active, le système d'exploitation peut changer de périphérique audio par défaut. Il peut arriver que le pipeline audio du navigateur ne parvienne pas à reconnecter le microphone sur le nouveau périphérique, ce qui entraîne l'absence totale d'envoi d'octets audio.
• Changement de périphérique audio au démarrage de la session : Le fait de changer d'entrée audio très tôt dans la session — dans les 1 à 2 premières secondes suivant la publication — est particulièrement susceptible de déclencher ce problème.
• Piste audio interrompue par le navigateur ou le système d'exploitation (trackEndedEvent) : Le navigateur peut interrompre la piste audio sous-jacente indépendamment de toute action de l'utilisateur. Le SDK détecte cela via un track.ended événement et soulève audioAcquisitionProblem avec method: trackEndedEvent.
• Détection basée sur les statistiques (absence de flux d'octets audio) : Une fois que la connexion entre pairs est établie, le SDK interroge les statistiques de l'éditeur toutes les quelques secondes environ. Si la piste audio sortante bytesSent n'augmente pas d'un sondage à l'autre, audioAcquisitionProblem est soulevée (avec method: getStats). Lorsque bytesSent commence à augmenter à nouveau, audioAcquisitionProblemResolved est soulevée.

Les événements

Ces événements sont émis sur l'instance de l'éditeur :

• audioAcquisitionProblem — déclenché lorsque le SDK détecte que l'éditeur a cessé d'envoyer du contenu audio (d'après les statistiques de l'éditeur), ou lorsque la piste audio sous-jacente déclenche un ended événement. Cela ne signifie pas nécessairement que la diffusion va échouer, mais cela indique que la capture audio a été interrompue.
• audioAcquisitionProblemResolved — déclenché lorsque la transmission audio est rétablie après une audioAcquisitionProblem. Si cet événement se produit, aucune mesure corrective n'est nécessaire.

Modèle de récupération recommandé

Lancer un minuteur court dès la réception audioAcquisitionProblem. Si audioAcquisitionProblemResolved Si le problème disparaît avant la fin du délai, cela signifie que le son s'est rétabli de lui-même et qu'aucune intervention n'est nécessaire. Si le délai expire sans que le problème ne soit résolu, changez de source audio pour rétablir le son.

publisher.on('audioAcquisitionProblem', () => {
  // Start a 3-second timer
  const timeout = setTimeout(() => {
    // Problem not resolved — attempt recovery by switching audio source
    publisher.setAudioSource(newDeviceId);
  }, 3000);

  publisher.on('audioAcquisitionProblemResolved', () => {
    // Audio recovered — clear the timer, no action needed
    clearTimeout(timeout);
  });
});

Éléments clés à prendre en compte

• Ce n'est pas un indicateur d'échec certain : audioAcquisitionProblem Cela n'entraîne pas systématiquement l'échec de l'abonnement. Considérez-le comme un signal précoce permettant de surveiller la situation et, le cas échéant, d'intervenir, et non comme un échec définitif.
• Suivre les statistiques audio de l'éditeur : Après avoir reçu audioAcquisitionProblem, vous pouvez également suivre les statistiques audio de l'éditeur (par exemple, via publisher.getStats()) afin de vérifier si la transmission audio a bien cessé avant d'intervenir.
• Mesures de rétablissement : Appel publisher.setAudioSource(newDeviceId) Il s'agit du principal mécanisme de récupération. Cela permet de changer de périphérique d'entrée audio sans avoir à passer par un cycle complet de désactivation puis de réactivation.
• Lien avec les délais d'expiration des abonnements : Si le flux audio n'est pas rétabli et que l'éditeur continue de ne pas envoyer de paquets audio, les abonnés risquent à terme de se retrouver face à OT_TIMEOUT (1501). Gestion proactive de audioAcquisitionProblem peut permettre d’éviter cette défaillance en aval.