Sitzungen

Um eine Verbindung zu einer Sitzung herzustellen, müssen Sie die Sitzung, zu der Sie eine Verbindung herstellen möchten, mit ihrer Sitzungs-ID angeben.

Jede Sitzungs-ID identifiziert eine eindeutige Sitzung. Sie können sich eine Sitzung als einen Raum vorstellen, in dem sich die Teilnehmer treffen und unterhalten.

Die Anzahl der Sitzungen, die Sie erstellen, und die Art und Weise, wie sich Clients mit ihnen verbinden, hängen von den Anforderungen Ihrer Anwendung ab.

Wenn Ihre App Benutzer für ein einmaliges Treffen miteinander verbindet, erstellen Sie eine eindeutige Sitzung für dieses Treffen.

Wenn Ihre App die Nutzer jedoch über mehrere Tage hinweg im selben "Raum" verbindet, können Sie eine Sitzung erstellen und diese wiederverwenden. Wenn sich eine Gruppe von Nutzern gemeinsam trifft, während andere Gruppen unabhängig voneinander tagen, erstellen Sie für jede Gruppe eine eigene Sitzung.

Sitzungen laufen nicht ab. Authentifizierungstoken laufen jedoch ab – die maximale TTL eines Tokens beträgt 24 Stunden. Weitere Informationen zur Generierung von Tokens und zum Umgang mit lang andauernden Sitzungen finden Sie unter Ein Token erstellen. Beachten Sie außerdem, dass Sitzungen nicht explizit beendet werden können.

Wenn Sie eine Sitzung erstellen, können Sie die folgenden Optionen angeben, die in den folgenden Abschnitten beschrieben werden:

• Der Medienmodus (ob der Medienrouter verwendet werden soll oder nicht).
• Die Präferenz für die Archivierung (ob der Lauf automatisch archiviert werden soll).
• Ein Ortshinweis (zur Angabe des geografischen Standorts der Sitzung).

Der Media Router und die Medienmodi

Wenn Sie eine Sitzung erstellen, legen Sie fest, wie die Clients in der Sitzung Audio- und Videoströme senden sollen, was als Medienmodus bezeichnet wird. Es gibt zwei Optionen:

• Weitergereicht - In einer weitergeleiteten Sitzung versuchen die Clients, Audio- und Videoströme direkt untereinander zu senden (Peer-to-Peer). Wenn die Clients jedoch aufgrund von Firewall-Beschränkungen keine Verbindung herstellen können, verwendet die Sitzung den TURN-Server zur Weiterleitung von Audio-Video-Streams. (Vor Version 2.2 bezeichneten die Server-SDKs diese Sitzungen als Peer-to-Peer-Sitzungen. Aber auch bei Verwendung dieser SDKs verwenden die Sitzungen den TURN-Server zur Weiterleitung von Streams, wenn Firewall-Beschränkungen Peer-to-Peer-Streaming blockieren). TLS 1.3 und ein starkes Zertifikat von mindestens 3072 Bit werden für die Sitzungsaushandlung verwendet.

• Geroutet - Die Sitzung verwendet den Media Router, um Audio- und Videoströme zwischen den Clients weiterzuleiten. Der Media Router bietet die folgenden Vorteile:

  • TLS 1.3 und ein starkes Zertifikat von mindestens 3072 Bit werden für die gesamte Signalisierung verwendet.

  • Der Medien-Router kann die Bandbreitennutzung in Mehrteilnehmer-Sitzungen verringern. (Wenn die Eigenschaft "Medienmodus" auf "Relayed" eingestellt ist, muss jeder Client, der einen Stream veröffentlicht, diesen separat an jeden Client, der ihn abonniert, senden. Mit dem Media Router sendet ein Verleger einen Stream einmal an den Router und dieser leitet ihn an jeden abonnierenden Client weiter).

  • Der Media Router kann die Qualität der Benutzererfahrung durch Audio-Fallback und Video-Wiederherstellung verbessern. Wenn sich die Konnektivität eines Clients so weit verschlechtert, dass er das Video für einen abonnierten Stream nicht mehr unterstützt, wird das Video auf diesem Client unterbrochen (ohne Auswirkungen auf andere Clients), und der Client erhält nur noch Audio. Wenn sich die Konnektivität des Clients verbessert, wird das Video wieder angezeigt.

  • Der Media Router unterstützt die Archivierungsfunktion, mit der Sie Sitzungen aufzeichnen, speichern und wieder abrufen können.

  • In Sitzungen, die den Media Router verwenden, wird durch die Verringerung der Bildrate für ein veröffentlichtes Video die Bandbreite, die der Stream benötigt, proportional reduziert.

  • Der Media Router unterstützt die Funktion für skalierbares Video. Skalierbares Video kann die Qualität von Videos in Sitzungen mit mehreren Teilnehmern erheblich verbessern.

  • Bei Clients, die die iOS- und Android-SDKs verwenden, unterstützen weitergeleitete Sitzungen nur zwei Clients, die mit der Sitzung verbunden sind. Der Media Router unterstützt zusätzliche Clients für Mehrteilnehmer-Sitzungen auf mobilen Geräten.

  • Der Media Router unterstützt die SIP-Interconnect-Funktion, mit der Sie Sitzungen mit SIP-Gateways verbinden können.

• Einzelne Peer-Verbindung. Ab Version 2.28.0 der Client-SDKs für iOS, Android, Windows, macOS und Linux werden geroutete Sitzungen unterstützt einzelne Peer-Verbindung. Wenn die Einzel-Peer-Verbindung aktiviert ist, werden alle Abonnentenströme für einen Client mit einer einzigen Verbindung zum Medien-Router geliefert (auch wenn sie von verschiedenen Clients veröffentlicht werden). Zu den Vorteilen der Aktivierung der Einzel-Peer-Verbindung gehören ein geringerer Ressourcenverbrauch des Clients, eine verbesserte Ratenkontrolle und - im Falle von mobilen nativen Geräten - die Unterstützung größerer Sitzungen. Wenn die Einzel-Peer-Verbindung deaktiviert ist (Standardeinstellung), verwendet der Client für jedes Audio-/Videobündel eine eigene Verbindung zum Media Router.

  Die Einzel-Peer-Verbindung ist nur in gerouteten Sitzungen verfügbar (Sitzungen, die den Vonage Video API Media Router verwenden). Eine vollständige Anleitung mit Anwendungsfällen, Konfigurationsdetails, Codebeispielen und Interaktion mit anderen Funktionen finden Sie in der Single Peer Connection Entwicklerhandbuch.

  Um eine einzelne Peer-Verbindung zu ermöglichen, verwenden Sie die folgenden Client SDK APIs:

  • Web SDK - Siehe die singlePeerConnection Eigenschaft der Optionen, die Sie in OT.initSession()
  • Android SDK - Session.Builder.setSinglePeerConnection()
  • iOS SDK - OTSessionSettings.singlePeerConnection
  • Linux SDK - otc_session_settings_set_single_peer_connection()
  • macOS SDK - otc_session_settings_set_single_peer_connection()
  • Windows SDK - SinglePeerConnection Eigenschaft der Session.Builder Klasse
  • React Native SDK - Das enableSinglePeerConnection Eigenschaft der options prop der Komponente OTSession

• Optimierung des Media Mesh: Die Plattform nutzt Media Mesh zur automatischen Optimierung der gerouteten Sitzungen, indem sie jeder Teilnehmer mit dem Medienrouter in seinem nächstgelegenen regionalen Rechenzentrum verbunden wird. Dies reduziert die Latenzzeit und verbessert die Qualität, insbesondere bei geografisch verteilten Sitzungen.

  Media Mesh ist standardmäßig aktiviert und erfordert keine Konfiguration. Um diese Optimierung außer Kraft zu setzen und die Medien auf eine bestimmte Region zu beschränken, siehe Regionale Medienzonen.

Adaptive Medienweiterleitung

Adaptive Media Routing (AMR) ist eine Leistungsoptimierung für weitergeleitete Sitzungen. AMR wertet die Anzahl der Abonnenten eines jeden Herausgebers einzeln aus. Wenn ein Publisher nur einen Abonnenten hat und keine Funktionen verwendet werden, die den Media Router erfordern (z. B. Archivierung, Live-Streaming, SIP usw.), leitet die Plattform die Medien dieses Publishers Peer-to-Peer an den Abonnenten weiter, anstatt sie über den Media Router zu leiten. Dies verringert die Latenzzeit und kann die Audio- und Videoqualität verbessern.

Die Sitzung bleibt zu jeder Zeit eine geroutete Sitzung. AMR ändert nicht den Medienmodus der Sitzung - es ändert nur die Medienweg unter der Haube verwendet. Ihr Anwendungscode, die Token und die serverseitige Sitzungskonfiguration bleiben genau gleich. Der Wechsel zwischen Peer-to-Peer-Relaying und Media Router-Relaying wird von den Client-SDKs transparent gehandhabt.

Wenn AMR Peer-to-Peer-Relaying verwendet

AMR leitet Medien direkt zwischen einem Herausgeber und seinem Teilnehmer weiter (unter Umgehung des Medienrouters im Medienpfad), wenn alle der folgenden Punkte sind zutreffend:

• Der Verlag hat genau ein Abonnent.
• Keine der im nächsten Abschnitt aufgeführten Funktionen ist aktiv.

So kann beispielsweise eine Sitzung mit vier Herausgebern und vier Teilnehmern vollständig im Peer-to-Peer-Relaying bleiben, solange jeder Herausgeber nur einen Teilnehmer hat und keine Media Router-Funktionen verwendet werden.

Wenn AMR zum Media Router wechselt

Die Plattform leitet die Medien eines Publishers durch den Media Router weiter, wenn jede der folgenden Bedingungen gelten:

• Ein Verleger hat mehr als ein Teilnehmer (z. B. wenn ein zweiter Client denselben veröffentlichten Stream abonniert).
• Archivierung gestartet wird (einschließlich Läufen mit aktivierter automatischer Archivierung).
• Live-Streaming-Übertragungen gestartet werden.
• SIP-Zusammenschaltung verwendet wird.
• Erlebnis-Komponist rendert die Sitzung.
• Audio-Anschluss aktiv ist.
• Live-Unterschriften aktiviert sind.

Sobald ein Auslöser aktiviert wird, werden alle Medien der Verlage nahtlos über den Media Router geleitet.

SDK-Unterstützung

AMR wurde eingeführt in OpenTok.js v2.24.7 und Version 2.27.0 der Client-SDKs für Android, iOS, Windows, macOS, Linux und React Native. Clients mit älteren SDK-Versionen verwenden in einer gerouteten Sitzung immer den Media Router.

Auswirkungen auf Fehlersuche und Entwicklung

AMR ist für Ihre Anwendungslogik transparent, aber es gibt ein paar Dinge, die bei der Entwicklung und Fehlerbehebung zu beachten sind:

• Inspektor kann fehlerhaft sein clientDisconnection Veranstaltungen wenn die Medien eines Herausgebers von der Peer-to-Peer-Weitergabe zum Medienrouter übergehen (z. B. wenn ein zweiter Client einen Stream abonniert). Diese Ereignisse stellen keine tatsächlichen Unterbrechungen dar - die Teilnehmer bleiben während des Übergangs verbunden. Dies ist ein bekanntes Problem in Inspector.

• MediaStream-Objekte können sich bei Übergängen ändern. Wenn AMR zwischen Peer-to-Peer-Relaying und dem Media Router umschaltet, wird die zugrunde liegende MediaStream für einen Teilnehmer ersetzt wird. Wenn Ihre Anwendung auf Folgendes zugreift MediaStream Objekte direkt (zum Beispiel zum Rendern von Videos in benutzerdefinierten <video> Elemente), müssen Sie diese Änderung mit einer der folgenden Möglichkeiten behandeln:

  • Empfohlen: Verwenden Sie die Media Stream Available API (verfügbar in OpenTok.js v2.27.7+). Die mediaStreamAvailable Ereignis für Publisher- und Subscriber-Objekte berücksichtigt automatisch alle durch AMR verursachten Änderungen und liefert die korrekten MediaStream wenn ein Übergang stattfindet.

  • Älterer Ansatz (vor Version 2.27.7): Hören Sie auf die play Ereignis für das Videoelement des Teilnehmers, um zu erkennen, wann die MediaStream ersetzt wurde, und aktualisieren Sie Ihr benutzerdefiniertes Rendering entsprechend. Siehe die Zugriff auf MediaStream-Objekte für Abonnenten Leitfaden.

• Verbindungs- und Stream-Ereignisse werden weiterhin normal ausgelöst. Sie müssen AMR-Übergänge nicht in Ihren Sitzungsereignis-Listenern behandeln. Die streamCreated, streamDestroyed, connectionCreatedund connectionDestroyed Ereignisse spiegeln den tatsächlichen Zustand der Teilnehmer wider, nicht den zugrunde liegenden Medienweg.

Interaktion mit anderen Funktionen

• Einzel-Peer-Verbindung (SPC): SPC ist nur aktiv, wenn Medien durch den Medien-Router fließen. Während AMR die Medien eines Publishers Peer-to-Peer weiterleitet, gilt SPC nicht für diesen Stream. Sobald der Stream an den Medienrouter weitergeleitet wird, tritt SPC in Kraft, sofern sie aktiviert ist.

• Ende-zu-Ende-Verschlüsselung: Die Ende-zu-Ende-Verschlüsselung funktioniert mit AMR. Medien werden verschlüsselt, unabhängig davon, ob sie Peer-to-Peer oder durch den Media Router fließen.

• Audio-Fallback: Teilnehmer-Audio-Fallback ist eine Funktion des Medien-Routers, die normalerweise angewendet wird, sobald ein Stream durch den Medien-Router geroutet wurde. Während AMR jedoch die Medien eines Publishers peer-to-peer weiterleitet, Publisher Audio Fallback automatisch das Video deaktivieren, um den Audiostream zu schützen, falls erforderlich. Sobald der Stream an den Media Router weitergeleitet wird, gelten sowohl der Publisher- als auch der Subscriber-Audio-Fallback wie gewohnt.

• Simulcast und Skalierbarkeit: Während AMR die Medien Peer-to-Peer weiterleitet, wird skalierbares Video automatisch deaktiviert, unabhängig vom verwendeten Codec. Wenn der Stream zum Media Router übergeht, hängt das Verhalten von skalierbarem Video vom Codec und der Einstellung der Anwendung für skalierbares Video im Dashboard ab:

  • VP8: Wenn skalierbares Video eingestellt ist auf Auf oder Auto im Dashboard wird Simulcast automatisch auf dem gerouteten Leg aktiviert, sobald der Übergang zum Media Router erfolgt.
  • VP9: Skalierbares Video ist standardmäßig aktiviert, wenn es über den Media Router geleitet wird.
  • H.264: Skalierbares Video wird nicht unterstützt und bleibt in allen Fällen standardmäßig deaktiviert.

  Weitere Einzelheiten zu skalierbaren Videoeinstellungen und Codec-Unterstützung finden Sie im Skalierbare Videoanleitung.

Archiv-Modus

Wenn Sie einen Lauf erstellen, können Sie den Archivierungsmodus so einstellen, dass der Lauf automatisch archiviert wird.

Dies gilt nur für geroutete Sitzungen (Sitzungen, die den Media Router verwenden).

Standardmäßig werden die Sitzungen nicht automatisch archiviert.

Hinweise zum Standort

Wenn Sie eine Sitzung erstellen, können Sie die IP-Adresse festlegen, die von der Vonage Videoplattform verwendet wird, um den besten Server zur Steuerung der Sitzung in ihrem globalen Netzwerk auszuwählen.

Wenn bei der Erstellung der Sitzung kein Standorthinweis festgelegt wird (was empfohlen wird), wird der Sitzungssteuerungsserver auf der Grundlage des Standorts des ersten Clients, der eine Verbindung zur Sitzung herstellt, ausgewählt.

Setzen Sie einen Standort-Hinweis nur dann, wenn Sie die allgemeine geografische Region (und eine repräsentative IP-Adresse) kennen und davon ausgehen, dass der erste Client, der eine Verbindung herstellt, sich nicht in dieser Region befindet.

Geben Sie eine IP-Adresse an, die für den geografischen Standort der Sitzung repräsentativ ist.

Beim Medienstreaming verwendet das System immer den Standort-Hinweis, um eine Verbindung zum nächstgelegenen Medienserver (SFU) herzustellen, um sicherzustellen, dass der Medienverkehr über den für den geografischen Standort des Kunden optimalsten Server geleitet wird.

Bewährte Praktiken bei der Erstellung von Sitzungen

Wiederverwendung der Session-ID

Verwenden Sie nach Möglichkeit keine Sitzungs-IDs zwischen verschiedenen Video-Chat-Gesprächen.

Erstellen Sie stattdessen neue Sitzungs-IDs für jeden einzelnen Video-Chat in Ihrer Anwendung.

Dies ist wichtig, insbesondere bei der Verwendung der Sitzungsinspektor.

In Inspector werden die Bewertungen der Sitzungsqualität und die Daten durch die Sitzungs-ID indiziert.

Eine Sitzungs-ID, die für mehrere Gespräche wiederverwendet wird, ist mit Inspector schwieriger zu debuggen, und Sitzungen mit wiederverwendeten Sitzungs-IDs neigen dazu, niedrigere Gesamtqualitätswerte zu melden als die tatsächlich erlebte Anrufqualität.

Aktivieren Sie die Sitzungsmigration oder begrenzen Sie Sitzungen auf 8 Stunden

Die moderne automatische Skalierung der Cloud macht es erforderlich, eine Mindestrotationszeit für die Dienste festzulegen. Alle Sitzungen, die länger als 8 Stunden dauern, können getrennt werden, da sie sich in Diensten befinden, die aus- oder einskaliert werden.

Die Vonage Video API Client SDKs ab Version 2.30.0 enthalten eine Sitzungsmigrationsfunktion, die alle Teilnehmer einer Sitzung während der Serverrotation nahtlos auf einen neuen Server überträgt. Diese Funktion gewährleistet die Kontinuität der Sitzung bei minimaler Unterbrechung für die Teilnehmer. Siehe Serverrotation und Sitzungsmigration.

Clients werden auch von einer Sitzung getrennt, wenn sie innerhalb von 4 Stunden nach der Verbindung keine Streams veröffentlichen oder abonnieren.

Sie können verwenden Sitzungsüberwachung um Benachrichtigungen zu erhalten, wenn Sitzungen beendet werden oder die Zeit abgelaufen ist und wenn eine Gruppe von Video API-Servern für eine Sitzung gewechselt werden soll.

Weitere Informationen finden Sie unter Server-Rotation.

Auswahl des Sitzungstyps Relayed vs. Routed

Verwenden Sie eine weitergeleitete anstelle einer gerouteten Sitzung, wenn Sie nur zwei (oder vielleicht sogar drei) Teilnehmer haben und keine Archivierung verwenden.

Durch die Verwendung von Relayed Sessions werden die Latenzzeiten zwischen den Teilnehmern verringert, die Fehlerquellen reduziert und in den meisten Fällen eine bessere Video- und Audioqualität erzielt.

Routed Läufe sind erforderlich, wenn Sie Ihren Lauf archivieren möchten.

Sie werden empfohlen, wenn Sie mehr als zwei oder drei Teilnehmer an der Sitzung haben.

Weitere Informationen finden Sie unter Der Media Router und die Medienmodi.

Sitzungen erstellen

Wenn Sie an einer Testversion Ihrer Anwendung arbeiten, können Sie eine Test-Session-ID von der BAUEN & VERWALTEN > Applications Seite Ihres Vonage Account.

Ihre Anmeldedaten finden Sie auch auf dem Dashboard, bitte folgen Sie unserem erste Schritte Leitfaden, um mehr zu erfahren.

Für Ihre eigene Implementierung sehen Sie sich bitte die Server-seitige SDKs.

Wenn Sie mehrere Sitzungs-IDs dynamisch erzeugen müssen, verwenden Sie die Server-seitige SDKs nicht die Projektseite.

Verwenden Sie die Sitzungs-ID mit einer Client SDK um eine Verbindung zu einer Videositzung herzustellen.

Außerdem müssen Sie einen Token erzeugen für jeden Benutzer, der sich mit der Sitzung verbindet.

Die Medien-Router bietet die folgenden Vorteile:

• Der Media Router kann die Bandbreitennutzung in Mehrparteiensitzungen verringern. (Wenn die Eigenschaft mediaMode auf RELAISEDmuss jeder Client einen separaten Audio-Video-Stream an jeden Client senden, der ihn abonniert).
• Der Media Router kann die Qualität der Nutzererfahrung verbessern durch Audio-Fallback und Video-Wiederherstellung. Wenn sich die Verbindung eines Clients so weit verschlechtert, dass er kein Video für einen abonnierten Stream unterstützt, wird das Video für diesen Client unterbrochen (ohne Auswirkungen auf andere Clients), und der Client erhält nur noch Audio. Wenn sich die Konnektivität des Clients verbessert, wird der Videostream wiederhergestellt.
• Der Media Router unterstützt die Archivierungsfunktionmit dem Sie Sitzungen aufzeichnen, speichern und wieder abrufen können.

Erstellen einer weitergeleiteten Sitzung

Bei einer weitergeleiteten Sitzung versuchen die Clients, Streams direkt untereinander zu senden.

Wenn jedoch Clients aufgrund von Firewall-Beschränkungen keine Verbindung herstellen können, verwendet die Sitzung den TURN-Server zur Weiterleitung von Audio- und Videoströmen.

Folgen Sie unserem Schritt für Schritt Tutorials, um zu lernen, wie man weitergeleitete Sitzungen erstellt

Erstellen einer automatisch aufgezeichneten Sitzung

Sie können einen Lauf erstellen, der automatisch archiviert wird.

Weitere Informationen finden Sie in der Archivierung Leitfaden.

Verwendung von Sitzungen in Client-Applikationen

Verwenden Sie die Sitzungs-ID in der Client SDK um eine Verbindung zu einer Sitzung herzustellen.

Außerdem müssen Sie einen Token erzeugen für jeden Benutzer, der sich mit der Sitzung verbindet.