Beobachtbarkeit der Kunden

Die OpenTok-SDKs bieten Funktionen für den Zugriff auf Echtzeit-Netzwerk- und Medienstatistiken in einer Videositzung, einschließlich senderseitiger Statistiken.

Die Client-Beobachtung liefert detaillierte Metriken zur Stream-Qualität - z. B. Paketverluste, empfangene Daten und geschätzte Bandbreite - und kann für jeden veröffentlichten oder abonnierten Stream verwendet werden.

Der Zugriff auf Statistiken kann über zwei Hauptmechanismen erfolgen:

  • High-Level-Statistik-API - in den meisten Fällen der bevorzugte Mechanismus. Diese API liefert Audio-, Video- und Netzwerkleistungsmetriken und berücksichtigt Peer-Verbindungsübergänge und andere interne Anpassungen. Das SDK fasst diese Details zusammen, so dass die Daten sauber auf eine Publisher- oder Subscriber-Abstraktion abgebildet werden können. Wann immer möglich, sollten Sie diese API verwenden, da sie eine genauere und stabilere Darstellung der tatsächlichen Sitzungsleistung bietet.
  • Low-Level-WebRTC-Statistikbericht, der den rohen WebRTC RTCStatsReport für die zugrunde liegende Peer-Verbindung offenlegt. Diese Daten werden nicht für Peer-Verbindungsübergänge oder interne Optimierungen angepasst und geben nur die direkten WebRTC-Statistiken wieder. Er ist nützlich für fortgeschrittenes Debugging oder wenn WebRTC-Rohdaten ausdrücklich benötigt werden.

Dieser Leitfaden umfasst die folgenden Abschnitte:

API für Audio-, Video- und Medien-Link-Statistiken

Die Audio- und Videostatistik-API bietet sowohl für Herausgeber als auch für Abonnenten einen regelmäßigen, detaillierten Einblick in die Medienleistung. Mit diesen Statistiken können Applikationen die Audio- und Videoqualität in Echtzeit überwachen, das Netzwerkverhalten verstehen, geräteseitige Probleme erkennen und proaktiv auf Bandbreiten- oder Leistungsänderungen reagieren. Die API ist für alle Video-Client-SDKs verfügbar und liefert separate Callbacks oder Ereignisse für Metriken auf Publisher- und Subscriber-Seite.

Zu den wichtigsten Arten von Daten und Ereignissen, die bereitgestellt werden, gehören:

  • Audio- und Videostatistiken - wie z. B. Bildraten, Auflösung, Bitrate und Anzahl der Pakete, die in regelmäßigen Abständen durch Rückrufe oder Ereignisse übermittelt werden.

  • Statistik der Medienlinks - bieten einheitliche Metriken auf Transportebene, die die periodischen Audio- und Videostatistiken ergänzen, einschließlich der Bewertung des Netzwerkzustands und der Bandbreitenschätzung. Für Abonnenten bieten diese Metriken einen zusätzlichen Einblick in die Transportleistung des Remote-Publishers und in die Zuordnung von Netzwerkverschlechterungen, so dass Anwendungen Verbindungsprobleme präzise diagnostizieren und den Nutzern aussagekräftiges, umsetzbares Feedback liefern können.

  • Ereignisse zur Änderung der Videoqualität - wird ausgelöst, sobald sich die Qualität eines Videostreams ändert, und liefert aktualisierte Metriken zusammen mit dem Grund für eine Verschlechterung oder Verbesserung.

  • Ereignisse zur Änderung der Netzbedingungen – wird ausgelöst, wenn bei einem Publisher oder Subscriber eine wesentliche Änderung des Netzwerkzustands festgestellt wird. Diese Ereignisse melden Änderungen des allgemeinen Netzwerkzustands und enthalten eine vollständige Momentaufnahme der Audio- und Videostatistiken sowie Kennzahlen auf Transportebene, wie beispielsweise den Netzwerkzustandswert und den Grund für den Zustand. Bei Subscribern wird zudem die Ursache für die Netzwerkbeeinträchtigung angegeben. Siehe Zustand des Netzes für Einzelheiten.

Verlagsstatistiken

Rückrufe des Herausgebers bieten Einblick in die Qualität der Medien, die gesendet an jeden Teilnehmer (oder an den Vonage Video Media Router bei gerouteten Sitzungen). Diese Metriken helfen dabei, die Upstream-Netzwerkbedingungen zu verstehen, die Codierungsleistung zu beobachten und Probleme wie Paketverluste oder Bitratenabfälle zu diagnostizieren.

Anmerkung: Bei gerouteten Sitzungen entsprechen die Publisher-Metriken möglicherweise nicht den tatsächlichen Medienwerten, da der Vonage Video Media Router die Bandbreite zur Optimierung der Ressourcen drosseln kann. Verlassen Sie sich in solchen Fällen nicht auf die verlagsseitigen Metriken, bis mindestens ein Teilnehmer angeschlossen ist. Sie können Qualitätseinschränkungsgründe in Bezug auf die Bandbreite für den Herausgeber ignorieren, bis ein Teilnehmer vorhanden ist. Bei weitergeleiteten Sitzungen werden keine Statistiken gemeldet, bis mindestens ein Teilnehmer angeschlossen ist.

Beachten Sie, dass der Herausgeber in einer Relayed-Sitzung einen separaten Medienstrom an jeden Abonnenten sendet. Aus diesem Grund können die Statistikereignisse mehrere Statistikobjekte enthalten - eines pro Abonnent. Für jedes Statistikobjekt in einer weitergeleiteten Sitzung sind zwei Identifizierungsfelder enthalten:

  • Verbindungs-ID: Die eindeutige ID der Verbindung des Abonnenten. Diese stimmt mit der ID-Eigenschaft des Verbindungsobjekts überein, das im Ereignis "connection created" für diesen Client geliefert wird.
  • Abonnenten-ID: Die eindeutige ID des Subscriber-Objekts, das den Stream dieses Publishers empfängt. Dies entspricht der ID-Eigenschaft des Abonnenten in der Anwendung des abonnierenden Clients.

Anhand dieser Felder können Sie feststellen, zu welchem Teilnehmer jedes Statistikobjekt gehört.

In einer gerouteten Sitzung (mit dem Vonage Video Media Router) gibt es nur einen ausgehenden Medienstrom, so dass das Array stats ein einziges Objekt enthält und sowohl die Verbindungs- als auch die Teilnehmer-ID undefiniert sind.

Audio-Metriken

  • Pakete verloren: Gesamtzahl der Audiopakete, die den Teilnehmer nicht erreichen konnten.
  • Gesendete Pakete: Gesamtzahl der an den Teilnehmer oder den Medien-Router übertragenen Audiopakete.
  • Gesendete Bytes: Kumulative Größe aller gesendeten Audiodaten, einschließlich Audio-Payload, Header und Padding.
  • Audio-Pegel: Aktuelle Lautstärke des Audiosignals, normalisiert zwischen 0 und 1.
  • Zeitstempel: Gibt an, wann die einzelnen Messungen durchgeführt wurden.

Metriken zum Transport und zu den Netzwerkbedingungen des Herausgebers sind über die Statistiken der Herausgeber-Medienverbindung verfügbar. Siehe Statistik der Medienlinks für Einzelheiten.

Video-Metriken

  • Pakete verloren: Numbers von Videopaketen, die ihr Ziel nicht erreicht haben.
  • Gesendete Pakete: Gesamtzahl der an den Teilnehmer oder den Medien-Router übertragenen Videopakete.
  • Gesendete Bytes: Gesamtzahl der an den Teilnehmer oder den Medien-Router übertragenen Bytes, einschließlich Video-Payload, Header und Padding.
  • Zeitstempel: Zeigt den Start- und den aktuellen Messpunkt an.
  • Video-Ebenen: Informationen pro Schicht für Simulcast oder skalierbare Videokodierung (SVC). In einer Simulcast-Konfiguration entspricht jedes Objekt einer unabhängigen Videokodierung (z. B. parallel gesendete Ströme mit niedriger, mittlerer und hoher Auflösung). Bei SVC (Scalable Video Coding) sendet der Herausgeber in der Regel ein einziges Video-Encoding, wobei die Skalierbarkeit (zeitlich, räumlich oder beides) intern kodiert und über das Feld Skalierbarkeitsmodus beschrieben wird. Es umfasst:
    • Kodierte Bildbreite: Breite der kodierten Videobilder für diese Ebene. Diese kann von der Aufnahmeauflösung der Kamera abweichen, wenn eine Skalierung oder Anpassung vorgenommen wurde.
    • Höhe der kodierten Frames: Höhe der kodierten Videoframes für diese Ebene. Wie bei der Breite kann der Encoder Frames je nach Bandbreite, CPU oder Simulcast/SVC-Ebenenkonfiguration herunterskalieren.
    • Encoder-Ausgangsbildrate: Tatsächliche Bildrate, mit der die Videobilder erfolgreich kodiert werden. Diese kann von der Aufnahmebildrate der Kamera (Bilder können vor der Kodierung verworfen werden) und von der tatsächlich übertragenen Bildrate (kodierte Bilder können vor dem Senden verworfen werden) abweichen.
    • Bitrate (nur Video-Nutzdaten): Geschätzte Bitrate der kodierten Video-Nutzdaten. Dies schließt den RTP-Overhead aus und kann je nach den Entscheidungen des Encoders zur Ratenkontrolle variieren.
    • Gesamtbitrate (einschließlich Overhead): Bitrate einschließlich RTP-Header, Padding und sonstigem Transport-Overhead. Dies spiegelt die tatsächliche Netznutzung besser wider als die reine Nutzdatenbitrate.
    • Skalierbarkeitsmodus: Gibt die räumliche/zeitliche Skalierbarkeitsstruktur an (z. B. "L3T3").
    • Codec: Der für die Kodierung dieser Ebene verwendete Codec (z. B. VP8, VP9, H.264, AV1).
    • Grund für die Qualitätseinschränkung: Gibt an, warum der Encoder die Qualität eingeschränkt hat (Bandbreite, CPU, andere). Hilft bei der Diagnose, ob die Anpassung durch Netzwerkbedingungen oder geräteseitige Beschränkungen verursacht wird.

Die Statistiken für Medienlinks des Herausgebers umfassen:

  • Verkehrsstatistiken: Lokale Verkehrs- und Netzstatistiken für den Verlag, einschließlich:
    • Geschätzte verfügbare Bandbreite der Uplink-Verbindung.
    • Bewertung des Netzzustands. Siehe Zustand des Netzes für Einzelheiten.
    • Grund der Netzbedingung. Siehe Zustand des Netzes für Einzelheiten.

Diese Metriken werden durch bereitgestellt:

  • Medien Link Statistiken Veranstaltung: Ein spezielles Ereignis, das in regelmäßigen Abständen ausgelöst wird, um Statistiken über Medienverbindungen zu erstellen.
  • Ereignis "Netzwerkbedingung geändert": Wird ausgelöst, wenn eine signifikante Änderung der Netzbedingungen festgestellt wird, und liefert die aktuellen Statistiken über die Medienverbindung zusammen mit dem Grund für die Änderung.

Die Medienverbindungsstatistiken des Herausgebers beschreiben dessen eigenen Uplink. Die Medienverbindungsstatistiken der Abonnenten geben zusätzlich Auskunft über den Transport des entfernten Herausgebers und die Ursache für eine Netzwerkbeeinträchtigung. Unter [Netzwerkzustand nach Herausgeber und Abonnent](#network_condition_by_publisher and_subscriber) erfahren Sie, wie diese beiden Perspektiven zusammenhängen und wie Sie die Erfahrung eines bestimmten Abonnenten bewerten können.

Abonnentenstatistiken

Rückrufe von Abonnenten liefern Informationen über die Medien, die erhalten und gerendert, so dass Anwendungen Probleme bei der Wiedergabe erkennen, die Downstream-Leistung bewerten und adaptive Entscheidungen treffen können.

Audio-Metriken

  • Empfangene Pakete: Wie viele Audiopakete erfolgreich empfangen wurden.
  • Pakete verloren: Wie viele Audiopakete wurden nicht erfolgreich empfangen.
  • Empfangene Bytes: Gesamtzahl der vom Herausgeber oder dem Video API Media Router empfangenen Audiodaten.
  • Audio-Pegel: Lautstärke des Tons der Fernbedienung.
  • Zeitstempel: Wann wurden die Metriken erhoben?
  • Statistik auf der Absenderseite: Vom Absender gemeldete Bandbreitenschätzungen.

Teilnehmer-Transport- und Netzzustandsmetriken, einschließlich der Transportstatistiken des Fernverlegers und der Informationen über die Quelle der Netzverschlechterung, sind über die Teilnehmer-Medienverbindungsstatistiken verfügbar. Siehe Statistik der Medienlinks für Einzelheiten.

Video-Metriken

  • Empfangene Pakete: Wie viele Videopakete erfolgreich empfangen wurden.
  • Pakete verloren: Wie viele Videopakete wurden nicht erfolgreich empfangen.
  • Empfangene Bytes: Gesamte Videodaten, die vom Herausgeber oder dem Video API Media Router empfangen wurden.
  • Dekodierte Auflösung: Breite und Höhe der Bilder nach der Dekodierung.
  • Dekodierte Bildrate: Tatsächliche vom Decoder erzeugte Bildrate. Diese kann von der Anzahl der empfangenen Frames (einige können vor der Dekodierung verworfen werden) und von der Anzahl der gerenderten Frames (einige dekodierte Frames werden je nach Rendering-Bedingungen möglicherweise nicht angezeigt) abweichen.
  • Bitrate: Aktuell empfangener Mediendurchsatz, wobei nur die Video-Nutzlast berücksichtigt wird.
  • Gesamt-Bitrate: Aktuell empfangener Mediendurchsatz, einschließlich Header und Padding.
  • Numbers von Videoeinbrüchen: Numbers of video freezes, wie in der Statistik-API von WebRTC definiert freezeCount.
  • Gesamtdauer der eingefrorenen Videos: Gesamtdauer der eingefrorenen Videos.
  • Numbers der Videopausen: Numbers der Unterbrechungen, die länger als 5 Sekunden dauern, einschließlich absichtlicher Pausen (z. B. wenn der Herausgeber die Videospur deaktiviert) und Fällen, in denen das Video aufgrund eines Audio-Fallbacks des Herausgebers oder des Teilnehmers abgeschaltet wird.
  • Gesamtdauer der Videopausen: Gesamtdauer der Videopausen.
  • Codec: Aktueller Codec, der für den Videostrom verwendet wird.
  • Statistik auf der Absenderseite: Vom Absender gemeldete Bandbreitenschätzungen.

Die Abonnenten-Medien-Link-Statistiken umfassen:

  • Statistiken zum Nahverkehr: Transport- und Netzstatistiken für die Downlink-Verbindung des Teilnehmers, einschließlich:

    • Geschätzte verfügbare Bandbreite der Downlink-Verbindung.
    • Bewertung des Netzzustands. Siehe Zustand des Netzes für Einzelheiten.
    • Grund der Netzbedingung. Siehe Zustand des Netzes für Einzelheiten.

  • Transportstatistiken des Fernverlags: Transport- und Netzwerkstatistiken für die Uplink-Verbindung des entfernten Verlegers, mit den gleichen Feldern wie die lokalen Transportstatistiken. Diese Statistiken können eingeschränkt sein, wenn die senderseitigen Statistiken nicht aktiviert sind.

  • Quelle der Netzverschlechterung: Gibt an, welche Seite der Verbindung in erster Linie für eine beobachtete Verschlechterung verantwortlich ist:

    • Keine: Keine Beeinträchtigung des Netzes festgestellt.
    • Lokal: Die Hauptursache ist das lokale Teilnehmernetz.
    • Ferngesteuert: Die Hauptursache ist das Netz des entfernten Verlags.
    • Beides oder unklar: Die Ursache der Verschlechterung lässt sich nicht eindeutig einer Seite zuordnen.

Abonnenten-Medien-Link-Statistiken werden durch geliefert:

  • Medien Link Statistiken Veranstaltung: Ein spezielles Ereignis, das in regelmäßigen Abständen ausgelöst wird, um Statistiken über Medienverbindungen zu erstellen.
  • Ereignis "Netzwerkbedingung geändert": Wird ausgelöst, wenn eine signifikante Änderung der Netzbedingungen festgestellt wird, und liefert die aktuellen Statistiken über die Medienverbindung zusammen mit dem Grund für die Änderung.

Videoqualität veränderte Ereignisse

Das SDK bietet Ereignisse zur Änderung der Videoqualität, die den Applikationen detaillierte Einblicke in den Videostream eines Anbieters oder eines Abonnenten ermöglichen. Diese Ereignisse ergänzen die periodischen Netzwerkstatistiken, die für die Beobachtung durch den Kunden bereitgestellt werden, und ermöglichen es den Applikationen, sowohl auf kontinuierliche Metriken als auch auf signifikante Qualitätsänderungen zu reagieren.

Sie können einen Handler an einen Verleger oder einen Abonnenten anhängen, um auf Qualitätsänderungsereignisse zuzugreifen. Die Ereignisse liefern aktualisierte Metriken zusammen mit dem Grund für eine Verschlechterung oder Verbesserung. Dieser Mechanismus ermöglicht es Ihrer Anwendung, die Videoleistung zu überwachen und die Benutzeroberfläche oder das Verhalten entsprechend anzupassen, unabhängig davon, wie die Metriken intern bereitgestellt werden.

Die Gründe für Qualitätsereignisse werden nach einer festgelegten Prioritätsreihenfolge ausgelöst. So hat beispielsweise eine durch die Bandbreite verursachte Qualitätseinschränkung Vorrang vor einer Auflösungsänderung. Wenn Sie alle Änderungen in den Metriken verfolgen möchten, sehen Sie sich die detaillierten Statistiken an, die in jedem Ereignis enthalten sind. Ausführliche Informationen finden Sie in der SDK-Referenzdokumentation.

Für einen Verleger werden die Gründe in der folgenden Rangfolge berücksichtigt:

  1. Verschlechterung aufgrund von Bandbreitenbeschränkung
  2. Verschlechterung aufgrund von CPU-Beschränkungen
  3. Andere Gründe für Qualitätsminderungen
  4. Codec-Änderungen
  5. Änderungen der Auflösung oder der Videoebene

Für einen Abonnenten werden die Gründe in der folgenden Rangfolge berücksichtigt:

  1. Video-Unterbrechung
  2. Codec-Änderungen
  3. Änderungen der Auflösung

Überwachung der Gesprächsqualität

Neben den zentralen Statistik-APIs bietet das OpenTok.js SDK zusätzliche Funktionen zur Überwachung und Reaktion auf Änderungen der Anrufqualität in Echtzeit. Diese Funktionen helfen Applications, die Leistung zu optimieren, indem sie sich an Gerätebeschränkungen und Netzwerkbedingungen anpassen.

Hinweis: Die Funktionen zur Überwachung der Anrufqualität, einschließlich der Überwachung der CPU-Leistung und der Verfolgung des Mean Opinion Score (MOS), sind derzeit nur im OpenTok.js SDK für Webanwendungen verfügbar.

Kernkompetenzen

Überwachung der CPU-Leistung - Erkennen Sie Änderungen in der CPU-Auslastung des Geräts und passen Sie Ihre Anwendung entsprechend an. Applikationen können auf CPU-Belastung reagieren, indem sie rechenintensive Funktionen deaktivieren oder die Videoqualität reduzieren, um die Gesprächsstabilität zu erhalten.

Mittlere Meinungsbewertung (MOS) - Bewerten Sie die von den Benutzern wahrgenommene Qualität Ihres Dienstes anhand der branchenüblichen MOS-Skala (1-5). Der MOS-Algorithmus berücksichtigt Paketverluste, Bitrate, Netzwerklatenz und andere Faktoren, die die Medienqualität beeinflussen.

Kombinierte Optimierung - Erstellen Sie robuste Applikationen, die sowohl auf die CPU-Leistung als auch auf die Netzwerkqualität reagieren und die Videoauflösung, Bildraten und andere Parameter dynamisch anpassen, um unter verschiedenen Bedingungen das bestmögliche Benutzererlebnis zu bieten.

Tests vor dem Anruf - Verwenden Sie die Test des Vonage Video API-Netzwerks Bibliothek zur Überprüfung, ob ein Client die Übertragung von Audio- und Videodaten unterstützt, sowie zur Schätzung der MOS-Werte, bevor Nutzer einer Sitzung beitreten.

Ausführliche Implementierungsanleitungen, Codebeispiele und bewährte Verfahren für die Überwachung der Anrufqualität in Web Applications finden Sie in der OpenTok.js SDK-Dokumentation.

Statistik auf der Absenderseite

Während eines Anrufs überträgt der Herausgeber einen Medienstrom an einen oder mehrere Teilnehmer. Die Medien können direkt weitergeleitet oder über die Vonage Video-Media-Router. Während die Abonnenten die Bitrate des empfangenen Streams beobachten können, fehlt ihnen in der Regel der Überblick über ihre gesamte Downlink-Kapazität. Die senderseitige Statistik-API behebt diese Einschränkung, indem sie Metriken bereitstellt, die den Abonnenten helfen, die verfügbare Bandbreite für den Medienempfang zu bewerten und die Streamqualität zu optimieren.

Ein Absender kann ein Publisher oder der Vonage Video-Media-Routerje nachdem, ob die Medien Punkt-zu-Punkt oder über den Medienrouter fließen. Die API wird als senderseitige Statistik bezeichnet, da der Sender die Quelle der gemeldeten Metriken ist, die an den Empfänger, also den Abonnenten, geliefert werden.

Die API meldet zwei wichtige Metriken pro Paket (Audio-Video-Paar): die maximale Bitrate, die der Sender schätzen kann, und die aktuelle Bandbreitenschätzung. Die maximale Bitrate ist eine Obergrenze für das, was aufgrund von Plattformbeschränkungen geschätzt werden kann. Bei der geschätzten aktuellen Bandbreite handelt es sich um die geschätzte Downlink-Bandbreite der WebRTC-Peer-Verbindungskanalkapazität, die unabhängig von der Bitrate des Streams für Medien verfügbar ist.

Beispielsweise kann ein Publisher einen VGA-Stream mit weniger als 1 Mbit/s senden, während der Vonage Video Media Router, der die senderseitigen Statistiken bereitstellt, die aktuelle Bandbreite auf 8 Mbit/s schätzt, was auf zusätzliche Kanalkapazität hinweist. Diese Informationen können von der Anwendung genutzt werden, um das Videolayout anzupassen oder richtlinienbasierte Aktionen wie Vonage Quality on Demand (QoD) auszulösen.

Es ist zu beachten, dass die Interpretation unterschiedlich ist, wenn ein einzelne Peer-Verbindungssitzung erstellt wird. In einer einzelnen Peer-Verbindungssitzung teilen sich mehrere Audio- und Videobündel dieselbe Verbindung, so dass die Gesamtbandbreitenschätzung durch Addition der einzelnen Bündelschätzungen berechnet werden sollte. Mit anderen Worten: Die Gesamtbandbreite wird von allen Teilnehmern der einzelnen Peer-Verbindung gemeinsam genutzt.

Aktivieren von Statistiken auf der Absenderseite

Um senderbezogene Statistiken zu aktivieren, verwenden Sie die entsprechende Methode im Client SDK, um die Senderstatistikspuren auf dem Herausgeber zu aktivieren. Nach der Aktivierung werden die folgenden Metriken in die regulären Audio- und Videostatistik-Ereignisse des Abonnenten aufgenommen:

  • Die maximale Bitrate, die für die Verbindung geschätzt werden kann.
  • Die aktuelle Bandbreiteneinschätzung für die Verbindung.

Anwendungsfälle

  • Optimierung der Teilnehmer-Layouts: Verwenden Sie die geschätzte Bandbreite der Sender-API zusammen mit den RTC-Statistiken des lokalen Endpunkts, um eine hohe Anzahl von Abonnenten mit guter Videoqualität anzuzeigen.

  • Adaptiver Medienmodus: Ein Abonnent kann anhand der Senderstatistiken feststellen, ob die geschätzte Bandbreite des Senders einen bestimmten Schwellenwert (z. B. 500 kbit/s) überschreitet, um zu entscheiden, ob er ein Abonnement im reinen Video- oder im reinen Audiomodus abschließt.

  • Skalierung der Last: Verwenden Sie die Statistiken auf der Senderseite, um zu prüfen, ob ein Teilnehmer eine höhere Last optimal bewältigen kann, z. B. wenn er von einer Bildschirmfreigabe mit niedriger Bitrate zu einem Live-Video mit hoher Bitrate wechselt.

  • Schwellenwert-Warnungen: Verwenden Sie die senderseitigen Statistiken, um Warnungen für Teilnehmer auszulösen, wenn die geschätzte Bandbreite einer Senderverbindung unter einen vordefinierten Schwellenwert fällt.

  • Quality on Demand (QoD)-Auslöser: Verwenden Sie die senderseitigen Statistiken, um eine Auslösung zu veranlassen, wenn die geschätzte Netzkapazität für einen abonnierten Stream unter einen bestimmten Schwellenwert im Mobilfunknetz fällt.

Anmerkungen

  • Je nach SDK sind die Statistiken auf der Senderseite aufgrund der Netzwerklatenz möglicherweise nicht sofort verfügbar, wenn die Statistiken zum ersten Mal angefordert werden oder beim ersten Statistikereignis nach der Anmeldung.
  • Wenn Sie eine einzelne Peer-Verbindungssitzung erstellenwird die Bandbreite der Peer-Verbindung auf alle Teilnehmer aufgeteilt. Die maximale Bitrate stellt die höchste Bitrate dar, die die Peer-Verbindung schätzen kann, während die aktuelle Bitrate die Bitrate der einzelnen Audio-Video-Bündel widerspiegelt. Alle Teilnehmer der einzelnen Peer-Verbindung teilen sich diese maximale Bitrate. Bei der Beurteilung der verfügbaren Bandbreite des Senders ist dies zu berücksichtigen. So kann beispielsweise eine aktuelle Bitrate von 2 Mbit/s auf eine gute Qualität hindeuten, wenn mehrere Teilnehmer dieselbe Peer-Verbindung nutzen.

Bekannte Probleme

In einigen Fällen, wenn die Sitzung weitergeleitet wird - oder in bestimmten gerouteten Setups mit nur zwei Teilnehmern - und der Publisher Firefox verwendet, sind aufgrund von Browsereinschränkungen möglicherweise keine absenderseitigen Statistiken verfügbar.

Zustand des Netzes

Die Netzwerkzustands-API bietet Echtzeiteinblicke in den Zustand der Netzwerkverbindung sowohl für Herausgeber als auch für Abonnenten. Sie zeigt einen Netzwerkzustandswert an, der die Gesamtqualität der Verbindung, den Hauptgrund für diesen Wert und - für Abonnenten - Informationen darüber enthält, welche Seite der Verbindung eine beobachtete Verschlechterung verursacht.

Die Netzzustandsdaten sind in den Statistiken der Medienverbindungen enthalten und werden über zwei Kanäle übermittelt:

  • Regelmäßige Statistiken: Felder zum Netzwerkstatus sind in den Medienverbindungsstatistiken enthalten, die im Rahmen regelmäßiger Ereignisse zur Medienverbindungsstatistik bereitgestellt werden. Siehe Statistik der Medienlinks für Einzelheiten.
  • Ereignisse, bei denen sich der Netzzustand ändert: Ein spezieller Rückruf oder ein Ereignis wird immer dann ausgelöst, wenn eine signifikante Änderung des Netzwerkzustands festgestellt wird. Dieses Ereignis unterscheidet sich von den Ereignissen "Video aktiviert/deaktiviert" oder "Audio-Fallback" und meldet Änderungen des Netzwerkzustands und nicht Änderungen des Medientrack-Status. Applications können dieses Ereignis nutzen, um auf Netzwerkprobleme zu reagieren, z. B. um UI-Indikatoren zu aktualisieren, Telemetriedaten zu protokollieren oder ein adaptives Verhalten auszulösen. Das Ereignis enthält die aktuellen Medienverbindungsstatistiken zusammen mit dem Grund für die Änderung.

Bewertung des Netzwerkzustands

Der Netzzustand ist ein Wert, der den Gesamtzustand der Netzverbindung für einen bestimmten Transport (lokal oder entfernt) widerspiegelt. Der Wert wird aus Kennzahlen wie Paketverlust und geschätzter verfügbarer Bandbreite abgeleitet. Höhere Werte weisen auf bessere Netzwerkbedingungen hin.

Ergebnis Beschreibung
Unbekannt Der Zustand des Netzes konnte nicht ermittelt werden.
Ausgezeichnet Ausgezeichnete Netzwerkbedingungen. Die Videoqualität ist optimal und die geschätzte Bandbreite kann die maximale Bitrate für die aktuelle Auflösung aufnehmen.
Gut Gute Netzbedingungen. Kleinere oder vorübergehende Probleme können auftreten.
Messe Mäßige Netzwerkbedingungen. Die Videoqualität kann durch den Sender eingeschränkt sein.
Warnung Schlechte Netzwerkbedingungen. Die Videoqualität wird stark beeinträchtigt, und eine Warnung zur Deaktivierung des Videos wird ausgelöst, wenn der Audio-Fallback aktiviert ist.
Kritisch Schwere Netzwerkprobleme. Wenn Audio-Fallback aktiviert ist, deaktiviert das SDK Video, um die Anrufstabilität zu erhalten.

Anmerkung: Die Bewertung der Netzqualität bezieht sich auf die aktuelle Medienkonfiguration und die Bandbreitenanforderungen. Sie gibt an, wie gut das Netzwerk die aktiven Anforderungen (z. B. Videoauflösung, Bitrate, Bildrate) unterstützt. Wenn die Anwendung beispielsweise für eine niedrige Kameraauflösung oder eine niedrige Bitrate konfiguriert ist, kann das Netzwerk als hervorragend eingestuft werden, da der Bandbreitenbedarf minimal ist. Höhere Auflösungen oder Bitraten erfordern mehr Netzwerkkapazität und können unter den gleichen Netzwerkbedingungen zu unterschiedlichen Qualitätsbewertungen führen.

Grund für den Netzwerkzustand

Jede Bewertung des Netzzustands wird mit einer Begründung versehen, die den Hauptfaktor für die Bewertung angibt:

  • Keine: Kein nennenswerter Grund.
  • Bandbreite: Der Zustand des Netzes hängt von der verfügbaren Bandbreite ab.
  • Verlust von Paketen: Netzzustand durch Paketverluste beeinträchtigt.

Netzverschlechterung Quelle

Die Quelle der Netzverschlechterung gibt an, welche Seite der Verbindung in erster Linie für eine beobachtete Netzverschlechterung verantwortlich ist. Diese Kennzahl ist für Teilnehmer verfügbar und gibt Aufschluss darüber, ob Leistungsprobleme vom Downlink des Teilnehmers oder vom Uplink des entfernten Anbieters ausgehen.

Die Quelle für Netzwerkverschlechterungen hilft Applications dabei, die Ursache von Netzwerkproblemen zu ermitteln und ermöglicht so eine gezielte Fehlersuche und Nutzerkommunikation. Anstatt nur zu melden, dass die Netzbedingungen schlecht sind, wird angegeben, ob das Problem mit der Verbindungsqualität des lokalen Teilnehmers oder des entfernten Herausgebers zusammenhängt.

Mögliche Werte:

  • Keine: Keine Beeinträchtigung des Netzes festgestellt. Sowohl die lokalen als auch die Fernverbindungen funktionieren gut.
  • Lokal: Das lokale Teilnehmernetz ist die Hauptursache für die Verschlechterung. Zu den Problemen können ein schlechtes WiFi-Signal, hohe Paketverluste im Downlink oder eine begrenzte verfügbare Bandbreite in der Verbindung des Teilnehmers gehören.
  • Ferngesteuert: Das Netz des entfernten Herausgebers ist die Hauptursache für die Verschlechterung. Der Verleger hat schlechte Netzwerkbedingungen auf seinem Uplink, was sich auf die Medienqualität auswirkt, die dieser Teilnehmer empfängt.
  • Beides oder unklar: Die Verschlechterung tritt auf beiden Seiten der Verbindung auf, oder die Ursache kann nicht eindeutig einer Seite zugeordnet werden. Dies ist typischerweise der Fall, wenn sowohl der Teilnehmer als auch der Herausgeber gleichzeitig von Netzwerkproblemen betroffen sind.

Netzwerkstatus nach Sender und Empfänger

Ein Publisher kann viele Abonnenten bedienen, während jeder Abonnent einen einzelnen Datenstrom von einem Publisher empfängt. Die Meldung des Netzwerkzustands erfolgt wie folgt: Ein Publisher meldet den Zustand seiner eigenen Uplink-Verbindung, und ein Abonnent meldet seinen Downlink, den Uplink des entfernten Publishers sowie die Seite, die für eine eventuelle Verschlechterung verantwortlich ist.

Ein Verlag meldet den Link, dessen Eigentümer er ist. In einer gerouteten Sitzung unterhält der Publisher lediglich eine Peer-Verbindung zum Vonage Video-Media-Router, unabhängig davon, wie viele Abonnenten den Stream empfangen. Der Media Router beendet diese Verbindung und leitet die Medien über eigene, separate Verbindungen an jeden Abonnenten weiter. Die Transportmetriken des Publishers beschreiben daher das Segment des Medienpfads vom Publisher zum Media Router – das Segment, auf das der Publisher durch seine eigene Codierung und Ratenkontrolle direkten Einfluss nehmen kann. Dies ist auch der Grund, warum das Statistik-Array eines gerouteten Publishers ein einzelnes Objekt enthält, bei dem die Verbindungs-ID und die Abonnenten-ID nicht definiert sind, wie beschrieben in Verlagsstatistik. Bei Sitzungen mit mehr als zwei Teilnehmern wäre eine Ausweitung dieser Kennzahlen auf jeden empfangenden Teilnehmer nicht skalierbar und hätte nur einen begrenzten diagnostischen Wert: Der Media Router leitet den Stream an eine unbestimmte Anzahl von Teilnehmern weiter, sodass die Daten auf der Publisher-Seite weder ein Netzwerkproblem isolieren noch einen Ausfall einem bestimmten Teilnehmer zuordnen könnten.

Durch die Meldung der lokalen Verbindung bleiben AMR-Übergänge transparent. Während Adaptives Medien-Routing (AMR) Auch wenn speziell Anrufe mit zwei Teilnehmern behandelt werden, bei denen jeder Publisher einen einzigen Subscriber hat, kann ein weitergeleiteter Medienpfad während des Gesprächs dennoch zum Media Router migrieren, wenn weitere Teilnehmer hinzukommen oder bestimmte Funktionen aktiviert werden. Da die Medienverbindungsstatistiken des Publishers dessen eigene Netzwerkverbindung beschreiben – also dessen Uplink, unabhängig davon, ob diese Verbindung bei einem Subscriber oder beim Media Router endet –, bleiben ihre Bedeutung und Form bei einem solchen Übergang unverändert. Anwendungen können Publisher-Statistiken konsistent nutzen, ohne die aktuelle Topologie verfolgen oder sich während des Gesprächs daran anpassen zu müssen. Dies entspricht dem zu Beginn dieses Leitfadens genannten Designziel, wonach sich die übergeordnete Statistik-API klar auf die Abstraktionen von Publisher und Subscriber abbilden lässt und über Übergänge hinweg stabil bleibt.

Bei Gesprächen mit zwei Teilnehmern ist die Ansicht des Teilnehmers maßgeblich. Wenn jeder Teilnehmer einen Stream veröffentlicht und einen Stream abonniert, reichen die Abonnentenstatistiken aus, um Rückschlüsse auf beide Richtungen zu ziehen. Wenn ein Abonnent eine Ursache für eine Verschlechterung meldet, die Remote, ist die Uplink-Verbindung des Remote-Teilnehmers eingeschränkt – und auch der eigene Teilnehmer dieses Teilnehmers leidet wahrscheinlich unter Beeinträchtigungen, da die üblichen Ursachen (schwaches WLAN-Signal, ein überlastetes Zugangsnetz, schlechte Mobilfunkabdeckung) beide Richtungen einer Verbindung betreffen. Betrachten Sie dies eher als eine Schlussfolgerung denn als eine Garantie.

Siehe auch Korrelieren Sie Publisher- und Subscriber-Metriken, um die Grundursache zu diagnostizieren.

Beziehung zum Audio-Fallback

Die Meldung von Netzwerkbedingungen ist auf den Audio-Fallback-Mechanismus abgestimmt. Wenn Audio-Fallback-Ereignisse auf der Stufe "Warnung" oder "Kritisch" ausgelöst werden, spiegelt die gemeldete Netzwerkbedingung den gleichen Schweregrad wider. Die Netzwerkbedingung gibt den entsprechenden Warn- oder kritischen Zustand für den Herausgeber, den Teilnehmer oder beide an, wodurch eine konsistente Signalisierung über Netzwerk- und Media-Fallback-APIs hinweg gewährleistet wird.

Der umgekehrte Fall kann ebenfalls eintreten: Die Netzwerkbedingung kann eine Warnung oder einen kritischen Wert melden, ohne dass der Audio-Fallback ausgelöst wird, was der Fall ist, wenn der Audio-Fallback deaktiviert ist.

Netzwerkzustand aktivieren

Die Berichterstattung über den Netzzustand beruht auf dem Zusammenspiel mehrerer Funktionen. Je mehr Funktionen Sie aktivieren, desto umfangreicher und genauer werden die Netzzustandsdaten:

  • Statistik auf der Absenderseite: Aktivieren Sie absenderseitige Statistiken auf dem Verleger, damit Abonnenten Transportmetriken des Verlegers aus der Ferne erhalten und eine genauere Zuordnung der Quelle von Netzwerkverschlechterungen vornehmen können.
  • Publisher Audio Fallback: Aktivieren Sie das Audio-Fallback auf der Verlagsseite, um die Genauigkeit der verlagsseitigen Bewertung der Netzwerkbedingungen zu verbessern.
  • Teilnehmer-Audio-Fallback: Aktivieren Sie Audio-Fallback auf dem Teilnehmer, um die Genauigkeit der teilnehmerseitigen Netzzustandsbewertung zu verbessern.

Wenn diese Funktionen nicht aktiviert sind, sind einige Netzzustandsdaten möglicherweise nur eingeschränkt oder gar nicht verfügbar.

Für den Empfang von Ereignissen, bei denen sich die Netzbedingungen ändern, registrieren Sie einen Callback oder Listener für Änderungen der Netzbedingungen auf dem Herausgeber oder Teilnehmer. Das Ereignis enthält die aktuellen Medienverbindungsstatistiken mit Netzwerkbedingungen und Transportmetriken. Einzelheiten finden Sie im Entwicklerhandbuch für jedes Client SDK im Ermöglichung der Erfassung von Audio- und Videostatistiken Abschnitt.

Verwendung von Einblicken in die Kundenbeobachtbarkeit

In diesem Abschnitt finden Sie praktische Hinweise, wie Sie diese Signale wirksam einsetzen und häufige Fehler vermeiden können.

Bewährte Praktiken

Lassen Sie das SDK die Qualität automatisch anpassen und reagieren Sie dann auf das Ergebnis

Das SDK übernimmt die Qualitätsanpassung bereits automatisch:

  • Verlagsseite: Bei Bandbreiten- oder CPU-Beschränkungen reduziert der Herausgeber automatisch die Auflösung und die Bildrate. Bei Simulcast- oder SVC-Konfigurationen bedeutet dies, dass der Encoder möglicherweise auf eine niedrigere räumliche oder zeitliche Ebene zurückgreift.
  • SFU (geroutete Sitzungen): Der Vonage Video Media Router wählt den geeigneten Simulcast-Layer für jeden Teilnehmer auf der Grundlage der verfügbaren Downlink-Bandbreite des jeweiligen Teilnehmers aus. Ein Teilnehmer mit einer schwachen Verbindung empfängt einen Layer mit niedrigerer Auflösung, ohne dass die Anwendung eingreifen muss.
  • Vermittelte Sitzungen: Der Verleger skaliert direkt für jeden Peer herunter, da er einzelne Streams an jeden Teilnehmer sendet.

Sie müssen und sollten nicht versuchen, diese Logik in Ihrer Anwendung zu replizieren. Verwenden Sie stattdessen die Beobachtbarkeitsereignisse, um reagieren auf das Ergebnis: Aktualisieren Sie Ihre Benutzeroberfläche, protokollieren Sie Telemetriedaten oder lösen Sie übergeordnete Richtlinienentscheidungen auf der Grundlage der vom SDK bereits gemeldeten Daten aus.

Wenn Sie eine quality_limitation_reason von bandwidth in den Videometriken des Herausgebers anzeigt, drosselt der Encoder bereits die Ausgabe. Nutzen Sie dieses Signal, um UX-Entscheidungen zu treffen (z. B. das Ausblenden einer hochauflösenden Vorschau), anstatt überflüssige Auflösungsüberschreibungen auszugeben. Ähnlich verhält es sich, wenn der Grund cpuUm dem Encoder mehr Spielraum zu verschaffen, sollten Sie in Erwägung ziehen, CPU-Ressourcen an anderer Stelle in Ihrer Anwendung freizugeben, z. B. indem Sie nicht benötigte Animationen pausieren, die Hintergrundverarbeitung aufschieben oder die Komplexität des UI-Renderings reduzieren.

Anzeige eines Echtzeit-Netzqualitätsindikators

Verwenden Sie den Netzwerkzustandswert aus der Medienverknüpfungsstatistik, um einen Qualitätsindikator in Ihrer Benutzeroberfläche darzustellen, z. B. Signalstärkebalken oder ein farbiges Symbol. Aktualisieren Sie den Indikator nur, wenn die Netzwerkbedingung Änderungen (unter Verwendung des Ereignisses "Netzbedingung geändert") und nicht bei jedem periodischen Statistik-Tick. Dadurch werden unnötige Neuberechnungen vermieden, während der Indikator weiterhin auf bedeutsame Qualitätsveränderungen reagiert.

Die Quelle für die Verschlechterung der Netzqualität gibt Ihnen Auskunft über die Teilnehmer welche Seite des Anrufs betroffen ist. Stellen Sie dies in Ihrer Benutzeroberfläche dar, damit die Teilnehmer ein gezieltes, umsetzbares Feedback erhalten, z. B. "Ihre Verbindung ist instabil" im Gegensatz zu "Der entfernte Teilnehmer hat Probleme mit dem Netzwerk" - anstelle einer allgemeinen Qualitätswarnung.

Ereignisse für adaptive UX verwenden, nicht für Abfragen

Bevorzugen Sie ereignisgesteuerte Rückrufe gegenüber der Inspektion periodischer Statistik-Arrays für die Schwellenwertlogik. Das Ereignis "Netzwerkbedingung geändert" und das Ereignis "Videoqualität geändert" sind speziell für die Erkennung sinnvoller Übergänge konzipiert. Das Abfragen der periodischen Statistiken auf Schwellenwertüberschreitungen bei jedem Tick führt zu CPU-Overhead.

Wenn Sie auf periodische Statistiken reagieren müssen, sollten Sie Ihre Logik über mehrere aufeinanderfolgende Stichproben entkoppeln, bevor Sie eine UX-Änderung auslösen.

Nutzung der Verkehrsstatistik für Layout- und Politikentscheidungen

Die Subscriber-Media-Link-Statistiken zeigen die Transportmetriken aus zwei Perspektiven gleichzeitig:

  • Statistiken zum Nahverkehr spiegeln die Bandbreite wider, die der Absender (der Herausgeber oder der Vonage Video Media Router) für die Verbindung zu diesem Teilnehmer als verfügbar einschätzt. Da die Bandbreitenschätzung in WebRTC vom Sender auf der Grundlage von RTCP-Feedback durchgeführt wird, stellt diese Zahl die Sicht des Senders auf die Kanalkapazität dar - und nicht eine Selbstmessung durch den Teilnehmer.
  • Transportstatistiken für Fernverlage die eigenen Uplink-Transportmetriken des Verlegers widerspiegeln, wie sie von der Seite des Verlegers gemeldet werden.

Mit diesen beiden Ansichten können Sie den gesamten Weg zwischen Herausgeber und Abonnent nachvollziehen. Nutzen Sie sie, um proaktive Layout- und Richtlinienentscheidungen zu treffen:

  • Begrenzen Sie die Anzahl der sichtbaren Videokacheln in einem Raster-Layout, wenn die geschätzte Kapazität gering ist, wobei Teilnehmer mit geringerer Priorität ausgeblendet werden, anstatt dass das Video eingefroren oder verschlechtert angezeigt wird.
  • Auslösen von Quality on Demand (QoD) Richtlinien in Mobilfunknetzen, wenn die geschätzte lokale Transportbandbreite unter einen bestimmten Schwellenwert sinkt, z. B. beim Wechsel von hochauflösenden zu normal auflösenden Streams.
  • Eine Kapazitätswarnung anzeigen bevor ein neuer Stream mit hoher Bitrate (z. B. Bildschirmfreigabe) zu einer Sitzung hinzugefügt wird, wenn die geschätzte lokale Transportbandbreite bereits begrenzt ist.

In einem Grid mit mehreren Teilnehmern können Sie diesen Ansatz erweitern, indem Sie Transportstatistiken und CPU-Beschränkungssignale verwenden, um den Publishern ein Qualitätsbudget zuzuweisen. Das SDK passt jeden Stream unabhängig an und weiß nicht, welche Teilnehmer in Ihrem Layout wichtig sind - die Priorisierung erfolgt auf Anwendungsebene. Verwenden Sie setPreferredResolution und setPreferredFrameRate auf den Verleger, um es auszudrücken: gewähren Sie der vorgestellten Kachel die volle Auflösungsobergrenze und begrenzen Sie die Teilnehmer im Hintergrund auf niedrigere Werte. Wenn sich der aktive Sprecher ändert oder sich die Bedingungen ändern, werden die Obergrenzen entsprechend angepasst. Dies ist eine Ergänzung zur automatischen Anpassung des SDK, die innerhalb der von der Anwendung festgelegten Obergrenzen weiterläuft.

Korrelieren Sie Publisher- und Subscriber-Metriken, um die Grundursache zu diagnostizieren

Netzwerkprobleme können auf beiden Seiten des Anrufs entstehen. Verwenden Sie die Kombination aus Statistiken über die Medienverbindung des Herausgebers und des Teilnehmers - zusammen mit der Quelle der Netzwerkbeeinträchtigung - um die Ursache zu ermitteln:

  • Eine Warnung oder ein kritischer Netzwerkzustand auf dem Uplink des Herausgebers in Verbindung mit einem Remote Die Degradierungsquelle beim Abonnenten weist auf ein verlagsseitiges Netzproblem hin.
  • Ein Rückgang der verfügbaren Bandbreite auf der Abwärtsstrecke des Teilnehmers in Verbindung mit einem Local Die Degradierungsquelle verweist auf den eigenen Anschluss des Teilnehmers.
  • Wenn beide Seiten eine Verschlechterung aufweisen oder die Quelle Both or unclearBehandeln Sie das Problem als eine gemeinsame Angelegenheit.

Protokollstatistiken für Post-Call-Analyse und Fehlersuche

Speichern Sie regelmäßige Statistiken und Ereignisse zur Änderung der Netzwerkbedingungen in einer Backend-Analysepipeline. Zu den wichtigsten Metriken, die erfasst werden sollten, gehören:

  • Netzzustandsbewertung und Grund im Zeitverlauf pro Verlag und Abonnent.
  • Grund für die Begrenzung der Videoqualität und aktive Schicht (Simulcast/SVC).
  • Geschätzte verfügbare Bandbreite aus der Medienverbindungsstatistik.
  • Numbers und Gesamtdauer von Videoeinbrüchen und -pausen.
  • MOS-Score (Web SDK) als Indikator für die wahrgenommene Anrufqualität.

Die Analyse dieser Protokolle nach einem Anruf kann Muster aufzeigen, wie z. B. wiederkehrende Verschlechterungen zu bestimmten Tageszeiten, in bestimmten Netzwerktypen oder für bestimmte Gerätemodelle, und so zu Verbesserungen der Infrastruktur und der Benutzeroberfläche führen.

Anti-Patterns

Setzen Sie die automatische Qualitätsanpassung des SDK nicht außer Kraft

Das SDK reduziert bereits die Auflösung und die Bildrate, wenn die Bandbreite oder die CPU begrenzt ist. Manuelle Auflösungsänderungen als Reaktion auf jedes Statistikereignis führen in der Regel zu Konflikten mit der Ratensteuerung des Encoders und können zu Oszillationen führen, d. h. zu einem schnellen Wechsel zwischen den Qualitätsstufen, was die wahrgenommene Qualität stärker verschlechtert als eine sanfte automatische Herabstufung.

Wenn Sie bestimmte Qualitätsanforderungen haben (z. B. eine maximal zulässige Auflösung), konfigurieren Sie diese deklarativ bei der Sitzungseinrichtung, anstatt auf Statistikereignisse zur Laufzeit zu reagieren.

Nur-Audio-Fallback nicht manuell anhand von Transportstatistiken auslösen

Die SDKs Audio-Fallback Funktion überwacht bereits die Netzwerkbedingungen und deaktiviert automatisch das Video, wenn die Verbindung auf ein Warn- oder kritisches Niveau sinkt. Die Implementierung einer eigenen Logik zum Umschalten eines Teilnehmers in den reinen Audiomodus auf der Grundlage der Schätzung der lokalen Transportbandbreite dupliziert dieses eingebaute Verhalten und kann zu Konflikten führen - z. B. zur vorzeitigen Deaktivierung von Video, bevor die Schwellenwerte des SDK erreicht sind, oder zur erneuten Aktivierung an einem anderen Punkt als dem des SDK. Wenn Sie ein Audio-Fallback-Verhalten benötigen, verwenden Sie die Audio-Fallback-Funktion des SDK, anstatt es direkt aus der Transportstatistik zu steuern.

UI-Änderungen nicht bei jedem periodischen Statistikereignis auslösen

Periodische Statistiken werden in regelmäßigen Abständen (in der Regel alle paar Sekunden) ausgelöst. Die Anwendung von UI-Updates oder Geschäftslogik auf jedes Ereignis, insbesondere Schwellenwertüberprüfungen bei verrauschten Metriken wie z. B. sofortigem Paketverlust, führt zu flackernden Indikatoren und unerwünschten Warnmeldungen. Glätten Sie Ihre Signale immer: Erfordern Sie mehrere aufeinanderfolgende Abtastungen unterhalb eines Schwellenwerts oder verwenden Sie das spezielle Ereignis "Netzwerkbedingung geändert", bevor Sie den Status der Benutzeroberfläche aktualisieren.

Verlassen Sie sich nicht allein auf verlagsseitige Metriken, um die Erfahrung des Abonnenten zu diagnostizieren

Die Publisher-Metriken spiegeln die Upstream-Übertragungsqualität wider. Ein Herausgeber kann hervorragende Netzwerkbedingungen melden, während ein oder mehrere Teilnehmer eine schlechte Downlink-Qualität erfahren. Um die Erfahrung eines bestimmten Teilnehmers zu beurteilen, kombinieren Sie immer die Statistiken des Herausgebers für die Medienverbindung mit den Metriken auf der Teilnehmerseite, einschließlich der Quelle der Netzwerkverschlechterung.

Verwenden Sie keine rohen Byte- oder Paketzählungen als Qualitätssignale

Kumulierte Summen wie bytesReceived oder packetsLost wachsen monoton und haben für sich genommen keine eigene Bedeutung. Berechnen Sie immer die Raten (Delta über das Intervall zwischen den Abtastungen) oder verwenden Sie die übergeordneten Felder, wie z. B. die geschätzte Bitrate oder den Netzwerkzustandswert, die das SDK bereits aus den Rohzählern ableitet.

Verwenden Sie keine Low-Level-RTC-Statistiken für die End-to-End-Qualitätsmessung

Der RTC-Statistikbericht spiegelt den Zustand einer einzeln zugrundeliegende Peer-Verbindung zu einem bestimmten Zeitpunkt. Das SDK kann während einer Sitzung zwischen Peer-Verbindungen oder Übergangstopologien wechseln, so dass rohe RTC-Statistiken nicht über diese Übergänge hinweg aggregiert werden. Für die Messung der End-to-End-Qualität und die Überwachung lang laufender Sitzungen sollten Sie immer die APIs für Audio-, Video- und Medienverbindungsstatistiken auf hoher Ebene verwenden, die diese internen Änderungen berücksichtigen.

Ignorieren Sie nicht die Unterschiede zwischen gerouteten und weitergeleiteten Sitzungen

Bei einer gerouteten Sitzung werden die senderseitigen Statistiken vom Vonage Video Media Router bereitgestellt, und die teilnehmerseitigen Bandbreitenschätzungen spiegeln den Downlink des Teilnehmers zum Media Router wider - und nicht eine direkte Messung des Uplinks des Herausgebers. Bei einer Relayed-Sitzung (Peer-to-Peer) sendet der Publisher einzelne Streams an jeden Teilnehmer, und die Publisher-Statistiken stellen direkte Peer-Messungen dar. Berücksichtigen Sie bei der Erstellung von Analysen oder adaptiver Logik den Sitzungsmodus, um Fehlinterpretationen der Numbers zu vermeiden.

RTC-Statistikbericht

Die RTC-Stats-Report-API bietet Zugriff auf standardisierte WebRTC-Statistiken auf niedriger Ebene für den veröffentlichten und abonnierten Medienstrom. Dadurch können Applikationen detaillierte Metriken in dem von der WebRTC-Spezifikation definierten Format abrufen, was eine erweiterte Überwachung und Analyse über die benutzerdefinierten Client-Beobachtbarkeitsmetriken hinaus ermöglicht.

Anmerkung: Diese API liefert Low-Level-Statistiken zu Peer-Verbindungen. Das Video-SDK kann Peer-Verbindungen optimieren, zwischen verschiedenen Topologien wechseln oder auf einen anderen Backend-Server migrieren. Diese Low-Level-Statistiken aggregieren nicht die Metriken verschiedener Peer-Verbindungen, die gerade genutzt werden oder von denen ein Wechsel stattgefunden hat. Daher empfiehlt es sich, für die End-to-End-Überwachung auf unsere Audio- und Video-Statistik-API zurückzugreifen.

Ermöglichung der Erfassung von Audio- und Videostatistiken

In Publisher oder Subscriber hören Sie auf die entsprechenden Statistikereignisse. Einzelheiten finden Sie im entsprechenden Entwicklerhandbuch für jedes Client SDK: