Übersicht über die Erstellung von Sitzungen

Wenn Sie sich über eine App mit einer OpenTok-Sitzung verbinden, geben Sie die Sitzung, mit der Sie sich verbinden möchten, mithilfe einer OpenTok-Sitzungs-ID an. Jede Sitzungs-ID identifiziert eine eindeutige OpenTok-Sitzung. Sie können sich eine Sitzung wie einen Raum vorstellen, in dem sich die Teilnehmer treffen und unterhalten.

Die Anzahl der von Ihnen erstellten Sitzungen und die Art und Weise, wie sich Nutzer mit diesen verbinden, hängen von den Anforderungen Ihrer App ab. Wenn Ihre App Nutzer für ein einmaliges Treffen miteinander verbindet, erstellen Sie für dieses Treffen eine eigene Sitzung. Wenn Ihre App Nutzer jedoch über mehrere Tage hinweg im selben „Raum“ miteinander verbindet, können Sie eine Sitzung erstellen und diese wiederverwenden. Wenn sich eine Gruppe von Nutzern trifft, während andere Gruppen unabhängig voneinander tagen, erstellen Sie für jede Gruppe eine eigene Sitzung.

OpenTok-Sitzungen laufen nicht ab. Authentifizierungstoken laufen jedoch ab. 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 OpenTok Media Router verwendet werden soll oder nicht)
  • Die Archivierungseinstellung (ob die Sitzung automatisch archiviert werden soll)
  • Ein Standorthinweis (zur Angabe des Standorts der Sitzung)

Der OpenTok Media Router und die Medienmodi

Wenn Sie eine Sitzung erstellen, legen Sie fest, wie die Teilnehmer der Sitzung Audio- und Videostreams senden sollen; dies wird als Medienbetrieb. Es gibt zwei Möglichkeiten:

  • Weitergereicht — In einer weitergeleiteten Sitzung versuchen die Clients, Audio- und Videostreams direkt untereinander (Peer-to-Peer) zu übertragen. Wenn die Clients jedoch aufgrund von Firewall-Einschränkungen keine Verbindung herstellen können, nutzt die Sitzung den OpenTok-TURN-Server zur Weiterleitung der Audio- und Videostreams. (Vor Version 2.2 bezeichneten die OpenTok-Server-SDKs diese Sitzungen als Peer-to-Peer-Sitzungen. Doch selbst bei Verwendung dieser SDKs nutzen die Sitzungen weiterhin den OpenTok-TURN-Server zur Weiterleitung von Streams, wenn Firewall-Einschränkungen das Peer-to-Peer-Streaming blockieren). Für die Sitzungsverhandlung werden TLS 1.3 und ein starkes Zertifikat mit mindestens 3072 Bit verwendet.

  • Geroutet — In der Sitzung wird der OpenTok Media Router verwendet, um Audio- und Videostreams zwischen den Clients weiterzuleiten. Die OpenTok Media Router bietet die folgenden Vorteile:

    • Für die Verbindungsaufbauphase werden TLS 1.3 und ein starkes Zertifikat mit mindestens 3072 Bit verwendet.

    • Der OpenTok Media Router kann den Bandbreitenverbrauch in Mehrparteien-Sitzungen senken. (Wenn die Eigenschaft „media mode“ auf „relayed“ gesetzt ist, muss jeder Client, der einen Stream veröffentlicht, diesen separat an jeden Client senden, der ihn abonniert hat. Mit dem OpenTok Media Router sendet ein Publisher einen Stream einmalig an den Router, der ihn dann an jeden abonnierenden Client weiterleitet.)

    • Der OpenTok Media Router kann die Qualität des Nutzererlebnisses verbessern durch Audio-Fallback und Video-Wiederherstellung für Abonnenten. Dank dieser Funktionen wird das Video auf einem Client unterbrochen (ohne dass andere Clients davon betroffen sind), wenn sich die Verbindung des Clients so weit verschlechtert, dass sie die Wiedergabe des Videos für einen abonnierten Stream nicht mehr unterstützt; der Client empfängt dann nur noch Audio. Verbessert sich die Verbindung des Clients wieder, wird das Video wieder angezeigt.

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

    • Der OpenTok Media Router unterstützt Live-Übertragungen.

    • Der OpenTok Media Router unterstützt Erlebnis-Komponist.

    • In Sitzungen, in denen der OpenTok Media Router zum Einsatz kommt, führt eine Verringerung der Bildrate eines veröffentlichten Videos zu einer proportionalen Reduzierung der vom Stream beanspruchten Bandbreite.

    • Der OpenTok Media Router unterstützt die Skalierbare Videofunktion. Skalierbares Video kann die Videoqualität bei Sitzungen mit mehreren Teilnehmern erheblich verbessern.

    • Bei Clients, die die OpenTok-SDKs für iOS und Android verwenden, unterstützen weitergeleitete Sitzungen nur zwei mit der Sitzung verbundene Clients. Der OpenTok Media Router unterstützt zusätzliche Clients für Mehrparteien-Sitzungen auf Mobilgeräten.

    • Der OpenTok Media Router unterstützt die SIP-Verbindungsfunktion, mit dem Sie OpenTok-Sitzungen mit SIP-Gateways verbinden können.

    • Der OpenTok Media Router unterstützt die Funktion „Audio-Anschluss“, mit dem Sie Audio aus einer OpenTok-Sitzung an einen WebSocket senden können.

Auch weitergeleitete Sitzungen (Sitzungen, die den OpenTok Media Router nutzen) profitieren von den folgenden Optimierungen:

  • 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. Bei aktivierter Single-Peer-Verbindung werden alle Teilnehmer-Streams für einen Client über eine einzige Verbindung zum OpenTok Media Router übertragen (auch wenn sie von verschiedenen Clients veröffentlicht werden). Zu den Vorteilen der Aktivierung der „Single Peer Connection“ gehören ein geringerer Ressourcenverbrauch auf Seiten des Clients, eine verbesserte Ratenkontrolle sowie – bei mobilen nativen Geräten – die Unterstützung größerer Sitzungen. Wenn die „Single Peer Connection“ deaktiviert ist (Standardeinstellung), nutzt der Client für jedes Audio-/Videobündel eine separate Verbindung zum OpenTok 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 (OpenTok.js) – 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 von Media Mesh. Die Plattform nutzt Media Mesh, um weitergeleitete Sitzungen automatisch zu optimieren, indem jeder Teilnehmer mit dem Medienrouter im nächstgelegenen regionalen Rechenzentrum verbunden wird. Dies verringert die Latenz und verbessert die Qualität, insbesondere bei geografisch verteilten Sitzungen.

    Media Mesh ist standardmäßig aktiviert und erfordert keine Konfiguration. Informationen dazu, wie Sie diese Optimierung außer Kraft setzen und Medien auf eine bestimmte Region beschränken können, finden Sie unter Regionale Medienzonen.

  • Adaptives Medien-Routing. Ab OpenTok.js v2.24.7 und v2.27.0 der anderen Client-SDKs (für Android, iOS, Windows, macOS, Linux und React) sind weitergeleitete Sitzungen so optimiert, dass sie adaptives Medien-Routing, sofern möglich. Das adaptive Medien-Routing ermittelt, ob Medien bei Eins-zu-Eins-Videostreams ohne den OpenTok Media Router weitergeleitet werden können, um die Medienleistung zwischen zwei Teilnehmern zu optimieren. Die weitergeleitete Sitzung passt das Medien-Routing automatisch an, sodass der OpenTok Media Router bei Bedarf genutzt wird – beispielsweise bei Sitzungen mit drei oder mehr Teilnehmern, bei der Archivierung, bei Live-Streaming-Übertragungen, bei der SIP-Anbindung, bei Experience Composer, bei Live-Untertiteln und beim Audio Connector.

    Mit der Einführung des adaptiven Medien-Routings gibt es zudem eine scalableVideo Option in OpenTok.js OT.initPublisher() Methode, um die Standardeinstellung außer Kraft zu setzen und skalierbares Video für den Herausgeber in einer gerouteten Sitzung zu deaktivieren.

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:

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

SDK-Unterstützung

AMR wurde in OpenTok.js v2.24.7 sowie in den Versionen 2.27.0 der Client SDKs für Android, iOS, Windows, macOS, Linux und React eingeführt. Clients, die ältere SDK-Versionen verwenden und sich in einer gerouteten Sitzung befinden, nutzen stets 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 Ereignisse, bei denen die Medienübertragung eines Publishers von der Peer-to-Peer-Weiterleitung auf den Media Router umgestellt wird (beispielsweise wenn ein zweiter Client einen Stream abonniert). Diese Ereignisse stellen keine tatsächlichen Verbindungsabbrüche dar – die Teilnehmer bleiben während des gesamten Übergangs verbunden. Dies ist ein bekanntes Problem in Inspector.
  • MediaStream-Objekte können sich während Übergängen ändern. Wenn AMR zwischen Peer-to-Peer-Weiterleitung und dem Media Router wechselt, 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:
    • Empfehlung: 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.
    • Alter Ansatz (vor Version 2.27.7): Auf das 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 wie gewohnt ausgelöst. Sie müssen AMR-Übergänge in Ihren Session-Ereignis-Listenern nicht speziell 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 über den Media Router übertragen werden. Während AMR die Medien eines Publishers im Peer-to-Peer-Verfahren weiterleitet, findet SPC für diesen Stream keine Anwendung. Sobald der Stream auf den Media Router umgeleitet wird, greift SPC, sofern es aktiviert ist.
  • Ende-zu-Ende-Verschlüsselung: Die End-to-End-Verschlüsselung funktioniert mit AMR. Die Medien werden verschlüsselt, unabhängig davon, ob sie Peer-to-Peer oder über den Media Router übertragen werden.
  • 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 Medien im Peer-to-Peer-Verfahren weiterleitet, wird „Scalable Video“ unabhängig vom verwendeten Codec automatisch deaktiviert. Wenn der Stream an den Media Router weitergeleitet wird, hängt das Verhalten von „Scalable Video“ vom Codec und der entsprechenden Einstellung der Anwendung 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.

Archiv-Modus

Wenn Sie eine Sitzung erstellen, können Sie den Archivierungsmodus so einstellen, dass die Sitzung automatisch archiviert wird. Dies gilt nur für geroutete Sitzungen (Sitzungen, die den OpenTok Media Router nutzen). Standardmäßig werden Sitzungen nicht automatisch archiviert.

Hinweise zum Standort

Wenn Sie eine Sitzung erstellen, können Sie die IP-Adresse festlegen, anhand derer die Vonage-Videoplattform den besten Server zur Steuerung der Sitzung in ihrem globalen Netzwerk auswählt. Wenn beim Erstellen der Sitzung kein Standorthinweis festgelegt wird (was empfohlen wird), wird der Sitzungssteuerungsserver anhand des Standorts des ersten Clients ausgewählt, der eine Verbindung zur Sitzung herstellt. Legen Sie einen Standorthinweis nur dann fest, wenn Sie die allgemeine geografische Region (und eine repräsentative IP-Adresse) kennen und davon ausgehen, dass sich der erste Client, der eine Verbindung herstellt, möglicherweise 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 Sitzungs-IDs nach Möglichkeit nicht mehrfach für verschiedene Video-Chat-Gespräche. Generieren Sie stattdessen für jeden einzelnen Video-Chat in Ihrer Anwendung neue Sitzungs-IDs.

Das ist besonders wichtig, wenn man OpenTok nutzt Inspektor. In Inspector werden Qualitätsbewertungen und Daten zu den Sitzungen anhand der Sitzungs-ID indiziert. Eine Sitzungs-ID, die für mehrere Gespräche wiederverwendet wird, lässt sich mit Inspector schwieriger debuggen, und Sitzungen mit wiederverwendeten Sitzungs-IDs weisen tendenziell niedrigere aggregierte Qualitätsbewertungen auf als die tatsächlich erlebte Gesprächsqualitä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.

Hinweis für Clients, die Versionen der Client-SDKs verwenden, die kleiner als 2.30.0 sind: Wir empfehlen, dass Sie bei Sitzungen, die länger als 8 Stunden dauern sollen, die verbundenen Benutzer zu einer neuen Sitzung migrieren, bevor es zu einer Zeitüberschreitung/Wiederverbindung kommt. Dadurch wird die beste Benutzererfahrung gewährleistet.

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 statt einer gerouteten Sitzung, wenn Sie nur zwei Teilnehmer (oder vielleicht sogar drei) haben und keine Archivierung nutzen. Durch die Verwendung weitergeleiteter Sitzungen wird die Latenz zwischen den Teilnehmern verringert, die Anzahl der Ausfallpunkte reduziert und Sie erhalten in den meisten Fällen eine bessere Video- und Audioqualität.

Für die Archivierung Ihrer Sitzung sind weitergeleitete Sitzungen erforderlich. Sie werden empfohlen, wenn mehr als zwei oder drei Teilnehmer an der Sitzung teilnehmen.

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

Sitzungen erstellen

Während Sie an einer Testversion Ihrer App arbeiten, können Sie über die Projektseite Ihrer Video API-Konto.

Sie können auch eine der serverseitigen OpenTok-Bibliotheken oder die OpenTok-REST-API verwenden, um eine Sitzung zu erstellen:

Sie können auch die OpenTok REST API um eine Sitzung zu erstellen.

Wenn Sie mehrere Sitzungs-IDs dynamisch generieren müssen, verwenden Sie eine der serverseitigen OpenTok-Bibliotheken oder die OpenTok-REST-API – nicht die Projektseite.