SRT-Server
Verwenden Sie SRT-Server, um sichere Contribution-Streams mit niedriger Latenz von Remote-Encodern oder Partnersystemen über verwaltete SRT-Ingest-Endpunkte zu empfangen. Steuern Sie den Zugriff für Publisher und Receiver, überwachen Sie den Live-Transportzustand in der authentifizierten Callaba-Oberfläche und bereiten Sie primäre sowie sekundäre PULL-Routen für Neuverbindung und Rückfall nach einer Unterbrechung vor.
Geeignet, wennSie benötigen verwalteten SRT-Ingest mit Zugriffsregeln, Transporttelemetrie sowie Primär- und Backup-Failover.
Anderes Modul verwenden, wennVerwenden Sie SRT-Routen für unveränderte Weiterleitung oder Restreams für Transcodierung, Overlays und andere Ausgabeprotokolle.
/api/srt-servers/createVoraussetzungen
Alle Verwaltungsmethoden erfordern einen gültigen x-access-token. Reservieren Sie erreichbare SRT-Ports, stimmen Sie Latenz und Passphrase mit dem Sender ab und legen Sie den Zugriff für Publisher und Receiver fest, bevor Sie Verbindungsdetails weitergeben.
Funktionen
createundupdatekonfigurieren Ports, Latenz, Bandbreite, Empfangspuffer, Passphrase, Zugriff, Callbacks und Routing-Hosts.getAll,getCountundgetByIdinspizieren Server.startundstopsteuern den Listener.switchTovalidiert und speichert eine bevorzugte konfigurierte PULL-Route. Wenden Sie die gespeicherte Präferenz in einem geplanten Wartungsfenster mitstopundstartan.removelöscht den Server.
Beispiel-Workflow
- Erstellen Sie einen Listener mit den erforderlichen Port-, Latenz-, Passphrasen- und Zugriffsregeln.
- Fügen Sie primäre und Backup-Routing-Hosts hinzu, wenn ein Failover erforderlich ist.
- Starten Sie den Server und verbinden Sie den Publisher.
- Beobachten Sie Live-Bitrate, geschätzte Bandbreite, Roundtrip-Zeit, Puffer und Verlustzähler in der Callaba-Operator-Oberfläche.
- Unterbrechen Sie die Primärquelle in einem kontrollierten Abnahmetest und bestätigen Sie in der authentifizierten Operator-Oberfläche, dass Neuverbindung und Routing-Host-Schleife eine vorbereitete Backup-Quelle erreichen.
Typische Anwendungsfälle
- Empfangen Sie verschlüsselte Contribution-Streams von einer Remote-Kamera oder einem Encoder am Veranstaltungsort.
- Betreiben Sie konfigurierte primäre und sekundäre SRT-PULL-Feeds mit Neuverbindung und Rückfall nach einer Unterbrechung.
- Steuern Sie den Publisher- und Receiver-Zugriff für Partner- oder Gastverbindungen.
- Überwachen Sie den Verbindungszustand und -ursprung während einer Live-Veranstaltung.
Einschränkungen und Fehlerbehebung
Sender und Listener müssen Modus, Port, Latenz, Stream-Identität und Passphrase identisch konfigurieren. Failover ist nicht grundsätzlich unterbrechungsfrei: Erkennungs- und Wiederherstellungszeit hängen von Quelle, Ziel, Neuverbindungsintervall, Puffer, Latenz und Netzwerk ab. switchTo speichert eine konfigurierte Routenpräferenz, lädt jedoch keinen laufenden Relay neu. Wenden Sie sie mit einem kontrollierten Stopp und Start an und prüfen Sie anschließend den Live-SRT-Zustand in der authentifizierten Callaba-Operator-Oberfläche.
Nächste Schritte
Prüfen Sie den Live-Feed und verbinden Sie den Server anschließend mit SRT-Routen, Restreams, Aufzeichnungen, Multiview oder Webplayern.
Ein SRT-Server-Gateway für Contribution aufbauen
Erstellen Sie einen sicheren SRT-Ingest für einen Remote-Production-Feed, starten Sie ihn und prüfen Sie die gespeicherte Zugriffs- und Routing-Konfiguration vor dem Downstream-Routing.
- SRT-Gateway erstellenLegen Sie Ports, Latenz, Passphrase, Publisher-/Receiver-Zugriff und Routing fest.
POST /api/srt-servers/create - Contribution-Ingest startenStarten Sie den Listener, bevor Sie Verbindungsdaten mit der Quelle teilen.
POST /api/srt-servers/start - Gespeichertes Gateway prüfenPrüfen Sie Ports, Zugriffsdatensätze, Routing-Hosts und Aktivstatus über die authentifizierte Ressource.
POST /api/srt-servers/getById
Eine erfolgreiche Create-Antwort bestätigt die Konfiguration, nicht den Medienzustand. Starten Sie die Ressource und prüfen Sie ihre Laufzeitstatistik, bevor Sie Produktionsverkehr senden.
Primäre und sekundäre SRT-Routen vorbereiten und prüfen
Konfigurieren Sie freigegebene Primär- und Backup-Quellen auf einem PULL-Server, prüfen Sie den gespeicherten Routensatz und validieren Sie das Neuverbindungsverhalten bei einer kontrollierten Quellenunterbrechung.
- Quellensatz konfigurierenErstellen Sie einen PULL-Server mit Primär- und Backup-URLs in routing_hosts.
POST /api/srt-servers/create - Gespeicherten Routensatz prüfenBestätigen Sie PULL-Routing und alle freigegebenen primären und sekundären Hosts.
POST /api/srt-servers/getById - Konfigurierten Relay startenStarten Sie den Server erst nach Prüfung von Routenreihenfolge und Verbindungseinstellungen.
POST /api/srt-servers/start - Abnahmefenster sicher beendenStoppen Sie nach der Prüfung von Primärausfall und Backup-Wiederherstellung in der Operator-Oberfläche bei Bedarf die temporäre Abnahmelaufzeit.
POST /api/srt-servers/stop - Produktionsrouten finalisierenWenden Sie geprüfte Timeout- oder Routenreihenfolge-Korrekturen im kontrollierten Wartungszustand an.
POST /api/srt-servers/update
Dies ist neuverbindungsbasierte Wiederherstellung zwischen konfigurierten Quellen, keine paketbasierte unterbrechungsfreie Pfadredundanz. Prüfen Sie die Wiederherstellung mit echtem Media-Traffic in der authentifizierten Callaba-Operator-Oberfläche.
Bevorzugte SRT-Quelle beim nächsten kontrollierten Start anwenden
Prüfen Sie die konfigurierten PULL-Routen, stoppen Sie den Relay in einem geplanten Fenster, speichern Sie die bevorzugte Quelle und starten Sie den Server, damit Engine die Laufzeit mit dieser Präferenz neu erzeugt.
- Primär- und Backup-Quelle registrierenErstellen Sie einen PULL-Server, dessen routing_hosts jede URL enthält, die die Richtlinie auswählen darf.
POST /api/srt-servers/create - Zugelassenen Routensatz prüfenBestätigen Sie PULL-Modus und exakte gespeicherte URLs vor dem Wartungsfenster.
POST /api/srt-servers/getById - Laufenden Relay stoppenWechseln Sie vor der Änderung der gespeicherten Routenpräferenz in einen kontrollierten Wartungszustand.
POST /api/srt-servers/stop - Bevorzugte Quelle speichernSenden Sie die Server-ID und eine exakte, bereits in routing_hosts vorhandene srt_url.
POST /api/srt-servers/switchTo - Neu erzeugen und startenStarten Sie den Server, damit die Relay-Konfiguration mit der gespeicherten Routenpräferenz neu erzeugt wird, und prüfen Sie anschließend das Live-Medium in der Operator-Oberfläche.
POST /api/srt-servers/start
switchTo validiert und speichert die konfigurierte Routenpräferenz, lädt jedoch keinen laufenden Relay neu. Behandeln Sie stop, switchTo und start als eine geplante Wartungstransaktion.
SRT-Publisher- und Receiver-Zugriff steuern
Wählen Sie beim Erstellen eine offene Gast-Grenze, eine IP-Allowlist oder einen passwortgeschützten Listener und prüfen Sie die befüllten Zugriffsdatensätze, bevor Sie Verbindungsdaten verteilen.
- Zugriffsgrenze erstellenSetzen Sie stream_control_type und access_settings für die gewählte Richtlinie zusammen mit Ports, Latenz und optionaler Passphrase.
POST /api/srt-servers/create - Gespeicherte Zugriffe prüfenLesen Sie die befüllte Zugriffsrelation und bestätigen Sie Publisher- und Receiver-Rollen vor der URL-Freigabe.
POST /api/srt-servers/getById - Richtlinie sicher wechselnSenden Sie beim Wechsel zwischen Gast-, Allowlist- oder geschütztem Betrieb den vollständig gewünschten Server- und Zugriffszustand.
POST /api/srt-servers/update
CONTROL_ACCESS_ALLOW_ALL akzeptiert beliebige Publisher- oder Receiver-Identitäten und sollte nur für bewusste Gast-Workflows verwendet werden. Nutzen Sie CONTROL_ACCESS_IP_ADDRESS mit access_settings für bekannte Hosts und ergänzen Sie bei Bedarf eine SRT-Passphrase.
Erstellen Sie einen SRT-Listener mit Ports, Latenz, Pufferung, Verschlüsselung, Routing, Monitoring und Zugriffskontrolle. Senden Sie das im Dashboard erzeugte JWT im x-access-token-Header.
Wählen Sie über routing_type einen Standalone-, Push- oder Pull-Listener. Senden Sie kein separates server_fc-Feld; Callaba berechnet die Flusssteuerung aus server_rcvbuf.
Einheiten sind signifikant: server_latency ist Millisekunden, server_timeout sind Sekunden, server_maxbw sind Bytes pro Sekunde und server_rcvbuf sind Bytes.
Anfragebeispiele
Wählen Sie eine Voreinstellung ohne Routing, mit Public-IP-Routing, Callaba-Routing oder erweiterten Sicherheits- und Monitoring-Einstellungen. Für eine operatorgesteuerte Bereitstellung steht außerdem ein Beispiel unter vMix Script bereit.
Typische Anwendungsfälle
- Stellen Sie OBS, einem Feld-Encoder oder einem Partner-Feed einen stabilen Contribution-Endpunkt bereit.
- Konfigurieren Sie das Push- oder Pull-Routing für eine Backup-Quelle oder eine verwaltete Übergabe.
- Schützen Sie einen operativ überwachten Ingest-Endpunkt mit Passphrase, Zugriffsregeln sowie Event- und Statistik-Callbacks.
Diese Beispiele halten routing deaktiviert und verwenden den Server selbst als stabilen Ingest-Endpunkt.
Verwenden Sie diese Konfiguration, wenn der Server als einfacher lokaler SRT-Ingest-Endpunkt ohne Routing-Schicht fungieren soll. Dies ist die einfachste Konfiguration und entspricht weitgehend dem Basisformular im Dashboard.
Der Modus PUBLIC_IP dient der direkten Weiterleitung zu öffentlichen Netzwerkadressen. Verwenden Sie PUSH, wenn dieser Server aktiv zum entfernten Endpunkt senden soll. Verwenden Sie PULL, wenn dieser Server den Stream vom entfernten SRT-Upstream abrufen soll.
Verwenden Sie diese Konfiguration, wenn der Server aktiv auf ein Public-IP-Routing-Ziel senden soll. Jeder Routing-Host benötigt einen Host und Port, während routing_server_name in diesem Modus optional bleibt.
Verwenden Sie diese Form, wenn die geroutete Seite im PULL- statt im PUSH-Modus betrieben werden soll. In der Praxis ist dies die entsprechende Public-IP-Konfiguration für einen PULL-Workflow.
Der Routing-Modus CALLABA verwendet benannte Routing-Hosts und erfordert für jedes Ziel Host, Port und Servername. Verwenden Sie PUSH, wenn dieser Server in die Callaba-seitige Route senden soll, und PULL, wenn die Callaba-seitige Route als SRT-Upstream dienen soll.
Verwenden Sie diese Konfiguration, wenn der Server im PUSH-Modus zum Callaba-Cloud-Pfad routen soll. In diesem Routing-Modus muss jedes Hostelement auch routing_server_name tragen.
Verwenden Sie diese Form, wenn die geroutete Callaba-Seite im PULL- statt im PUSH-Modus arbeiten soll. Die Anforderungen an die benannten Routing-Hosts bleiben beim Wechsel des Routing-Typs unverändert.
Diese Beispiele behalten die grundlegende Ingest-Konfiguration bei, aktivieren aber jeweils nur eine erweiterte Funktion, sodass es einfacher ist, die genauen Felder zu kopieren, die Sie benötigen.
Verwenden Sie diese Konfiguration, wenn der Ingest-Endpunkt SRT-Verschlüsselung benötigt. Das Beispiel verwendet eine 16 Zeichen umfassende Passphrase, die laut Produktanleitung für einen mit AES-128 sicheren Schutz geeignet ist.
Geeignet für: gemeinsam genutzte Ingest-Endpunkte, Partner-Contribution und alle Fälle, in denen der Listener standardmäßig keine unverschlüsselten SRT-Sitzungen akzeptieren soll.
Verwenden Sie diese Konfiguration, wenn der Server SRT-Statistiken an einen externen Monitoring-Endpunkt senden soll. Das Backend validiert Callback-URL und Intervall gemeinsam.
Geeignet für: verwaltete Veranstaltungen, Support-Workflows und dauerhaft laufende Ingest-Endpunkte, deren Telemetrie ohne regelmäßige Abfrage des vollständigen Serverobjekts extern erfasst werden soll.
Verwenden Sie diese Konfiguration, wenn nur bestimmte Publisher- oder Receiver-Hosts erlaubt sein sollen. Jeder Eintrag erfordert host und role_name, wenn stream_control_type CONTROL_ACCESS_IP_ADDRESS ist.
Geeignet für: kontrollierten Ingest von bekannten Standorten oder festen Peer-Adressen.
Dashboard-Bezeichnung: Name.
Vergeben Sie einen eindeutigen Namen, damit der Server später leicht zu erkennen ist. Die Validierung akzeptiert 1 bis 60 Zeichen.
Der aktuell validierte API-Vertrag akzeptiert SERVER_TYPE_SRT.
Das Modell enthält außerdem SERVER_TYPE_WEBRTC, aber die Validierung beim Erstellen und Aktualisieren erlaubt derzeit nur den SRT-Servertyp.
Dashboard-Bezeichnung: Einmal erstellt aktivieren.
„Aktiviert“ beschreibt den aktuellen Serverzustand. Durch das Deaktivieren des Servers werden Verbindungen und Datenübertragungen für alle mit diesem SRT-Server verbundenen Publisher und Receiver deaktiviert.
Dashboard-Bezeichnung: Port.
Listener-Port des SRT-Servers. Die Live-Validierung akzeptiert Werte von 1024 bis 65535.
Dashboard-Bezeichnung: Receiver-Port.
Port zum Empfangen von SRT-Streams. Die aktuell validierte API erwartet auch einen Wert von 1024 bis 65535.
Die Laufzeit hat einen Fallback-Pfad, wenn dieser Port fehlt, aber der öffentliche API-Vertrag beim Erstellen und Aktualisieren erfordert ihn immer noch explizit.
Dashboard-Bezeichnung: Latenz.
Die Latenz wird in Millisekunden konfiguriert. Die Produktanleitung empfiehlt die Verwendung von ungefähr ping × 4, mit einem praxistauglichen Mindestwert von etwa 120 ms für einen stabilen SRT-Contribution-Stream.
Eine praktische Einrichtungsanleitung finden Sie unter Finden Sie die perfekte Latenz für Ihr SRT-Setup.
Dashboard-Bezeichnung: Maximale Netzwerkbandbreite.
Netzwerkbandbreite oder Bitrate in Byte/s. Verwenden Sie -1 für unbegrenzte Bandbreite. Die Validierung akzeptiert derzeit Werte bis zu 3125000000.
Dashboard-Bezeichnung: Timeout bei Stream-Inaktivität.
Konfiguriert in Sekunden. Wenn das Timeout erreicht ist, trennt der Server den Client. -1 bedeutet unbegrenztes Timeout.
Dashboard-Bezeichnung: Empfangspuffergröße.
Dieses Feld wird in Bytes ausgedrückt. Die REST API akzeptiert 12058624 bis 200000000.
Das Dashboard beginnt mit 12058624 und empfiehlt 48234496 für den Produktionseinsatz. Die Flusssteuerung wird aus diesem Empfangspuffer abgeleitet, sodass Sie kein separates server_fc-Feld senden.
Dashboard-Bezeichnung: Passphrase.
Optionales SRT-Verschlüsselungsgeheimnis für den Ingest-Endpunkt. Die Dashboard-Anleitung empfiehlt eine Länge von 16, 24 oder 32 Zeichen für Passphrasen mit AES-128, AES-192 oder AES-256 sicherer Verschlüsselung.
Dashboard-Bereich: Routing-Einstellungen.
Steuert, ob der SRT-Server als lokaler eigenständiger Ingest-Endpunkt oder als gerouteter Endpunkt läuft. Die validierten Werte sind DISABLED, PUBLIC_IP und CALLABA.
Diese Auswahl beeinflusst, welche Laufzeitvorlage ausgewählt wird: Standalone, PUSH oder PULL-Routing-Modus.
Das Servermodell definiert PUSH und PULL.
Liste der Routing-Ziele.
Beim CALLABA-Routing muss jedes Element routing_host, routing_port und routing_server_name enthalten. Bei PUBLIC_IP sind Host und Port erforderlich; der Servername ist optional.
Das Produkt verknüpft diesen Modus auch mit Backup-Stream-Workflows. Siehe Wie man einen SRT-Backup-Stream im Falle einer Unterbrechung des Hauptstreams einrichtet.
Optionale Callback-URL für die Übermittlung von SRT-Statistiken. Bei der Einstellung muss der Wert ein gültiger http oder https-URI sein.
Intervall für die Veröffentlichung von Statistiken in Sekunden.
Die Validierung beim Erstellen und Aktualisieren akzeptiert Werte von 1 bis 10. Wenn Statistiken aktiviert sind und kein Intervall bereitgestellt wird, verwendet der Dienst standardmäßig 1.
Modus zur Steuerung des Stream-Zugriffs: Wenn der Wert auf IP-adressbasierte Zugriffssteuerung gesetzt ist, validiert das Backend die zugehörigen access_settings-Einträge als Host- und Rollenobjekte.
Optionale Liste von Zugriffsregeln oder Stream-Identitäten, die zusammen mit dem Server erstellt werden.
In Antworten werden diese als zugehörige access-Einträge und nicht als ursprünglicher Request-Body angezeigt.
Ressourcen-ID, die beim Erstellen oder Auflisten des SRT-Servers zurückgegeben wird.
In der API-Antwort stimmt id mit _id überein.
Name, der für den erstellten SRT-Server gespeichert ist.
URL-freundlicher Slug, der aus server_name erzeugt wird. Das Backend erzeugt ihn durch URL-Normalisierung.
Typ des erstellten Servers, zum Beispiel SERVER_TYPE_SRT.
Listener-Port, den die API für den erstellten SRT-Server zurückgibt.
Receiver-Port, den die API für den erstellten SRT-Server zurückgibt.
Zugehörige UDP-Portzuweisung für die Publisher-Seite des Servers.
Zugehörige UDP-Portzuweisung für die Receiver-Seite des Servers.
Konfigurierter Latenzwert in Millisekunden.
Konfigurierte maximale Bandbreite in Byte/s.
Konfiguriertes Inaktivitäts-Timeout in Sekunden. Die API-Antwort serialisiert den Wert derzeit als String.
Konfigurierte Größe des Empfangspuffers in Byte. Die Flusssteuerung wird aus diesem Wert abgeleitet.
Ob der erstellte Server unmittelbar nach der Erstellung aktiviert ist.
Gespeichertes Verschlüsselungsfeld für den Server: Wenn der Passphrasenschutz aktiviert ist, speichert das Backend einen verschlüsselten Wert anstelle eines Klartextgeheimnisses.
Mit dem Server gespeicherte publisherseitige Stream-ID beziehungsweise URL-Präfix.
Mit dem Server gespeicherte receiverseitige Stream-ID beziehungsweise URL-Präfix.
Routing-Ziele, die mit dem Server gespeichert sind. Im minimalen Standard-Erstellungsablauf ist dies ein leeres Array.
Aufgelöstes Statistikintervall. Der Standardwert beim Erstellen ist 1.
Verknüpfte Zugriffs- und Stream-Einträge für diesen SRT-Server. getById löst diese vollständiger auf als die Antworten beim Erstellen und Aktualisieren.
Vom Backend ergänzte Benutzerkennung des Besitzers.
Erstellungszeitstempel, der von der API zurückgegeben wird.
Zeitstempel der letzten Änderung.
Dokumentversionsfeld, das von der Modellserialisierung zurückgegeben wird.
Die API gibt zusammen mit dem erstellten SRT-Serverobjekt ein boolesches Erfolgsflag zurück. Bei erfolgreicher Erstellung ist es true.