Inhalt dieses Guides
SRT-Verbindungsrollen verstehen: Caller, Listener, Rendezvous, NAT, Firewall und warum mobile Encoder meist anders geplant werden als Server im Rechenzentrum.
IRL-Arbeitsmodus
IRL ist ein Gesamtsystem aus Funk, Transport, Strom, Thermik und Audio. Teste diese Ebenen getrennt.
Welche Ebene ist aktuell am schwächsten?
Peak-Speed allein reicht nicht. Stabilität, Handover und Zelllast bestimmen den Livebetrieb.
Transportprotokoll und Redundanz müssen zum Verhalten deiner Mobilfunkpfade passen.
Ein perfekter Uplink hilft nicht, wenn Smartphone, Hub, Mikrofon oder Stromversorgung ausfallen.
SRT kann Verbindungen in verschiedenen Modi aufbauen. Die Begriffe Caller, Listener und Rendezvous beschreiben nicht die Videoqualität, sondern wer die Verbindung initiiert beziehungsweise wie beide Endpunkte miteinander aushandeln. Für mobile Workflows ist das relevant, weil ein Smartphone oder Encoder häufig hinter NAT und Provider-Infrastruktur sitzt.
Caller: Verbindung aktiv aufbauen
Der Caller kennt Adresse und Port der Gegenstelle und initiiert die Verbindung. Für Feldgeräte ist das oft praktisch: Ausgehende Verbindungen funktionieren hinter NAT in der Regel einfacher als ein von außen erreichbarer Dienst direkt auf der Mobilfunkverbindung.
Listener: auf Verbindung warten
Der Listener bindet einen Port und wartet auf eingehende SRT-Verbindungen. Ein Server im Rechenzentrum mit öffentlicher IP ist dafür ein typischer Kandidat. Firewallregeln müssen den gewählten Port zulassen; der Dienst sollte nicht unnötig breit exponiert werden.
Rendezvous: beide Seiten kennen sich
Im Rendezvous-Modus versuchen beide Endpunkte, die Verbindung zueinander aufzubauen. Das kann in bestimmten NAT-Szenarien nützlich sein, ist aber nicht automatisch die einfachste Option. Für einen klaren Creator-Workflow ist Caller → öffentlicher Listener oft leichter zu dokumentieren und zu überwachen.
Portplanung
SRT verwendet UDP. Öffne nur den konkret benötigten Port an der Gegenstelle. Wenn mehrere Feeds parallel laufen, dokumentiere Zuordnung und Zweck. Eine Cloud-VM sollte zusätzlich mit Host-Firewall und gegebenenfalls IP-Restriktionen abgesichert werden.
Verschlüsselung nicht vergessen
SRT unterstützt AES-Verschlüsselung. Wenn der Feed über das öffentliche Internet läuft, ist ein Passphrase-basierter verschlüsselter Transport sinnvoll. Passphrases gehören nicht in öffentlich sichtbare Startskripte oder Repositories.
Fehler systematisch eingrenzen
- Kann der Caller die Server-IP erreichen?
- Lauscht der SRT-Prozess auf dem erwarteten UDP-Port?
- Erlaubt die Firewall den Port?
- Stimmen Modus und Port auf beiden Seiten?
- Stimmen Verschlüsselungsparameter?
- Erst danach Codec- und Containerfragen prüfen.
Für die Pufferdimensionierung siehe SRT-Latenz einstellen.
Konfiguration versionieren
Speichere für jeden Endpunkt eine kleine Dokumentation mit Modus, Hostname, Port, Verschlüsselung und Zweck des Feeds. Bei mehreren mobilen Encodern verhindert das Verwechslungen und erleichtert einen schnellen Ersatz. Sensible Passphrases gehören dabei in einen geschützten Secret-Store oder in die jeweilige Geräteverwaltung, nicht in gemeinsam geteilte Klartextnotizen.