Bewährte Praktiken für Tests vor dem Anruf

Dieser Leitfaden beschreibt die Erfahrung vor dem Anruf für Video API Applications, die Verbindungsfehler reduzieren und die Live-Sitzungserfahrung schützen möchten. Er behandelt Warteräume, Berechtigungen und die Einrichtung von Geräten, Netzwerktests, die Interpretation von Ergebnissen und die Verbindungsentscheidung.

Ein Test vor dem Gespräch schätzt die Gesprächsqualität zu einem bestimmten Zeitpunkt ein. Er kann Probleme bei der Einrichtung erkennen, bevor die Sitzung beginnt, aber er kann nicht vorhersagen, was im weiteren Verlauf des Anrufs passieren wird. Überwachen Sie auch nach dem Einschalten des Benutzers mit Beobachtbarkeit der KundenQualitätsereignisse und Laufzeitanpassungsfunktionen.

Empfohlener Pre-Call Flow

  1. Verwenden Sie einen Warteraum, bevor der Benutzer dem Anruf beitritt.
  2. Überprüfen Sie die Berechtigungen für Kamera und Mikrofon und zeigen Sie eine lokale Vorschau an.
  3. Lassen Sie den Benutzer Geräte auswählen und zeigen Sie an, welche Kamera und welches Mikrofon gerade ausgewählt sind.
  4. Führen Sie den Voraufruftest mit separate Prüfbescheinigungen und eine separate Testsitzung. Dadurch bleiben die Anrufsitzung und ihre Inspector-Daten von den Testverbindungen und -strömen getrennt.
  5. ausführen. NetworkTest.testConnectivity() zuerst, dann NetworkTest.testQuality().
  6. Verwenden Sie die dokumentierten Ausgaben, um einen Wartezimmerstatus zu setzen. Ein einfaches Modell ist Pass, Warn, oder Fail.
  7. Nehmen Sie an der Sitzung teil, nachdem die Berechtigungen, die Geräteeinrichtung und die Prüfungen vor dem Anruf abgeschlossen sind. Für WarnEine Möglichkeit besteht darin, den Benutzer mit einer deutlichen Warnung weitermachen zu lassen.

Wenn Sie die Netzwerktest-Bibliothek verwenden, erstellen Sie eine separate geroutet Testsitzung. Verwenden Sie die ID der Kommunikationssitzung nicht erneut für die Testsitzung. Wenn die Testimplementierung explizite audioSource und videoSource Werte, verwenden Sie die im Warteraum ausgewählte Kamera und das Mikrofon.

Warteräume

Ein Warteraum gibt den Benutzern Zeit, die Kamera- und Mikrofonberechtigungen zu überprüfen und Geräte auszuwählen, bevor sie den Anruf tätigen. Verwenden Sie ihn, um empfohlene Veröffentlichungseinstellungen anzuwenden und vor Beginn der Sitzung einen Test durchzuführen. Auf diese Weise wird die Einrichtung von der Live-Sitzung getrennt, und es kommt zu weniger frühen Unterbrechungen, wenn Teilnehmer hinzukommen. Die Website Web-Referenz-App umfasst einen Warteraum, in dem die Geräte vor dem Beitritt begutachtet und eingerichtet werden können.

Warteraum UI

Das Wartezimmer kann Folgendes beinhalten:

  • Lokale Kamera-Vorschau,
  • Anzeige der Mikrofonaktivität,
  • Wahlschalter für Kamera und Mikrofon,
  • Löschung des Genehmigungsstatus und der Verweigerungsmitteilung,
  • Status- oder Fortschrittsanzeige des Tests vor dem Anruf,
  • Ein sichtbarer Zustand der Verbindungsbereitschaft,
  • Eine Wiederholungsaktion für den Voranruftest.

Führen Sie den Test erneut durch, wenn eines der folgenden Ereignisse eintritt:

  • Der Benutzer wechselt die Kamera oder das Mikrofon,
  • Das Netzwerk des Benutzers ändert sich,
  • Die Kamera- oder Mikrofonerlaubnis wird wieder erteilt, nachdem sie verweigert wurde,
  • Der Benutzer bittet ausdrücklich um einen erneuten Versuch,
  • Zwischen dem Abschluss der Prüfung und dem Beitritt vergeht viel Zeit.

Gastgeber oder Moderator Muster

Wenn Ihr Produkt die Rolle eines Gastgebers, Moderators oder Präsentators hat, können die Teilnehmer im Warteraum bleiben, bis der Gastgeber bereit ist, die Live-Sitzung zu starten. In einigen Applikationen mit kleinen Gruppen oder Moderatoren können die Teilnehmer stattdessen der Sitzung beitreten, bevor der Gastgeber sie veröffentlicht, und verbunden bleiben, ohne sie zu veröffentlichen, bis der Gastgeber bereit ist. Betrachten Sie diesen Ansatz als ein optionales Muster auf Anwendungsebene mit Kompromissen bei der Skalierung, nicht als allgemeine Empfehlung oder Anforderung an die Video API-Plattform. Bei einem größeren Publikum kann das vorherige Verbinden vieler Teilnehmer zu einem Ansturm von Abonnements führen, wenn der Host mit der Veröffentlichung beginnt. Die Warteraum-Muster-App Artikel zeigt ein Implementierungsbeispiel.

Netzwerk-Tests durchführen

Verwenden Sie die Vonage Video Network Testbibliothek, um zu prüfen, ob ein Client die Veröffentlichung von Audio und Video unterstützt, bevor Benutzer einer Sitzung beitreten.

Wenn Ihre Anwendung konfigurierbare TURN- oder IP-Proxy-Einstellungen verwendet, übergeben Sie die entsprechenden iceConfig oder proxyServerUrl Werte in den Netzwerktest mit ein.

Konnektivitätskontrollen

ausführen. NetworkTest.testConnectivity() vor der Qualitätsprüfung.

Diese Prüfung verifiziert, ob der Client die für eine Video API-Sitzung erforderlichen Dienste erreichen kann:

  • API Erreichbarkeit,
  • Nachrichtenübermittlung / Signalisierung WebSocket Erreichbarkeit,
  • Medien-Router Erreichbarkeit,
  • Logging-Server Erreichbarkeit.

Interpretieren Sie diese Ergebnisse je nach dem Sitzungsmodus, den Ihre Anwendung verwendet:

  • Wenn die api oder messaging Prüfung fehlschlägt, kann der Client die erforderlichen Sitzungsverbindungen nicht herstellen.
  • Wenn die media Prüfung fehlschlägt, wird eine geroutete Sitzung nicht erfolgreich sein. Eine weitergeleitete Sitzung kann dennoch erfolgreich sein, obwohl sie auch fehlschlagen kann, wenn TURN erforderlich ist.
  • Wenn die logging Prüfung fehlschlägt, kann der Client zwar weiterhin eine Verbindung herstellen, Vonage sammelt jedoch nicht die üblichen Protokollierungsdaten, die von Tools wie Inspector verwendet werden.

Qualitätskontrollen

Wenn die Konnektivitätsergebnisse für Ihren Anwendungsfall akzeptabel sind, führen Sie NetworkTest.testQuality()zu testen:

  • Audio-Unterstützung,
  • Video-Unterstützung,
  • Audio- und Video-Bitrate,
  • Audio- und Video-Paketverlustrate,
  • Empfohlene Veröffentlichungsauflösung,
  • Empfohlene Bildrate für die Veröffentlichung,
  • qualityLimitationReason mit Werten bandwidth, cpu, oder null.

Anmerkung: Der Test läuft standardmäßig im Audio-Video-Modus und kann bei Bedarf im reinen Audio-Modus fortgesetzt werden.

Timeout-Tests

Die timeout Option für testQuality() akzeptiert Werte größer als 5000 ms und weniger als 30000 ms. Wenn Sie diese Einstellung nicht vornehmen, läuft der Test etwa eine Stunde lang:

  • 30 Sekunden für einen Audio-Video-Test,
  • 10 Sekunden für einen reinen Audiotest.

Geringere Zeitüberschreitungen verringern die Genauigkeit der Ergebnisse.

Browser-Unterstützung

testQuality() wird in Firefox nicht unterstützt. Verwenden Sie in diesem Fall den Warteraum für Berechtigungen und Geräteeinstellungen und verlassen Sie sich auf testConnectivity() wenn Sie weiterhin eine reine Verbindungsprüfung vor dem Anruf wünschen.

Eingeschränkte Netzwerke

Bei eingeschränkten Netzen sind die dokumentierten Netzanforderungen zu beachten:

  • Bevorzugen Sie eine Umgebung, in der UDP 3478 und TCP 443 sind verfügbar.
  • Um die beste Einrichtungszeit und Medienqualität zu erzielen, lassen Sie auch ausgehende UDP 1025-65535 für Media ICE und SRTP.
  • Wenn nur TCP 443 verfügbar ist, kann die Verbindung zwar immer noch hergestellt werden, aber der Aufbau ist langsamer und die Medienqualität schlechter.
  • Wenn ein Proxy vorhanden ist, sollte er transparent oder für HTTPS-Verbindungen konfiguriert sein.

Verifizieren Sie in Firmen- oder eingeschränkten Netzwerken dieselben erforderlichen Ports und Protokolle und führen Sie den Konnektivitätstest erneut durch, bevor der Benutzer beitritt.

Für restriktivere Umgebungen, siehe:

Empfohlener Vorgesprächsstatus

Status Verwenden Sie es, wenn Was als nächstes zu tun ist
Pass Die Verbindung ist für den von Ihrer Anwendung verwendeten Sitzungsmodus erfolgreich, die erforderlichen Medien werden unterstützt, der Paketverlust liegt unter 3 %, die Bitrate übersteigt die Mindestschwellenwerte (≥150 kbit/s Video, ≥25 kbit/s Audio) und die empfohlenen Veröffentlichungseinstellungen sind für den Anruf akzeptabel. Lassen Sie den Benutzer beitreten. Wenden Sie bei der Initialisierung des Publishers die empfohlene Veröffentlichungsauflösung und Bildrate an.
Warn logging die einzige fehlgeschlagene Konnektivitätsprüfung ist, der Paketverlust 3-5 % beträgt, die Bitrate niedrig, aber wiederherstellbar ist, die empfohlene Veröffentlichungsauflösung oder Bildrate reduziert ist oder qualityLimitationReason ist bandwidth oder cpu. Zeigen Sie den Grund im Warteraum an, lassen Sie den Benutzer es erneut versuchen und wenden Sie die empfohlenen Veröffentlichungseinstellungen an. Erlauben Sie dem Benutzer bei Bedarf, mit einer deutlichen Warnung fortzufahren.
Fail api oder messaging scheitert, media für den von Ihrer Anwendung benötigten Sitzungsmodus ausfällt, erforderliche Audio- oder Videodaten nicht unterstützt werden, Berechtigungen oder Geräteerfassung unvollständig sind, Paketverluste 5 % überschreiten oder die Bitrate unter kritische Schwellenwerte fällt (<150 kbit/s Video, <25 kbit/s Audio). Lassen Sie den Benutzer noch nicht teilnehmen. Zeigen Sie das Problem im Warteraum an und fordern Sie den Benutzer auf, es nach der Behebung des Problems erneut zu versuchen. Wenn Audio, aber nicht Video unterstützt wird, können Sie eine reine Audioverbindung anbieten.

Wenn der Status auf Warn oder FailAnhand des Signals, das sie ausgelöst hat, entscheiden sie, was als nächstes zu tun ist:

  • Wenn das Problem bandwidthBitten Sie den Benutzer, es in einem stärkeren oder weniger eingeschränkten Netz erneut zu versuchen, oder fahren Sie mit reduzierten Veröffentlichungseinstellungen fort.
  • Wenn das Problem cpubitten Sie den Benutzer, anspruchsvolle Applications zu schließen, teure Effekte zu deaktivieren und es erneut zu versuchen.
  • Wenn das Problem logging kann der Benutzer weiterhin eine Verbindung herstellen, aber die normalen Inspector-Daten werden reduziert.
  • Wenn es sich bei dem Browser um Firefox handelt, verwenden Sie den Warteraum für Berechtigungen und die Einrichtung des Geräts, und verwenden Sie testConnectivity() wenn Sie einen reinen Verbindungscheck vor dem Anruf benötigen.

Interpretation der Netzwerktestergebnisse

Prüfen Sie beim Setzen eines Vorgesprächsstatus:

  • Unterstützt vs. nicht-unterstützt,
  • Ergebnis der Konnektivität,
  • Paketverlustrate (unter 3 % ist akzeptabel; 3 bis 5 % ist Vorsicht geboten; über 5 % bedeutet Ausfall),
  • Bitratenpegel (Video ≥150 kbps und Audio ≥25 kbps sind akzeptable Mindestwerte),
  • Empfohlene Veröffentlichungsauflösung und Bildrate,
  • qualityLimitationReason.

Wenn Sie Diagnosen auf niedrigerer Ebene benötigen, wie z. B. Round-Trip-Zeit, Freeze-Zahlen oder RTC-Rohdaten, verwenden Sie Client Observability oder den WebRTC-Rohdatenbericht.

In-Call-Qualitätssignale

Nachdem der Benutzer beigetreten ist:

  • Verwenden Sie qualityScoreChanged Verfolgung der Teilnehmerqualität auf dem In-Call-Integer 1-5 Skala,
  • Verwenden Sie cpuPerformanceChanged auf den Gerätedruck in Webclients zu reagieren,
  • Verwenden Sie die Qualitätsereignisse von Client Observability, wenn Sie mehr Details benötigen, als die einfachen Prüfungen vor dem Anruf liefern.

Ausführliche Web-Anleitungen finden Sie unter Client-Beobachtbarkeit: Web.

Nach dem Beitritt fortfahren

Nachdem der Benutzer beigetreten ist, fahren Sie mit fort:

Subscriber Audio Fallback erfordert eine geroutete Sitzung. Publisher-Audio-Fallback ist sowohl in gerouteten als auch in weitergeleiteten Sitzungen verfügbar.