Veröffentlichen: Diagnostik

In diesem Leitfaden erfahren Sie, wie Sie Diagnosen für Verlage erstellen und häufige Probleme beheben können.

Abrufen von Statistiken über den Stream eines Verlegers

Das Vonage Video SDK stellt detaillierte Metriken zur Stream-Qualität über eine High-Level-Statistik-API zur Verfügung, die für die meisten Anwendungsfälle empfohlen wird und die Audio-, Video-, Netzwerk- und Absenderstatistiken in einer einheitlichen, sitzungsspezifischen Form bereitstellt, die über Peer-Verbindungsübergänge hinweg stabil bleibt. Für fortgeschrittenes Debugging bietet das SDK auch Zugriff auf den rohen WebRTC-Statistikbericht, der unverarbeitete Peer-Verbindungsdaten wiedergibt.

Siehe das Handbuch für Entwickler von Client Observability für detaillierte Informationen.

Test stream

Sie können einen Teststream veröffentlichen und dessen Audio- und Videostatistiken überprüfen, um die Art des Streams (z. B. hochauflösend oder nur Audio) zu ermitteln, die von Ihrer Verbindung unterstützt wird.

Um Statistiken für einen Stream zu erhalten, der vom lokalen Client veröffentlicht wurde, müssen Sie eine Sitzung verwenden, die den Media Router nutzt (Sitzungen, bei denen der Medienmodus auf geroutet eingestellt ist), und Sie müssen die Option testNetwork Eigenschaft zu true im options Objekt, das Sie an die Session.subscribe() Methode. Sie können dann die getStats() Methode des Subscriber-Objekts, um Audio- und Videostatistiken für den von Ihnen veröffentlichten Stream zu erhalten.

Bewährte Praktiken bei der Veröffentlichung

Dieser Abschnitt enthält Tipps für die erfolgreiche Veröffentlichung von Streams.

Zugriff auf das Gerät zulassen

Es empfiehlt sich, die Nutzer darüber zu informieren, dass sie aufgefordert werden, den Zugriff auf ihre Kamera und ihr Mikrofon zu gestatten.

Wir haben festgestellt, dass die weitaus meisten Fehler bei der Veröffentlichung darauf zurückzuführen sind, dass Benutzer auf die Schaltfläche "Verweigern" klicken oder die Schaltfläche "Zulassen" überhaupt nicht anklicken. Wir stellen Ihnen alle Ereignisse zur Verfügung, die Sie benötigen, um Ihre Benutzer durch diesen Prozess zu führen:

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

Es ist auch eine gute Idee, Ihre Website über SSL bereitzustellen. Der Grund dafür ist, dass Chrome von den Nutzern nur einmal pro Domain verlangt, den Zugriff auf Geräte zu erlauben, wenn diese Domain über SSL bereitgestellt wird. Das bedeutet, dass Ihre Nutzer (wenn sie Chrome verwenden) nicht jedes Mal, wenn sie die Seite laden, mit dem lästigen Dialogfeld "Zulassen/Ablehnen" konfrontiert werden.

OT.initPublisher() und Session.publish() aufteilen

Außerdem empfehlen wir die Aufteilung der OT.initPublisher() und Session.publish() Schritte. Dadurch wird die anfängliche Verbindungszeit verkürzt, da Sie eine Verbindung zur Sitzung herstellen, während Sie darauf warten, dass der Benutzer auf die Schaltfläche "Zulassen" klickt. Also statt:

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

Bewegen Sie die OT.initPublisher() bevor Sie eine Verbindung herstellen, wie im Folgenden beschrieben:

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

Auflösung und Bildrate

Sie können die Auflösung und die Bildrate des Publishers bei der Initialisierung einstellen:

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

Standardmäßig ist die Auflösung eines Publishers 640x480, aber Sie können sie auch auf 1920x1080, 1280x720 oder 320x240 einstellen. Am besten versuchen Sie, die Auflösung an die Größe anzupassen, in der das Video angezeigt werden soll. Wenn Sie das Video nur mit 320x240 Pixeln anzeigen, macht es keinen Sinn, mit 1280x720 oder 1920x1080 zu streamen. Durch die Verringerung der Auflösung können Sie Bandbreite sparen und Überlastungen und Verbindungsabbrüche vermeiden.

Standardmäßig beträgt die Bildrate des Videos 30 Bilder pro Sekunde, aber Sie können sie auch auf 15, 7 oder 1 einstellen. Durch die Verringerung der Bildrate kann die erforderliche Bandbreite reduziert werden. Videos mit geringerer Auflösung können eine niedrigere Bildrate haben, ohne dass der Benutzer einen großen Unterschied bemerkt. Wenn Sie also eine niedrige Auflösung verwenden, sollten Sie auch eine niedrige Bildrate in Betracht ziehen.

Fehlersuche

Befolgen Sie die Tipps in diesem Abschnitt, um Konnektivitätsprobleme bei der Veröffentlichung zu vermeiden. Allgemeine Informationen zur Fehlerbehebung finden Sie unter Fehlersuche - Web.

Umgang mit Fehlern

Es gibt Callback-Methoden für beide Session.publish() und OT.initPublisher(). Wir empfehlen, die Fehlerantworten auf diese beiden Methoden zu behandeln. Wie bereits erwähnt, ist es am besten, diese Schritte aufzuteilen und die OT.initPublisher() bevor Sie mit der Verbindung zu Ihrer Sitzung begonnen haben. Es erleichtert auch die Fehlerbehandlung, wenn Sie nicht beide Methoden gleichzeitig aufrufen. Der Grund dafür ist, dass beide Fehlerbehandlungsmethoden ausgelöst werden, wenn ein Fehler veröffentlicht wird. Es ist am besten, zu warten, bis OT.initPublisher() zu vervollständigen und Session.connect() zu vervollständigen, und rufen Sie dann Session.publish(). Auf diese Weise können Sie alle hardwarebezogenen Probleme in der OT.initPublisher() Rückruf und alle netzbezogenen Fragen in der Session.publish() Rückruf.

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();
  }
});

Zugang verweigert

Die höchste Anzahl von Misserfolgen bei OT.initPublisher() sind darauf zurückzuführen, dass der Endnutzer den Zugang zu Kamera und Mikrofon verweigert. Dies kann entweder durch Abhören des accessDenied Ereignis oder durch Abwarten einer Fehlerantwort auf die Methode OT.initPublisher() mit einer code Eigenschaft auf 1500 gesetzt und eine message Eigenschaft auf "Publisher Access Denied:" gesetzt. Wir empfehlen, dass Sie diesen Fall behandeln und dem Benutzer eine Meldung anzeigen, dass er versuchen sollte, erneut zu veröffentlichen und den Zugriff auf die Kamera zu erlauben.

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

Zugang zum Gerät

Ein weiterer Grund für OT.initPublisher() Wenn OpenTok nicht auf eine Kamera oder ein Mikrofon zugreifen kann, schlägt das Programm fehl. Dies kann passieren, wenn keine Kamera oder kein Mikrofon an den Rechner angeschlossen ist, wenn etwas mit dem Treiber für die Kamera oder das Mikrofon nicht stimmt oder wenn eine andere Anwendung die Kamera oder das Mikrofon verwendet (dies geschieht nur unter Windows). Sie können versuchen, das Auftreten dieser Probleme zu minimieren, indem Sie unsere Hardware-Setup-Komponente verwenden oder die Funktion OT.getDevices() Methode direkt. Sie sollten jedoch auch jeden Fehler behandeln, wenn Sie OT.initPublisher() denn es kann immer noch etwas schief gehen. Zum Beispiel könnte der Benutzer den Zugriff auf die Kamera oder das Mikrofon verweigert haben. In diesem Fall muss die error.name Eigenschaft wird auf "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;
  }
});

Netzwerk-Fehler

Die anderen Gründe für Fehler bei der Veröffentlichung sind in der Regel auf eine Art von Netzwerkfehler zurückzuführen. Wir behandeln diese in dem Callback zu Session.publish(). Wenn der Benutzer nicht mit dem Netz verbunden ist, wird der Callback-Funktion ein Fehlerobjekt mit dem name Eigenschaft eingestellt auf "OT_NOT_CONNECTED". Wenn der Benutzer über eine sehr restriktive Netzwerkverbindung verfügt, die keine WebRTC-Verbindungen zulässt, kann der Publisher keine Verbindung herstellen, und das Publisher-Element zeigt ein sich drehendes Rad an. Dieser Fehler hat eine name Eigenschaft eingestellt auf "OT_CREATE_PEER_CONNECTION_FAILED". In diesem Fall empfiehlt es sich, dem Benutzer eine Nachricht zu übermitteln, die ihn darauf hinweist, dass die Veröffentlichung fehlgeschlagen ist und dass er seine Netzwerkverbindung überprüfen sollte. Die Behandlung dieser Fehler sieht folgendermaßen aus:

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;
  }
});

Verlust der Konnektivität

Ihr Publisher kann auch die Verbindung verlieren, nachdem er bereits eine Verbindung hergestellt hat. In den meisten Fällen führt dies dazu, dass auch die Sitzung ihre Verbindung verliert, aber das ist nicht immer der Fall. Sie können das Trennen der Verbindung des Publishers behandeln, indem Sie auf die streamDestroyed Ereignis mit einer reason Eigenschaft auf "networkDisconnected" wie folgt eingestellt:

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

Implementierung von Wiederholungsversuchen bei der Veröffentlichung von Sitzungen

Vorübergehende Fehler beim Veröffentlichen sind ein bekanntes und wiederkehrendes Problem im Video API-JS-SDK, insbesondere in mobilen Browsern. Wenn session.publish() Schlägt der Vorgang fehl, gibt das SDK über den Callback des Completion-Handlers einen Fehler zurück. Es wird empfohlen, auf Anwendungsebene eine Wiederholungslogik mit einer Verzögerung zwischen den Versuchen zu implementieren.

Warum es zu Veröffentlichungsfehlern kommt

Die häufigsten Ursachen für vorübergehende Veröffentlichungsfehler sind:

• Zeitüberschreitungen bei „StreamCreateRequest“ (Fehler 1500): OT.Publisher Die Veröffentlichung konnte nicht innerhalb einer angemessenen Zeitspanne erfolgen – dies wird in der Regel durch Medienunterbrechungen oder Netzwerkverzögerungen während der ICE-/SDP-Verhandlung verursacht.
• mediaStopped Ereignisse während des Veröffentlichungsablaufs, wo der Zugriff auf Mediengeräte unterbrochen werden kann.
• Wiederverwendung von Publisher-Objekten ohne ordnungsgemäße Bereinigung — Wiederverwendung einer Publisher-Instanz, die mit anderen Einschränkungen initialisiert wurde, ohne den Aufruf unpublish und neu zu initialisieren.
• OT_NOT_CONNECTED — Versuch, etwas zu veröffentlichen, bevor die Sitzung vollständig hergestellt ist.
• OT_USER_MEDIA_ACCESS_DENIED — Probleme beim Zugriff auf das Gerät (kein erneuter Versuch möglich).

Behebbare vs. nicht behebbare Fehler

Nicht alle session.publish() Fehler sind nicht alle gleich. Vor der Implementierung einer Wiederholungslogik ist es unerlässlich, Fehler korrekt zu klassifizieren – der erneute Versuch bei einem nicht behebbaren Fehler verschwendet Zeit, verschlechtert das Benutzererlebnis und kann echte Fehler verschleiern, die eine andere Reaktion erfordern.

Unbehebbare Fehler – Nicht erneut versuchen

Diese Fehler sind auf Programmierfehler, strenge Berechtigungsbeschränkungen oder einen ungültigen Aufrufkontext zurückzuführen. Ein erneuter Versuch führt nicht zur Behebung dieser Fehler. Zeigen Sie dem Benutzer stattdessen eine aussagekräftige Meldung an oder korrigieren Sie die Anwendungslogik.

Behebbare Fehler – Wiederholung des Versuchs ist unbedenklich

Diese Fehler werden in der Regel durch vorübergehende Netzwerkstörungen, Zeitüberschreitungen bei der Signalübertragung oder eine vorübergehende Nichtverfügbarkeit der Plattform verursacht. Sie sind das Hauptziel der Wiederholungslogik.

Fehler, die eine andere Maßnahme erfordern (keinen einfachen erneuten Versuch)

Manche Fehler lassen sich weder durch einen einfachen erneuten Versuch noch durch einen vollständigen Abbruch beheben – sie erfordern eine bestimmte Korrekturmaßnahme, bevor ein erneuter Versuch unternommen werden kann.

Zusammenfassung: Empfohlenes Wiederholungsmuster mit Fehlerklassifizierung

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();
}

Verwendung:

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);
});

Wichtig: Bereinigung der Publisher vor einem erneuten Versuch

In den meisten Ausfallszenarien – einschließlich OT_TIMEOUT / OT_ICE_WORKFLOW_FAILED — die Publisher-Instanz kann wiederverwendet werden direkt für das nächste session.publish() Aufruf. Sie müssen es nicht neu initialisieren.

Im Rahmen der internen Wiederholungsfunktion des SDK (eingeführt in Version 2.35) löscht das SDK nun intern den Stream, wenn ein Veröffentlichungsversuch fehlschlägt, was zu einem streamDestroyed Veranstaltung mit reason: reset die vom Herausgeber ausgegeben werden sollen. Dies ist ein erwartetes Verhalten und führt dazu, dass nicht erfordert eine Neuinitialisierung des Publishers – Sie können es mit derselben Instanz erneut versuchen.

Der einzige Fall, in dem Sie den Publisher mit OT.initPublisher() Bevor ein erneuter Versuch unternommen wird, ist der Zeitpunkt, zu dem der Herausgeber selbst destroyed Das Ereignis wird ausgelöst. Dieses Ereignis ist endgültig und zeigt an, dass das Publisher-Objekt selbst nicht mehr verwendbar ist.

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 internally by the SDK
// during a failed publish attempt — this does NOT require reinitializing the publisher
publisher.on('streamDestroyed', (event) => {
  if (event.reason === 'reset') {
    // Expected during retry flow — reuse the same publisher instance
    return;
  }
  // Handle other streamDestroyed reasons as appropriate for your application
});

Was man NICHT tun sollte

• Do nicht aufrufen OT.initPublisher() zweimal auf dasselbe Publisher-Objekt mit unterschiedlichen Einschränkungen, ohne vorher die Daten zu bereinigen (session.unpublish() → warten, bis streamDestroyed → dann neu initialisieren).
• Do nicht Erneut versuchen OT_PERMISSION_DENIED (Benutzer hat den Zugriff auf Kamera/Mikrofon verweigert) – Hier ist ein Eingriff des Benutzers erforderlich, kein erneuter Versuch.
• Do nicht Erneut versuchen OT_NOT_CONNECTED — Vergewissern Sie sich vor der Veröffentlichung, dass die Sitzung verbunden ist.
• Do nicht Unbegrenzt oft wiederholen – auf maximal 3 Versuche begrenzen und den Fehler ordnungsgemäß behandeln.

Umgang mit dem mediaStopped Veranstaltung

Der Medien-Track kann während der Veröffentlichung angehalten werden. Warten Sie auf dieses Ereignis und behandeln Sie es als Auslöser für einen erneuten Versuch:

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);
});

Zusammenfassung der empfohlenen Parameter

Behebung von Problemen bei der Audioaufnahme: audioAcquisitionProblem und audioAcquisitionProblemResolved

Abgesehen von Wiederholungsversuchen auf Veröffentlichungsebene gibt es eine separate Kategorie von Audio-Problemen, die einen aktiven Publisher beeinträchtigen können: Das Audiogerät des Clients liefert möglicherweise auch nach einer erfolgreichen Veröffentlichung keine Audiodaten. Die Video API JS SDK stellt speziell für dieses Szenario zwei Ereignisse bereit.

Häufige Ursachen

Die audioAcquisitionProblem Das Ereignis wird ausgelöst, wenn das SDK – anhand der Publisher-Statistiken – feststellt, dass die Audiospur keine Bytes mehr an die Peer-Verbindung überträgt, obwohl getUserMedia Der Vorgang war erfolgreich, und der Herausgeber scheint aktiv zu sein. Die häufigsten Ursachen sind:

• Bluetooth-Audiogerät wurde während der Sitzung verbunden oder getrennt: Wenn ein Benutzer während einer aktiven Sitzung Kopfhörer anschließt oder abzieht oder Bluetooth-Kopfhörer (z. B. AirPods) verbindet, wechselt das Betriebssystem möglicherweise das Standard-Audiogerät. Die Audio-Pipeline des Browsers kann das Mikrofon des neuen Geräts möglicherweise nicht erneut erkennen, was dazu führt, dass keine Audio-Bytes gesendet werden.
• Wechsel des Audiogeräts zu Beginn der Sitzung: Ein Wechsel des Audioeingangs sehr früh in der Sitzung – innerhalb der ersten 1–2 Sekunden nach der Veröffentlichung – führt besonders häufig zu diesem Problem.
• Die Audiospur wurde vom Browser oder vom Betriebssystem beendet (trackEndedEvent): Der Browser kann die zugrunde liegende Audiospur unabhängig von jeglicher Benutzeraktion beenden. Das SDK erkennt dies über ein track.ended Ereignis und löst aus audioAcquisitionProblem mit method: trackEndedEvent.
• Statistikbasierte Erkennung (keine Audio-Bytes werden übertragen): Das SDK überwacht die Publisher-Statistiken kontinuierlich, nachdem die Peer-Verbindung hergestellt wurde. Wenn innerhalb von 30 Sekunden nach Erreichen des Verbindungsstatus „verbunden“ keine Audio-Bytes erkannt werden, audioAcquisitionProblem wird ausgelöst mit method: getStats.

Die Veranstaltungen

Diese Ereignisse werden von der Publisher-Instanz ausgelöst:

• audioAcquisitionProblem — Wird ausgelöst, wenn das SDK feststellt, dass der Publisher keine Audiodaten mehr sendet (basierend auf den Publisher-Statistiken). Dies bedeutet nicht zwangsläufig, dass der Stream fehlschlägt, ist jedoch ein Hinweis darauf, dass die Audioaufnahme unterbrochen wurde.
• audioAcquisitionProblemResolved — wird ausgelöst, wenn die Audioübertragung nach einer vorherigen Unterbrechung wiederhergestellt ist audioAcquisitionProblem. Wenn dieses Ereignis ausgelöst wird, sind keine Korrekturmaßnahmen erforderlich.

Empfohlenes Wiederherstellungsmuster

Bei Empfang einen kurzen Timer starten audioAcquisitionProblem. Wenn audioAcquisitionProblemResolved Wenn der Timer abläuft, bevor Störungen auftreten, hat sich der Ton von selbst wieder normalisiert und es sind keine Maßnahmen erforderlich. Läuft der Timer ab, ohne dass sich das Problem behoben hat, wechseln Sie als Abhilfemaßnahme die Audioquelle.

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);
  });
});

Wichtige Überlegungen

• Kein garantierter Hinweis auf einen Ausfall: audioAcquisitionProblem führt nicht immer zu einem Abonnementfehler. Betrachten Sie dies als frühes Warnsignal, um die Situation zu überwachen und gegebenenfalls Maßnahmen zu ergreifen, nicht als endgültigen Fehler.
• Audio-Statistiken des Herausgebers überwachen: Nach Erhalt audioAcquisitionProblem, können Sie auch die Audio-Statistiken des Herausgebers einsehen (z. B. über publisher.getStats()), um zu überprüfen, ob die Audioübertragung tatsächlich beendet ist, bevor Sie Maßnahmen ergreifen.
• Maßnahmen zur Wiederherstellung: Aufruf von publisher.setAudioSource(newDeviceId) ist der primäre Wiederherstellungsmechanismus. Dadurch wird das Audio-Eingabegerät umgeschaltet, ohne dass ein vollständiger Zyklus aus „Veröffentlichung aufheben“ und „erneut veröffentlichen“ erforderlich ist.
• Zusammenhang mit Zeitüberschreitungen bei Abonnements: Wenn der Ton nicht wiederhergestellt wird und der Sender weiterhin keine Audiopakete sendet, kann es vorkommen, dass Abonnenten schließlich auf OT_TIMEOUT (1501). Proaktiver Umgang mit audioAcquisitionProblem kann dazu beitragen, diesen Ausfall im weiteren Verlauf zu vermeiden.