---
title: Netzanforderungen für ST 2022-7
url: https://doc2.pstreamer.tv/de/manual/planning/st2022_7.html
lang: de
product: Perfect Streamer
version: 2.0.2.423
---

# Netzanforderungen für ST 2022-7

> **Wichtig**
>
> **Betaversion 2.1.** Das hier Beschriebene gibt es nur in der Betaversion 2.1: Sie wird aus dem Beta-Repository und nur mit einer Lizenz installiert; die stabile Version 2.0.2 und die Demoversion enthalten es nicht. Die Betaversion wird ohne Gewähr ausgeliefert, Support gibt es nach Möglichkeit ([Betatestprogramm](../extras/beta.md#extras-beta)).

SMPTE ST 2022-7 ist nahtlose Redundanz: Derselbe RTP-Stream erreicht den Empfänger über zwei Wege, und der Empfänger setzt sie anhand der Folgenummern der RTP-Pakete zu einem zusammen. Ein Paket, das auf einem Weg verloren geht, wird vom anderen genommen; es gibt keine Umschaltung, und am Ausgang des Empfängers ist der Verlust nicht zu sehen. Der Schutz ist genau so zuverlässig, wie die Wege unabhängig sind: Alles, was beide Wege gemeinsam haben, bleibt ein Single Point of Failure.

In Perfect Streamer wird der zweite Weg an Eingängen und Ausgängen vom Typ RTP eingerichtet ([RTP](../webui/io/network.md#webui-io-rtp)):

- der Eingang empfängt den zweiten Weg — `path2-address` und `path2-port`, die Schnittstelle `path2-bind-if`, die SSM-Quelle `path2-ssm-address` und das Wartefenster `path-skew-ms`;
- der Ausgang sendet dieselben Pakete über den zweiten Weg — `path2-address` und `path2-port`, die Schnittstelle `path2-mcast-if`.

Beide Wege müssen ein und denselben Stream tragen: dieselbe SSRC und dieselbe Paketnummerierung. Unterscheiden sich die Wege, werden sie nicht zusammengeführt — es wird nur der erste Weg verwendet, und der Knoten löst einen Alarm mit Code 76 (`input-paths-differ`, [Liste der Alarme](../extras/alert_codes.md#extras-alert-codes)) aus. Ein- und Ausgänge vom Typ Pro-MPEG behandeln den zweiten Weg genauso wie RTP; die FEC des zweiten Wegs läuft auf dessen eigene FEC-Ports, und Pro-MPEG-Multiplexing lässt sich mit dem zweiten Weg nicht kombinieren ([Pro-MPEG](../webui/io/network.md#webui-io-prompeg)).

## Zwei unabhängige Wege

Die wichtigste Anforderung sind zwei getrennte Netze, etwa „rot“ und „blau“, jedes mit eigenen Switches, Leitungen und eigener Stromversorgung. Ein gemeinsamer Switch, eine gemeinsame Backbone-Leitung oder eine gemeinsame Stromversorgung auf beiden Wegen ist ein Single Point of Failure, und fällt er aus, gehen beide Wege zugleich verloren.

Auf dem Knoten sind zwei Netzwerkkarten empfehlenswert, eine für jedes Netz. Einem Eingang wird der zweite Weg mit dem Feld `path2-bind-if` zugewiesen, einem Ausgang mit dem Feld `path2-mcast-if` (Name der Schnittstelle oder ihre IPv4-Adresse; ein leerer Wert bedeutet die Standardschnittstelle des Systems). Ließ sich der zweite Weg des Ausgangs nicht öffnen, etwa weil `path2-mcast-if` eine Adresse nennt, die es auf diesem Server nicht gibt, sendet der Ausgang weiter über den ersten Weg, und der Fehler des zweiten Wegs erscheint in der Statistik des Ausgangs.

## Multicast

Sind die Wege Multicast-Gruppen, müssen beide Netze Multicast jeweils selbst weiterleiten:

- auf den Switches ist IGMP Snooping aktiviert;
- in **jedem** der beiden Netze läuft ein IGMP Querier. Ohne ihn leitet das Snooping die Gruppe nach einigen Minuten nicht mehr weiter, und der Weg verschwindet ohne sichtbaren Grund;
- für den Empfang mit Angabe der Quelle (SSM, `path2-ssm-address` für den zweiten Weg) muss das Netz IGMPv3 unterstützen;
- führen die Wege über Router, ist in beiden Netzen PIM eingerichtet, und die TTL der Pakete reicht für alle Abschnitte.

## Bandbreite

Jeder Weg trägt den ganzen Stream, deshalb verdoppelt sich der Verkehr: Planen Sie für jedes Netz die volle Bitrate des Streams ein. Kommt FEC zum Stream hinzu, läuft auch dessen Anteil über jeden Weg ([Planung von Bandbreite, Latenz und Ports](index.md#planning-bandwidth-latency)).

## Laufzeitunterschied der Wege

Die Laufzeiten der beiden Wege unterscheiden sich, und der Unterschied muss in das Empfängerfenster `path-skew-ms` passen: 10 bis 1000 ms, standardmäßig 450 ms — Klasse C des Standards ST 2022-7 (Streams unter 270 Mbit/s). Das ist die längste Zeit, die der Empfänger auf ein fehlendes Paket vom nachlaufenden Weg wartet. Das Warten zählt ab dem Moment, in dem die Lücke erkannt wird, also wenn der vorauslaufende Weg die folgenden Pakete bereits geliefert hat. Ein Verlust mehrerer Pakete auf dem vorauslaufenden Weg wird ersetzt, solange der nachlaufende Weg um nicht mehr als `path-skew-ms` plus die Dauer dieser Pakete zurückliegt.

In realen Netzen unterscheiden sich die Wege meist um einige bis einige zehn Millisekunden. Sind die Laufzeiten der Wege bekannt und ähnlich, lässt sich `path-skew-ms` verringern: Der Empfänger fügt dann weniger Verzögerung hinzu. Die eigene Verzögerung des Streams auf dem Knoten muss dieses Fenster abdecken.

## Was nicht nötig ist

- **Jumbo-Frames.** Sieben TS-Pakete in einem RTP-Paket passen in die übliche MTU von 1500 Byte.
- **PTP und Uhrensynchronisation.** Die Wege werden nach den Folgenummern der RTP-Pakete zusammengeführt, nicht nach der Zeit — anders als bei SMPTE ST 2110.
- **Besondere ST-2022-7-Funktionen in den Switches.** Gewöhnliche Unicast- oder Multicast-Weiterleitung genügt.

## Empfehlungen

- In einem Netz, das sich die Streams mit anderem Verkehr teilen, geben Sie ihnen QoS-Priorität (DSCP); sonst verzögert oder verliert eine Spitze fremden Verkehrs Pakete auf beiden Wegen zugleich.
- Führen Sie nicht beide Wege über eine gebündelte Verbindung (LAG) oder eine Backbone-Leitung: Das ist derselbe Single Point of Failure wie ein gemeinsamer Switch.
- Bei einem Ausgang in einer Reservegruppe sendet beide Wege der Knoten, der als Sender der Gruppe gewählt ist. Legen Sie `path2-mcast-if` auf jedem Mitglied der Gruppe fest: Auch über den zweiten Weg beobachten die Knoten den Sender.